ATM packet scheduler

RELATED APPLICATION

0001This application is a continuation of U.S. patent application Ser. No. 09/473,724, filed Dec. 28, 1999, now U.S. Pat. No. 6,654,376 dated Nov. 25, 2003.

FIELD OF THE INVENTION

0002This invention relates to arrangement and method of adapting voice and data traffic into an ATM network.

BACKGROUND OF THE INVENTION

0003The services that are carried in today's telecommunications network can be categorised into two main types; real time and non-real time services. The key examples of these two types are respectively voice telephony and computer data. The two services have very different characteristics and requirements and therefore have traditionally been carried over disjoint network technologies. However to increase flexibility and to decrease costs, there is a major drive by PTTs and network operators to integrate real-time and non-real time services within one homogeneous network. The asynchronous transfer mode (ATM) has been specifically designed to enable this.

0004A component of ATM is the adaptation function. This provides the mechanism that adapts the carried service to and from the ATM domain. Several adaptation layers have so far been defined. For example, ATM Adaptation Layer 1 (AAL1) is designed to adapt constant bit rate services (predominately voice or video) into fixed length ATM cells. A key feature of AAL1 is that it enables the timing relationship between the transmitter and receiver to be maintained over the asynchronous network. In contrast, AAL5 has been predominantly designed to support data services. As such it provides a mechanism to segment long data packets into fixed length ATM cells and a mechanism to enable the integrity of the reassembled data packet to be validated after transmission across the network. AAL5 is also being used in certain applications to carry voice services (particularly in computer desktop applications) where AAL5 technology is readily available.

0005Both AAL1 and AAL5 adapt the carried service into a stream of fixed length ATM cell payloads. However for certain compressed voice services the length of the ATM cell payload (48 bytes) is too large and its use would lead to a large packetisation delay that in turn would affect existing network delay budgets and acceptable voice characteristics. To resolve this problem AAL2 has been defined. AAL2 supports a multiplex of user channels within a single Virtual Channel Connection (VCC). Each user channel is carried in a stream of ‘mini-packets’—the length of the mini-packet payload for each channel can be defined according to the packetisation delay that can be tolerated. AAL2 differs from AAL1 and AAL5 in two key ways; firstly it enables a single VCC to support multiple diverse services (a number of simultaneous voice, video and data channels can be multiplexed together to reduce packetsation delay), and secondly it introduces a new switching layer above the ATM layer (i.e. the function of switching a mini-packet connection from one AAL2 VCC to another AAL2 VCC).

0006AAL2 has introduced a number of new issues to ATM scheduling and congestion control. These arise primarily from the characteristics of the traffic sources that AAL2 has been designed to support.

0000Traffic Classes Overview

0000ATM Traffic Classes

0007To accommodate the differing behaviours and QoS requirements for a variety of traffic sources, a set of traffic classes is defined in ATM. Each class is designed to describe the characteristics and requirements of a particular type of voice or data service. Five traffic classes have been defined by the ATM Forum [ATMF TM<b>4</b>]-CBR, rt-VBR, nrt-VBR, ABR and UBR.

0008However by its nature only the CBR and rt-VBR classes are appropriate for AAL2.

CBR

0009The CBR traffic class has been designed to support periodic traffic sources that have real-time requirements (i.e. they are delay sensitive). The traffic contract for a CBR connection is entirely specified by its Peak Cell Rate (PCR). The PCR specifies the peak emission rate of ATM cells (and thus implicitly the period between successive cells). All cells within the connection should conform to the PCR. Although the connection is described as CBR, it is perfectly admissible to transmit cells at lower than the PCR, or even to halt emission entirely.

0010Since the class is real-time, the ATM network commits to delivering cells within a specified delay and jitter bound (CTD and CDV).

0000rt-VBR

0011The real-time VBR class has been defined to support variable rate real time services (such as certain video streams). A rt-VBR connection is specified in terms of its Sustained Cell Rate (SCR), its Maximum Burst Size (MBS) and its PCR. The SCR defines the mean rate of the connection, the PCR defines the peak rate of any burst and the MBS defines the relationship between the two. Again, as this is a real time connection, the ATM network commits to delivering the service to specified delay and jitter bounds.

0000Policing of Connections

0012Once a connection has been established the ATM network commits to delivering it within the pre-specified QoS bounds providing the connection adheres to its traffic contract. The connection will be policed by the network at certain key interface points (typically the UNI and any inter-operator NNIs)—any cells that do not comply with the contract can be either discarded or tagged.

0013The Generic Cell Rate Algorithm (GCRA) (commonly known as a leaky bucket algorithm) has been defined to perform the policing function in ATM. The GCRA is generically specified through the use of two parameters—the Increment and Limit. The Increment specifies the anticipated period between conforming cells whilst the Limit specifies the allowed ‘relaxation’ from this increment for cells that arrive earlier than anticipated.

0014For a CBR connection the Increment is simply the reciprocal of the PCR. Due to the statistical effects of multiplexing sources together, jitter is introduced into a connection at all stages in the network (including at source as seen by the UNI). The allowable jitter, at each policed interface (e.g. a UNI or NNI), is termed the Cell Delay Variation Tolerance (CDVT). It is this parameter that is used for the GCRA Limit value in a CBR connection.

0015The generic GCRA algorithm can be summarised by the following pseudo-code:

0016<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>if (cell_arrival_time > TAT) /* TAT is Theoretical Arrival Time */</entry></row><row><entry>{</entry></row><row><entry> cell_conforms;</entry></row><row><entry> TAT = cell_arrival_time + INC,</entry></row><row><entry>}</entry></row><row><entry>else if (cell_arrival_time > TAT − Limit)</entry></row><row><entry>{</entry></row><row><entry> cell_conformant;</entry></row><row><entry> TAT = TAT + INC;</entry></row><row><entry>}</entry></row><row><entry>else</entry></row><row><entry> cell_non_conformant;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0017Thus for a CBR connection the minimum interval between successive cells is equal to 1/PCR−CDVT. Any cells outside of this, can be marked as non-conformant and subsequently discarded if desired.

0018A rt-VBR connection on the other-hand must conform to both the PCR and SCR components of its traffic contract. To police this, two GCRAs operating in parallel are used to ensure compliance (each cell must comply to both GCRAs for the cell to be conformant). The first GCRA polices the peak rate of the connection (thus Increment=1/PCR, Limit=CDVT) whilst the second polices for the sustained rate. The sustained rate GCRA rate algorithm is defined by the parameters (Increment=1/SCR and Limit=BT+CDVT) where BT is the Burst Tolerance of the connection and is calculated by: <br />BT=(MBS−1)(1/SCR−1/PCR)

0019AAL2 will be used primarily to support CBR Voice and VBR Voice traffic sources (although it can also support other delay sensitive traffic as well as data). It is important to note here the distinction between the individual AAL2 traffic sources and the underlying traffic class of the VCC bearer (CBR or rt-VBR VCC). In AAL2 it will be quite normal to use a CBR VCC to aggregate together a number of VBR Voice traffic sources or to use a rt-VBR VCC to support a mixture of CBR Voice and VBR Voice traffic sources.

0020A CBR Voice source is characterised by a periodic emission of constant rate data. CBR Voice sources include traditional 64 kb/s PCM (as typically carried by AAL1) or may arise through the use of constant rate CODECs with no silence suppression or down-speeding facility. CBR Voice sources are well understood and when multiple sources are multiplexed into a single VCC the aggregate will form a well-behaved CBR VCC connection (in an analogous manner to how CBR VCCs can be multiplexed together to form a CBR VPC). Congestion can therefore be prevented primarily through the use of appropriate Connection Admission Control (CAC) procedures.

0021VBR Voice is the term used to describe a traffic source generated by the use of a variable rate coding scheme and/or the utilisation of silence suppression. Generally, such sources still generate data at fixed periodic intervals, however now at each interval, the amount of data generated (the AAL2 packet payload length) can vary dynamically from packet to packet (down to zero during silent intervals). Such a voice source can therefore be characterised as an on-off source that has a variable bit rate during its on-period (albeit constrained to a small set of pre-defined CODEC rates) and an on-off distribution that is defined by the user's talkspurt behaviour. Unfortunately the multiplex of these sources no longer guarantees that the aggregate VCC obeys a well behaved CBR characteristic.

0022Assuming a nominal 50:50 talkspurt ratio each user spends approximately half their time in speech and the other half in silence. Therefore the mean occupancy on any bearer VCC will be half of that if silence suppression was not performed. However over any short time interval there is also a finite probability that fewer or greater than half the users will be active. These statistical fluctuations about the mean increase inversely with the number of users in the VCC pool. Therefore if the underlying bearer VCC is CBR with a capacity equating to the aggregate mean rate of the users, during periods where greater than half the users are active congestion will occur at the AAL2 multiplexing layer. Further due to the talkspurt characteristics, the duration of this congestion will typically be far longer than the normal cell-scale congestion that occurs naturally even when multiplexing pure CBR sources together. Simulations have shown that talkspurt congestion periods of several tens of milliseconds can arise when multiplexing multiple VBR Voice sources together over a low rate CBR VCC bearer connection.

0023There are a number of mechanisms to compensate for this potential talkspurt congestion. These include: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0024">Use of a very rigorous CAC mechanism to minimise the probability of talkspurt congestion occurring. However for a VCC multiplexing together a low number of sources this is likely to lead to a poor statistical multiplexing gain (poor loading utilisation on the link).</li><li id="ul0002-0002" num="0025">Minimise talkspurt activity by traffic engineering. As the community of users increases the effects of talkspurt activity diminishes (the statistical fluctuation from the mean is smaller for larger groups of users). Thus by maximising the number of sources in a VCC or by aggregating multiple VCCs into a VPC (and policing at the VPC level not the VCC level) the potential for congestion due to talkspurt activity is minimised.</li><li id="ul0002-0003" num="0026">Accept that congestion will occur and provide sufficiently large buffers (at both source and sink) to compensate for it.</li><li id="ul0002-0004" num="0027">Dynamically down-speed connections during periods of talkspurt congestion. Some (but not all CODECS) can dynamically vary the connection bit-rate between a number of defined rates. (For example an ADPCM connection might select between 32 and 16 kb/s).</li><li id="ul0002-0005" num="0028">Use a rt-VBR traffic contract to enable the VCC cell rate to vary its bandwidth to cater for fluctuations in the aggregate bit rate of the traffic sources.</li><li id="ul0002-0006" num="0029">Minimise congestion by delaying lower priority traffic (i.e. delay insensitive) in favour of voice traffic during periods of high talk activity.</li></ul></li></ul>

0030In practice due to the sheer diversity of network applications for which AAL2 is likely to be used a combination of all of these methods may be employed (although obviously not at the same time on a single VCC). This places some general requirements on an AAL2 packet scheduler process which may be summarised as:

0031It should provide sufficient buffering to absorb talkspurt congestion. <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0032">It should have the ability to monitor for the onset of congestion at source either at the individual VCC level or at the device level as a whole. Detection of such congestion mechanisms should where possible enable alarms to be generated that can subsequently be applied to the traffic generating CODECS to indicate that they should apply down-speeding (if possible).</li><li id="ul0004-0002" num="0033">It must have the ability to generate AAL2 VCC connections having either a CBR or a rt-VBR traffic profile.</li><li id="ul0004-0003" num="0034">To minimise the the delay for real time services in favour of non-real time services AAL2 packet level prioritisation should be supported.</li></ul></li></ul>

0035The permissible emission rate of cells for an ATM VCC is governed by its traffic contract. For a CBR VCC this contract is specified in terms of a Peak Cell Rate (PCR). For a rt-VBR VCC the emission of cells must comply with its PCR, as well as its Sustained Cell Rate (SCR) and Maximum Burst Size (MBS). In the context of an AAL2 packet scheduler compliance to the specified bearer VCC traffic contract may be achieved by explicit enforcement, implicitly or a mixture of both.

0036With explicit conformance the AAL2 packet scheduler explicitly shapes its traffic to ensure compliance with the underlying bearer VCC traffic contract. Thus if the instantaneous packet rate (arriving at the scheduler) is greater than the contracted bearer rate then the scheduling of completed ATM cell payloads still remains in contract and the excess packets will be buffered within the packet scheduler buffer area.

0037In contrast, where implicit conformance is employed, the packet scheduler takes no account of the underlying bearer traffic contract—it is simply event driven by the arrival of new AAL2 packets. In this scenario the packet scheduler is effectively anticipating that the arrival of packets in itself will implicitly conform to the underling traffic contract. In effect this approach is relying on the CAC procedures being sufficiently stringent such that the probability of the contract being broken without explicit conformance is very low. Effectively the established traffic contract has been defined such that even under the ‘worst-case’ packet arrival scenarios rate the instantaneous arrival rate is still within the bounds of the contract and thus no further timing controls are required by the packet scheduler. However due to the nature of talkspurt behaviour it is unlikely that for the majority of cases this implicit timing approach will yield an efficient solution since (especially for low rate CBR VCCs) the contracted PCR would tend to need to greatly exceed the nominal sustained rate of the connection (due to statistical fluctuations)—in effect this would lead to a very low utilisation of the available bandwidth. (One other option when using implicit timing controls within the packet scheduler is to use a subsequent ATM device to reshape the emitted traffic to the underlying traffic contract.)

0038Alternatively a hybrid timing approach can also be used within the packet scheduler. In this scenario explicit timing is used to ensure compliance to the PCR only. Whilst this is sufficient in itself for CBR VCCs for rt-VBR VCCs compliance to the SCR and MBS is not enforced. Instead in the hybrid approach the traffic contract is established such that providing the PCR is complied to the arrival of packets will not cause the SCR or MBS to be exceeded (in effect SCR and MBS are instead implicitly enforced by defining appropriate limits at connection setup.

0039The introduction of AAL2 has introduced a number of new issues relating to ATM scheduling and congestion control, and in particular the problem of efficient bandwidth utilisation. These arise primarily from the nature of the traffic sources, particularly voice, which AAL2 has been designed to support.

SUMMARY OF THE INVENTION

0040An object of the invention is to provide an improved method and apparatus for ATM packet scheduling.

0041According to a first aspect of the invention, there is provided a method of scheduling dispatch of packets containing constant bit rate (CBR) or real time variable bit rate (rt-VBR) at an ingress operation of multiplexing the packets into payloads of an asynchronous transfer mode (ATM) bearer virtual circuit connection, the method comprising controlling the packet dispatch so as to match the traffic characteristics of an underlying bearer channel

0042According to another aspect of the invention, there is provided method of scheduling dispatch of packets containing constant bit rate (CBR) or real time variable bit rate (rt-VBR) at an ingress operation of multiplexing the packets into payloads of an asynchronous transfer mode (ATM) bearer virtual circuit connection, the method comprising; <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0043">enabling a holdover timer having a pre-set period on receipt of a packet;</li><li id="ul0006-0002" num="0044">assembling common part sublayer payload data unit (CPS-PDU) comprising any unused octets from a previous packet partially dispatched, and whole packets in order of priority;</li><li id="ul0006-0003" num="0045">whenever said timer period expires before a said common part sublayer payload data unit is completed, packing the payload of that data unit with null data; and</li><li id="ul0006-0004" num="0046">controlling the packet dispatch so as to match the traffic characteristics of an underlying bearer channel.</li></ul></li></ul>

0047According to a further aspect of the invention, there is provided packet scheduler for dispatch of packets containing constant bit rate (CBR) or real time variable bit rate (rt-VBR) at an ingress operation of multiplexing the packets into payloads of an asynchronous transfer mode (ATM) bearer virtual circuit connection, the scheduler comprising; <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0048">a holdover timer having a pre-set period on receipt of a packet; <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0049">assembly means for assembling common part sublayer payload data unit (CPS-PDU) comprising any unused octets from a previous packet partially dispatched, and whole packets in order of priority and, whenever said timer period expires before a said common part sublayer payload data unit is completed, for packing the payload of that data unit with null data; and</li><li id="ul0009-0002" num="0050">means for controlling the packet dispatch so as to match the traffic characteristics of an underlying bearer channel.</li></ul></li></ul></li></ul>

0051The arrangement and method are optimised for AAL2 CBR and rt-VBR traffic. In particular, they offer optimum support for multiple priorities and provide well behaved traffic sources.

BRIEF DESCRIPTION OF THE DRAWINGS

0052A preferred embodiment of the invention will now be described with reference to the accompanying drawings in which:

0053<figref idref="DRAWINGS">FIG. 1</figref> illustrates the multiplexing of AAL2 minicells into ATM payloads;

0054<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart illustrating a preferred scheduling algorithm;

0055<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart illustrating a modified scheduling algorithm;

0056<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram of a scheduler embodying the algorithm of <figref idref="DRAWINGS">FIG. 2</figref>; and

0057<figref idref="DRAWINGS">FIG. 5</figref> is a schematic diagram of a scheduler embodying the modified algorithm of <figref idref="DRAWINGS">FIG. 3</figref>.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

0058Referring first to <figref idref="DRAWINGS">FIG. 1</figref>, which is introduced for explanatory and comparative purposes, this illustrates The multiplex of AAL2 mini-packets into ATM cell payloads is illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. By multiplexing multiple sources into the bearer payload, the cell assembly delay incurred is minimised compared to traditional ATM adaptation mechanisms whereby one VCC supports a single user only. Clearly, as the number of simultaneous users of the bearer VCC decreases the cell assembly delay will tend to increase. Therefore the AAL2 adaptation standard specifies a timer called the holdover timer that provides a bound for this delay under these conditions. Configurable on a per VCC basis, the holdover timer is reset at the start of each cell payload assembly process (i.e. the first octets of any AAL2 packet placed into the cell payload cause the timer to reset and the timing process to begin). If the timer expires prior to the complete assembly of a payload then at the point of expiry the partially filed payload is immediately dispatched. The general process of AAL2 segmentation and multiplexing will be familiar to those skilled in the art.

0059There now follows a description of exemplary embodiments of the invention. The description is in two parts: firstly algorithms are specified that define the idealised packet scheduler operation for a number of different traffic scenarios, secondly a specific implementation of one aspect of the invention is provided.

0060The algorithms are based on extended versions of the standard GCRA algorithm. The algorithms are optimised such that the resultant traffic sources will behave exactly as defined by their traffic contracts and thus always pass any resultant policing function

0061A preferred packet scheduling algorithm is illustrated in the flow chart of <figref idref="DRAWINGS">FIG. 2</figref>. This algorithm is suitable for scheduling AAL2 packets up to a maximum rate equal to the PCR. Since the algorithm explicitly enforces to the PCR only, then the algorithm is suitable for scheduling to either a CBR traffic contract or a rt-VBR traffic contract (providing the SCR and MBS are implicitly conformed to via the CAC algorithm as previously discussed).

0062Prior to use the algorithm is configured using two parameters the minimum inter-cell period Tmin (where Tmin=1/PCR) and the Holdover parameter. (The Holdover timer value is greater than or equal to Tmin) If a value of zero is programmed for Tmin then the packet scheduler is free to emit payloads whenever they have been completed irrespective of the inter-cell duration (i.e. the Tmin timer is always maintained in an expired state). Additionally and/or alternatively a null value for the holdover value may be specified: this indicates that the packet scheduler should emit only completed (full) ATM SDUs irrespective of cell assembly delay (i.e. the Holdover Timer is always maintained in the expired state).

0063The algorithm is initialised when the VCC becomes active. In normal operation it is designed to schedule either completed ATM cell payloads (either at, or after, the Tmin timer expiry) unless the Holdover timer also expires at which instance a partially assembled cell will be emitted forcibly (any unused payload of the ATM cell is padded with the standard AAL2 pad byte as per the standard).

0000Packet Level Priority

0064The algorithm may be used in applications whereby all received packets are assumed to be of equal priority and in this scenario, packets are scheduled strictly in accordance to their arrival (i.e. first come first served). Alternatively the algorithm may be extended to support any number of levels of packet priority and in this scenario the scheduling of a packet is a function of its arrival order, its priority class and the priority scheduling scheme implemented.

0065The algorithm may be used to schedule to any priority mechanism including strict sense priority (high priority packets are always scheduled before lower priority packets), weighted fair queuing (where each priority class gets equal access to the scheduler albeit in direct proportion to its mean data rate) or statistical priority (whereby one queue is generally prioritised over another albeit the lower priority queue is still granted the scheduler in preference to the higher priority queue according to a user configured statistical priority). Irrespective of priority mechanism the following rules for the scheduling of packets and thus the assembly/dispatch of ATM SDUs are implemented: <ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0000"><ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0066">The arrival of any packet irrespective of priority is used to initiate the holdover timer (if not already set).</li><li id="ul0011-0002" num="0067">When scheduling a CPS-PDU it is assembled in the following order: <ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0068">First any unused octets from a packet already partially sent in the previous CPS-PDU are used. Throughout this document we refer to the unconsumed octets of such a straddling packed as the straddling or straddled octets.</li><li id="ul0012-0002" num="0069">Next whole packets are scheduled according to the priority mechanism implemented. For example with strict sense priority packets from the highest priority queue are consumed before the next highest and so on. <br /> Finally any unused payload is padded with null data to complete the CPS PDU. </li></ul></li></ul></li></ul>

0070The detailed operation of the algorithm is described by the use of following pseudo code and is illustrated by the flow chart of <figref idref="DRAWINGS">FIG. 2</figref>.

0000Pseudo Code

0071<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>packet_scheduler(Tmin,Holdover)</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> TAT_Tmin = 0; /* TAT is Theoretical Arrival Time */</entry></row><row><entry /><entry> Holdover_Limit = NOT_SET;</entry></row><row><entry /><entry> repeat while VCC Connection is ACTIVE</entry></row><row><entry /><entry> {</entry></row><row><entry /><entry>  do</entry></row><row><entry /><entry>   {</entry></row><row><entry /><entry>   poll for packet arrival;</entry></row><row><entry /><entry>     if packet received</entry></row><row><entry /><entry>   {</entry></row><row><entry /><entry>    if (octets_in_queues + straddling_octets = 0)</entry></row><row><entry /><entry>     Holdover_Limit = current_time + Holdover;</entry></row><row><entry /><entry>      queue packet;</entry></row><row><entry /><entry>   }</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>  while ( (straddling_octets + octets_in_queues < 47 OR</entry></row><row><entry /><entry>  time < TAT−Tmin)</entry></row><row><entry /><entry>AND</entry></row><row><entry /><entry>   (time < Holdover_Limit) );</entry></row><row><entry /><entry>  assemble and dispatch CPS-PDU</entry></row><row><entry /><entry>  TAT_Tmin = time + Tmin;</entry></row><row><entry /><entry>  if (straddling_octets + octets_in_queues <> 0)</entry></row><row><entry /><entry>   HoldoverLimit = time + Holdover</entry></row><row><entry /><entry> /* reset if the last packet straddled the cell */</entry></row><row><entry /><entry>  else</entry></row><row><entry /><entry>   HoldoverLimit = NOT-SET;</entry></row><row><entry /><entry> } /* end repeat while</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0072An alternative algorithm is illustrated in flow chart form in <figref idref="DRAWINGS">FIG. 3</figref>.

0073In this algorithm the packet scheduler is extended to explicitly enforce compliance to the SCR and the MBS as well as the PCR. Each VCC is initialised with 4 parameters Tmin, the Holdover value the sustained inter-cell period Tsus (where Tsus=1/SCR) and the BT (which acts as the limit of the SCR component of the policing function as previously described). Note that Tmin&lt;=Tsus&lt;=Holdover.

0074The scheduler emits completed cells providing the inter-cell period is compliant to both the PCR and the SCR limits. Only completed payloads are dispatched unless the holdover timer expires in which case a partially completed cell will be emitted. Null values may be configured for the Holdover. Additionally or alternatively a null value may be specified for the SCR components of the VCC (Tsus and BT) in which case the scheduler defaults back to a PCR scheduler only and finally a null values may be specified for the SCR values and the PCR values and the scheduler becomes event driven as before. (Note a null value for the PCR and a non-null value for the Tsus/BT is a non allowed condition).

0000Packet Priority

0075Again the algorithm of <figref idref="DRAWINGS">FIG. 3</figref> can be used either to support a single priority level or multiple levels. The exact implementation can be tailored to the priority mechanism employed. In this example two levels of priority are defined—high and low. Strict sense priority is used between the levels and the following rules are obeyed: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0076">Strict sense priority is used—a low priority packet is never scheduled if there are any high priority packets in the queue.</li><li id="ul0014-0002" num="0077">As soon as the number of octets in the high priority queue (plus any straddled octets irrespective of their priority exceeds 47 a cell may be dispatched providing it complies to both the PCR and the Limit of the SCR.</li><li id="ul0014-0003" num="0078">After expiry of the SCR sustained rate timer, low priority packets are also used to complete the payload. i.e. low priority packets never contribute to a burst.</li></ul></li></ul>

0079If the holdover expires then the cell will be dispatched with padding.

0080Both low and high priority packets are used to initiate the holdover timer. <br />Tmin&lt;=Tsus&lt;=Holdover

0081Although the a two level strict sense priority paradigm is illustrated in the following pseudo code and the flow chart of <figref idref="DRAWINGS">FIG. 3</figref> those skilled in the art will recognise that the algorithm may be readily extended to support further levels or priority and/or a differing priority scheme.

0082The pseudo code for the algorithm of <figref idref="DRAWINGS">FIG. 3</figref> is given below.

0000Pseudo Code

0083<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>packet_scheduler(Tmin,Tsus,Holdover,BT) /* BT = (MBS−1)(1/SCR − 1/PCR) */</entry></row><row><entry>{</entry></row><row><entry> TAT_Tmin = 0;</entry></row><row><entry> TAT_Tsus = 0;  /* Sustained rate of the SCR timer</entry></row><row><entry> Limit_Tsus = 0;  /* Limit of the SCR element of the traffic contract</entry></row><row><entry> Holdover_Limit = NOT_SET;</entry></row><row><entry> repeat while VCC Connection is Active</entry></row><row><entry> {</entry></row><row><entry>     do</entry></row><row><entry>     {</entry></row><row><entry>    poll_for_packet_arrival;</entry></row><row><entry>   if packet received</entry></row><row><entry>    {</entry></row><row><entry>      if octets_in_queues + straddling_octets = 0 /* Holdover timer is</entry></row><row><entry>kicked off by */</entry></row><row><entry>        Holdover_Limit = time + Holdover;</entry></row><row><entry>   /* low priority traffic as well */</entry></row><row><entry>      queue_packet;</entry></row><row><entry>     }</entry></row><row><entry>      } while ( (straddled_octets + octets_in_high_priority queue < 47 OR</entry></row><row><entry>time<</entry></row><row><entry>           maxof(TAT−Tmin,Limit_Tsus)) AND (time <</entry></row><row><entry>Holdover_Limit) AND</entry></row><row><entry>        (straddled_octets + octets_in_both_queues < 47 OR time < TAT−</entry></row><row><entry>TSus))</entry></row><row><entry>   assemble and dispatch CPS PDU;</entry></row><row><entry>    if (straddling_octets + octets_in_queues <> 0)</entry></row><row><entry>    HoldoverLimit = time + Holdover</entry></row><row><entry>    else</entry></row><row><entry>    HoldoverLimit = NOT_SET;</entry></row><row><entry>    TAT_Tmin = time + Tmin;</entry></row><row><entry>    if (time >= TAT_Tsus)</entry></row><row><entry>     TAT_Tsus = time + TAT_Tsus /* Sets Tsus outside of a burst */</entry></row><row><entry>    else</entry></row><row><entry>     TAT_Tsus = TAT_Tsus + Tsus; /*Sets Tsus within a burst */</entry></row><row><entry>   Limit_Tsus = TAT_Tsus − BT;</entry></row><row><entry> } /* end repeat while</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0084<figref idref="DRAWINGS">FIGS. 4 and 5</figref> depict in schematic form packet schedulers embodying the AAL2 packet scheduler algorithms previously described. The embodiment described logically provides one instance of an AAL2 packet scheduler per AAL2 bearer VCC. In this embodiment two levels of packet priority are supported and each scheduler schedules ATM payloads up to a rate equal to the PCR (i.e. the minimum period between successive cells for a VCC is equal to Tmin). Thus the algorithm may be used to support either CBR VCCs or rt-VBR VCCs (in the latter case implicit conformance of the SCR and MBS parameters is assumed through the use of an appropriate CAC algorithm.

0085The scheduler embodiment to be described has the following general characteristics: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0086">The traffic scheduler is capable of supporting multiple AAL2 VCCs. In this example 512 VCCs—but this is readily extended. Each AAL2 VCC is treated fairly with respect to the other AAL2 VCCs.</li><li id="ul0016-0002" num="0087">For each AAL2 VCC the user may configure the Tmin (1/PCR) and the Holdover values. If a null is programmed for the Tmin Value then the packet scheduler is free to emit payloads whenever they have been completed irrespective of the inter-cell duration. A null for the Holdover Value may also (or alternatively) be specified—this defines that the packet scheduler emits completed (full) ATM SDUs only, irrespective of the cell assembly delay</li><li id="ul0016-0003" num="0088">Per AAL2 VCC, the scheduler will emit completed (assembled) ATM cell payloads at a maximum rate up to the pre-defined PCR of that bearer.</li></ul></li></ul>

0089Per AAL2 VCC, holdover timers are implemented. In this embodiment Holdover values between approximately 100 us and 125 ms are supported (although this may be readily extended). To minimise the implementation requirements—the resolution of the holdover timer decreases as the holdover timer increases. <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0000"><ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0090">The packet scheduler supports two priorities—a separate queue (per priority) per AAL2 VCC is maintained. The number of priorities supported may be readily extended.</li><li id="ul0019-0002" num="0091">Strict sense priority is used to select between the two priority queues within a single AAL2 VCC packet scheduler. (i.e. the priority mechanism is only applied within a VCC and not across the aggregate range of the total set of VCCs—thus the fact that one VCC has a number of high priority packets awaiting scheduling would have no influence over the scheduling decision of another AAL2 VCC even though it might only contain low priority packets). <br /> General Operation </li></ul></li></ul></li></ul>

0092The packet scheduler is controlled through the use of two timed events: the Holdover Timer Event and the Tmin Timer Event. Each timer event may be in one of three possible states: Not Set (no timer in operation), Set (with an associated expiry time) and Expired (a set time has come and gone). The operation of the scheduler follows the behaviour described below: <ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0000"><ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0093">On initialisation of the AAL2 VCC the Holdover Timer Event is Not Set. The Tmin Timer Event is set to EXPIRED.</li><li id="ul0021-0002" num="0094">On detection of the first packet arrival for the VCC (either high or low priority with both queues empty) a new Holdover Timer Event is set (equal to the sum of the current time and the programmed Holdover Value parameter if not null). A null Holdover value does not set an event.</li><li id="ul0021-0003" num="0095">On detection of either of the following conditions, the AAL-2 packet scheduler schedules the emission of a CPS-PDU:</li><li id="ul0021-0004" num="0096">The Tmin Timer Event has Expired and the number of unscheduled octets in the VCC queue (aggregated over both the high and low priority queues) is greater than or equal to 47. (Note this includes both packet header and packet payload octets)</li></ul></li></ul>

0097The Holdover Timer Event has Expired. <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0000"><ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0098">After scheduling a new CPS-PDU, if the Tmin Timer value is configured as null the Tmin Timer Event remains in the Expired state, otherwise it is set (equal to the sum of the current time and the Tmin Timer Value parameter). The Holdover Timer Event is also set (if not null) if there remain any further unscheduled octets within the VCC queues (either high or low priority)—if not then the Holdover Timer Event is set to Not Set until the detection of the next packet arrival for that VCC.</li></ul></li></ul>

0099Upon detection of the necessary conditions in 3 above (and not prior to this) the scheduled ATM CPS PDU is assembled and dispatched. The CPS PDU is assembled in the following order: <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0000"><ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0100">Firstly, any unused octets from a packet (high or low priority) that straddles over from the previous ATM CPS-PDU are used (i.e. finish last unfinished packet from either queue).</li><li id="ul0025-0002" num="0101">Secondly, octets are used from the head of the (unscheduled) high priority queue until the payload is completed or the queue consumed.</li><li id="ul0025-0003" num="0102">Thirdly, octets are used from the head of the (unscheduled) low priority queue until the payload is completed or the queue consumed.</li></ul></li></ul>

0103Finally any unused payload bytes will be filled with the AAL2 padding byte.

0000Implementation Details

0104The detailed implementation of the packet scheduler process embodying the algorithm of <figref idref="DRAWINGS">FIG. 2</figref> is now described. A block diagram of the implementation is shown in <figref idref="DRAWINGS">FIG. 4</figref>. The operation of the packet scheduler is distributed across a number of processes and controlled through the use of a number of common key stores.

0105The Control Processor <b>41</b> is used to configure and monitor the behaviour of the per AAL2 VCC packet schedulers. Prior to initialisation of an AAL2 VCC, under user control, the Control Processor configures the parameters of the VCC by programming the relevant location within the Scheduler Parameter Store <b>42</b>. The Scheduler Parameter Store <b>42</b> contains one location per VCC which maintains a list of the per VCC connection parameters that control the operation of the packet scheduler. Although normally setup upon VCC establishment they may also be modified during the lifetime of the VCC connection. The following fields are programmable per AAL2 VCC.

0106The Tmin Val (Tmin Timer Value) field specifies the duration of the Tmin timer. <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0000"><ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0107">The Tmin Res (Tmin Timer Resolution) field specifies the resolution of the Tmin Timer. The two fields are used together to fully specify the Tmin Timer—their use will be explained fully later.</li></ul></li></ul>

0108The H/O Val (Holdover Value) field specifies the duration of the Holdover timer. <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0000"><ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0109">The H/O Res (Holdover Resolution) field specifies the resolution of Holdover Timer. The two fields are used together to fully specify the Holdover Timer—their use will be explained fully later.</li></ul></li></ul>

0110Additionally to setup a new VCC the Control Processor <b>41</b> initalises the per VCC status parameters within the Scheduler Status Store <b>43</b>. This store maintains the dynamic per AAL2 VCC status parameters that enable the control of the packet scheduling processes. This store provides the key interface for controlling the interaction between the various subprocesses. The following fields are maintained per VCC: <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0000"><ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0111">The Q-Hi Hd and Q-Hi TI (High Priority Queue Head and Tail Pointers). Incoming packets are stored in the packet payload memory until they are scheduled. A common memory is used to provide a shared storage area and the individual per VCC per priority queues are configured using linked list structures. The Q-Hi Hd and Q-Hi TI are used to point to the head and tail locations of the high priority VCC queue. A null value indicates that there are no packets within that queue.</li><li id="ul0031-0002" num="0112">The Q-Lo Hd and Q-Lo TI (Low Priority Queue Head and Tail Pointers). As above but for the low priority queue.</li><li id="ul0031-0003" num="0113">The Q-Hi Ctr (High Priority Queue Counter). This field maintains a count of the total number of octets in the high priority queue that have yet to be scheduled/assembled into a CPS-PDU. The count includes both payload and header octets and includes any straddled octets.</li></ul></li></ul>

0114The Q-Lo Ctr (Low Priority Queue Counter). As above but for the low priority queue. <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0000"><ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0115">The H/O Set (Holdover Timer Set) flag is used to indicate whether a Holdover Timer value is currently defined for the AAL2 VCC.</li><li id="ul0033-0002" num="0116">The H/O Exp (Holdover Timer Expired) flag indicates that the Holdover Timer value has expired (timed-out).</li><li id="ul0033-0003" num="0117">The Tmin Exp (Tmin Timer Expired) flag indicates that the Tmin timer value has expired (timed-out).</li><li id="ul0033-0004" num="0118">The Rem (Remaining) field is used in the process of scheduling packets that straddle across at least one CPS-PDU boundary. In normal operation, this field is used to indicate (for the straddled packet) how many octets remain to be scheduled in the CPS-PDU currently under assembly. This value includes both payload and header bytes.</li><li id="ul0033-0005" num="0119">The Hi/Lo (High/Low) bit is used to indicate whether the straddled packet is queued on the high or low priority packet queues.</li><li id="ul0033-0006" num="0120">The SN (Sequence number) field is used to record the modulo-2 sequence number that is transmitted within the STF field of an AAL2 CPS PDU. The fields is incremented every time a CPS-PDU is assembled by the scheduler.</li></ul></li></ul>

0121At initialisation the control processor configures the status parameters to the following values: Q-Hi Hd=0 (NULL), Q-Hi TI=0 (NULL), Q-Lo Hd=0 (NULL), Q-Lo TI=0 (NULL), Q-Hi Ctr=0, Q-Lo Ctr=0; H/O Set=0 (Not SET), H/O Exp=0, Tmin Exp=1 (SET); Rem=0; Hi/Lo=0, SN=0.

0122Once initialised the AAL2 packets may be received (and subsequently scheduled) by the packet scheduler <b>44</b>. Incoming packets are terminated by the Incoming Packet Process <b>45</b>. For each received packet the Incoming Packet process determines the outgoing bearer VCC to which the packet is destined and the priority of the received packet. The outgoing VCC is determined by the a connection identifier for the packet whilst the priority is determined by a subset of the packet identifier, the packet type (as indicated by the UUI field within the AAL2 header), and a configurable dynamic call state for the connection. Optimally the packet queues are maintained using a shared dynamic buffer and therefore the incoming packet process uses a series of linked lists—one linked list per priority per bearer VCC. Thus as the incoming packet is received a free slot in the buffer is chosen (via a free list) and the appropriate linked list updated (including updating the necessary head and tail pointers within the Scheduler Status Store). Additionally, Q Hi-Ctr (or Q-Lo Ctr) is incremented by the length of the received packet. Finally, if prior to the receipt of this packet, both the Hi and Lo priority queues were empty for that VCC then a new Holdover Timer Event will be set (unless the Holdover Value is NULL). To set a Holdover Timer for the VCC the Incoming Packet Process raises a flag to the Timer En-Queuing Process <b>46</b> indicating both the identification of the VCC and the Event Type.

0123The timing of events is performed using a set of Event Timer ring buffers <b>48</b> in conjunction with an Event Store <b>47</b>. Each location in an Event Timer ring buffer represents a single time period whilst each location in the Event Store represents a particular event, either the expiry of a Tmin Timer or the expiry of a Holdover Timer, determined by the timer expiry process <b>49</b>. Therefore to set a new timed event it is simply necessary to associate the relevant Event Store location with the relevant Event Timer location. A doubly linked list mechanism is employed to achieve this. The Event Timer ring buffer maintains a set of head and tail pointers (one for each time period)—whilst all the events due to expire at that period are chained together in the Event Store. A doubly linked list is used as this enables events to be simply de-queued prior to their natural expiry—a requirement since for the majority of cases the CPS-PDU will be fully assembled before the Holdover timer expires. An F (first) bit field is associated with each Event Store location—if set this indicates that the Event is the first event within the chain and therefore that the Last field is pointing back to the Event Timer location—again this is necessary to be able to dequeue events at random within the list.

0124Since there are two events per VCC (Tmin Expiry and Holdover Expiry) the Event Store consists of 2×number of AAL2 VCCs. Each location explicitly represents one event (i.e location <b>1</b> represents VCC1 Tmin Timer expiry, location <b>2</b> represents VCC2 Holdover Timer expiry, location <b>3</b> represents VCC2 Tmin Timer expiry and so on).

0125Strictly it is only Holdover events that are de-queued prior to their natural expiry and therefore the storage requirements of the Event Store may be optimised by providing two Event Stores—one for Tmin expiry (which needs only to be singly linked) and one for Holdover expiry (that needs to be doubly linked as described).

0126The time period covered by an Event Timer is equal to the number of its memory locations multiplied by the timing resolution of that timer. To enable the process to support a wide timing range without recourse to an excessively large store, multiple Event Timers may be supported in parallel. Each Event Timer supports a differing timing resolution. For example three Event Timers containing 128 locations can be used to support a timing range between 0 and 128 ms in the following manner: <ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0127">Event Timer <b>1</b>: Resolution 10 μs—Range 0 to 1.28 ms</li><li id="ul0034-0002" num="0128">Event Timer <b>2</b>: Resolution 100 μs—Range 0 to 12.8 ms</li><li id="ul0034-0003" num="0129">Event Timer <b>3</b>: Resolution 1 ms—Range 0 to 128 ms</li></ul>

0130Thus each Event is associated with the appropriate Timer according to its range and resolution.

0131Therefore to set the Holdover Timer, the Timer Enqueuing process <b>46</b> reads the appropriate location of the Scheduler parameter store <b>42</b> to determine its value (H/O Val) and resolution (H/O Res)—the current process time is added to the H/O Val to determine the location of this event within the Event Timer ring buffer whilst the H/O Res indicates which of the Event Timers to use. The new timer is then set by adding the event to the appropriate linked list and the H/O Set bit is Set within the Scheduler status store to indicate that a holdover timer is in operation for that VCC.

0132Working in parallel with the Timer Enqueuing Process is the Timer Expiry Process <b>49</b>: This process controls the operation of the Event Timers/Event Stores. Each of the three Event Timer Stores operate in parallel (any contention between the three stores may be resolved by giving priority to the finer resolution timer). At each time interval the current time is incremented and thus increments the pointer to the next Event Timer location. At this time the process dequeues the associated linked-list—as each event is de-queued the process simply sets the relevant expiry bit in the Scheduler Status Store (e.g. if the timer dequeues a Holdover expiry event for VCC3 then it sets the H/O Exp flag in the scheduler status store for VCC3). Since the number of events that are queued for any time period can vary, then the time to perform the dequeuing process will also vary. Therefore there is an overall control process that is used to determine the correct time interval at which to advance to the next memory location. If for any memory location the dequeuing process takes longer than the time that that location actually represents then the sub-process continues to dequeue events (at that location and subsequent locations) at its maximum rate until the process catches up with ‘real’ time).

0133The Packet Scheduler Process <b>44</b> is used to constantly monitor the Scheduler Status store <b>43</b> in order to determine when it should schedule the assembly of a CPS-PDU. Its function is to detect the condition {H/O Exp=SET OR {Tmin Exp=SET AND (Q Hi+Q Lo)>=47). Upon detection it triggers the CPS-PDU Assembly Sub-process to be described with the identity of the scheduled VCC. In addition the packet scheduler sub-process does the following tasks <ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0000"><ul id="ul0036" list-style="none"><li id="ul0036-0001" num="0134">If necessary (i.e H/O Exp=0, H/O Val< >NULL) it triggers the Timer Dequeuing Process to dequeue an unexpired Holdover Timer.</li><li id="ul0036-0002" num="0135">If Tmin Val< >0 it will trigger the Timer Enqueueing Process to recalculate and re-queue the Tmin Timer and resets the Tmin Exp flag.</li><li id="ul0036-0003" num="0136">Further if after assembly of the just scheduled CPS-PDU, there are remaining unscheduled octets for that VCC (within either of the two queues) it will trigger (to the Timer Enqueuing Process) the queuing and recalculation of a new Holdover Timer (and reset the H/O Exp flag). If no unscheduled octets remain it simply resets the H/O Set flag.</li></ul></li></ul>

0137Finally, the CPS-PDU Assembly Process <b>50</b> triggered by the packet scheduler process is used to assemble the CPS PDU for the scheduled VCC. The CPS PDU is assembled in the following order: <ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0000"><ul id="ul0038" list-style="none"><li id="ul0038-0001" num="0138">firstly use up any remaining octets from a straddled packet (the presence of a straddled packet, how many straddled octets remain and from which priority queue to take them from, is indicated by the Rem and Hi/Lo fields in the manner already described.</li><li id="ul0038-0002" num="0139">secondly octets are scheduled from the high priority queue until either the queue is exhausted of unscheduled octets or the CPS PDU is completed.</li><li id="ul0038-0003" num="0140">thirdly octets are scheduled from the low priority queue until either the queue is exhausted of unscheduled octets or the CPS PDU is completed. <br /> finally padding bytes are used to complete any empty payload space </li></ul></li></ul>

0141As the CPS-PDU Assembly Process assembles the CPS-PDU it dequeues any fully consumed packets (and adjusts the appropriate head pointer within the Scheduler Status store). In addition using the remaining and SN fields for the VCC it generates the STF octet. Finally at the end of the assembly process the Q-Hi Ctr, Q-Lo Ctr, SN, Rem and H/L fields are recomputed.

0142An alternative exemplary scheduler construction is illustrated schematically in <figref idref="DRAWINGS">FIG. 5</figref>. In this example a full rt-VBR scheduler is implemented which explicitly schedules according to both the SCR and PCR elements of the traffic contract The implementation of such a scheduler is shown in <figref idref="DRAWINGS">FIG. 6</figref>. The scheduler works as per the previous example with the following exceptions: <ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0000"><ul id="ul0040" list-style="none"><li id="ul0040-0001" num="0143">For each AAL2 VCC the user configures the following parameters: Tmin (1/PCR), TSus (1/SCR), BT (burst tolerance=[MBS−1]*[1/SCR−1/PCR]) and the Holdover values.</li></ul></li></ul>

0144The following condition holds true: Tmin&lt;Tsus&lt;Holdover

0145Null values may be programmed for the: <ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0000"><ul id="ul0042" list-style="none"><li id="ul0042-0001" num="0146">Holdover Value: In which case the packet scheduler will emit only full ATM SDUs irrespective of the cell assembly delay.</li><li id="ul0042-0002" num="0147">A null TSus and (by implication BT) in which case the packet scheduler can emit packets indefinitely at the full PCR (i.e the VCC reverts to CBR behaviour).</li><li id="ul0042-0003" num="0148">A null PCR value in which case the packet scheduler may emit ATM SDUs as soon as sufficient data is present irrespective of the inter-cell duration. (Note the TSus are also set NULL in this case). <br /> General Operation </li></ul></li></ul>

0149The packet scheduler is now controlled through the use of four timed events. In addition to the Holdover Timer Event and the Tmin Timer Event two new Events are added—the Tsus Timer (which is used to time conformance to the actual SCR) and the Tsus-Limit Timer Event (which is used to determine the limit on the SCR—i.e. how much burst may be tolerated). Again each timer event may be in one of three possible states: Not Set (no timer in operation), Set (with an associated expiry time) and Expired (a set time has come and gone). The operation of the scheduler follows the behaviour described below: <ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0000"><ul id="ul0044" list-style="none"><li id="ul0044-0001" num="0150">On initialisation of the AAL2 VCC the Holdover Timer Event is Not Set. The Tmin Timer Event, Tsus Timer Event and Tsus-Limit Timer Event is set to EXPIRED.</li><li id="ul0044-0002" num="0151">On detection of the first packet arrival for the VCC (either high or low priority with both queues empty) a new Holdover Timer Event is set (equal to the sum of the current time and the programmed Holdover Value parameter if not null). A null Holdover value does not set an event.</li><li id="ul0044-0003" num="0152">On detection of either of the following conditions, the AAL-2 packet scheduler schedules the emission of a CPS-PDU:</li><li id="ul0044-0004" num="0153">The Tmin Timer Event and the Tsus-Limit Timer Event have both Expired and the number of unscheduled octets in the high priority VCC queue (plus any unscheduled octets in a straddling packet irrespective of priority) is greater than or equal to 47. (Note this includes both packet header and packet payload octets).</li><li id="ul0044-0005" num="0154">The Tsus Timer Event has Expired and the number of unscheduled octets in both the high and low priority VCC queues (plus any unscheduled octets in a straddling packet irrespective of priority) is greater than or equal to 47. (Note this includes both packet header and packet payload octets).</li><li id="ul0044-0006" num="0155">The Holdover Timer Event has Expired. <ul id="ul0045" list-style="none"><li id="ul0045-0001" num="0156">After scheduling a new CPS-PDU, if the Tmin Timer value is configured as null the Tmin Timer Event remains in the Expired state, otherwise it is set (equal to the sum of the current time and the Tmin Timer Value parameter). The Holdover Timer Event is also set (if not null) if there remain any further unscheduled octets within the VCC queues (either high or low priority)—if not then the Holdover Timer Event is set to Not Set until the detection of the next packet arrival for that VCC. If the Tsus Timer Value is configured as null then both the Tsus Timer Event and the Tsus-Limit Timer Event remain in the expired state. Otherwise the Tsus Timer is set to either the sum of the current time plus the Tsus Timer Value (if the Tsus timer has expired indicating that the just scheduled cell did not contribute to a burst) or to the sum of the currently set Tsus Timer Event plus the Tsus Timer Value (if the Tsus Timer Event has not yet expired i.e the previous scheduled cell has contributed to a burst). In either case the Tsus-Limit Timer Event is then set to the sum of the newly set Tsus Timer Event minus the BT.</li></ul></li></ul></li></ul>

0157Upon detection of the necessary conditions in 3 above (and not prior to this) the scheduled ATM CPS PDU is assembled and dispatched. The CPS PDU is assembled (as in the previous algorithm in the following order): <ul id="ul0046" list-style="none"><li id="ul0046-0001" num="0000"><ul id="ul0047" list-style="none"><li id="ul0047-0001" num="0158">Firstly, any unused octets from a packet (high or low priority) that straddles over from the previous ATM CPS-PDU are used (i.e. finish last unfinished packet from either queue).</li><li id="ul0047-0002" num="0159">Secondly, octets are used from the head of the (unscheduled) high priority queue until the payload is completed or the queue consumed.</li><li id="ul0047-0003" num="0160">Thirdly, octets are used from the head of the (unscheduled) low priority queue until the payload is completed or the queue consumed.</li></ul></li></ul>

0161Finally any unused payload bytes will be filled with the AAL2 padding byte.

0000Implementation Details

0162The detailed implementation of the packet scheduler process embodying the algorithm of <figref idref="DRAWINGS">FIG. 3</figref> is now described with reference to the block diagram of <figref idref="DRAWINGS">FIG. 5</figref>. The operation of the packet scheduler is substantially identical to that previously described with reference to <figref idref="DRAWINGS">FIG. 4</figref>, but with the following exceptions:

0163The Scheduler Parameter Store <b>52</b> contains the following additional per VCC fields. <ul id="ul0048" list-style="none"><li id="ul0048-0001" num="0000"><ul id="ul0049" list-style="none"><li id="ul0049-0001" num="0164">The Tsus Val (Tsus Timer Value) field specifies the duration of the Tsus (SCR) timer.</li><li id="ul0049-0002" num="0165">The Tsus Res (Tsus Timer Resolution) field specifies the resolution of the Tsus Timer.</li><li id="ul0049-0003" num="0166">The BT Val (Burst Tolerance Value) field specifies the duration of the burst tolerance timer.</li><li id="ul0049-0004" num="0167">The BT Res (Burst Tolerance Resolution) field specifies the resolution of BT Timer.</li></ul></li></ul>

0168The following per VCC status parameters are added to the Scheduler Status Store <b>53</b>: <ul id="ul0050" list-style="none"><li id="ul0050-0001" num="0000"><ul id="ul0051" list-style="none"><li id="ul0051-0001" num="0169">The Tsus Exp (Tsus Timer Expired) flag indicates that the Tsus Timer value has expired (timed-out).</li><li id="ul0051-0002" num="0170">The Tsus-Limit Exp (Tsus-Limit Exp Timer Expired) flag indicates that the Tsus-Limit (burst tolerance) timer value has expired (timed-out).</li></ul></li></ul>

0171At initialisation the control processor configures the additional status parameters to the following values: Tsus Exp=1 (SET); Tsus-Limit Exp=1 (SET).

0172Once initialised the AAL2 packets may be received (and subsequently scheduled) by the packet scheduler.

0173The operation of the Incoming Packet Process is analogous to the previous description.

0174The timing of events is again performed using the combination of Event Timer ring buffers and the Event Store. The Event Store is however expanded to include two further per VCC Events (the expiry of the Tsus Timer and the expiry of the Tsus-Limit Timer). Since there are four events per VCC the event store now consists of 4×number of AAL2 VCCs.

0175The Holdover Timer and Tmin Timer events are established exactly as before. The Tsus and Tsus-Limit timers are always established in parallel. To set these values the Enqueueing Process firstly determines if the Tsus timer has expired or not. If it has not expired then it will dequeue the current timer value (either directly or in association with the Dequeuing process), temporarily recording its value to use in the subsequent computation) and set a new Tsus value equal to the previous Tsus Timer plus the Tsus Value. If it has already expired then it will set the new Tsus Timer to the sum of the current time plus the Tus Value. In either case it temporarily records this new value and uses it to set the new TSus-Limit timer equal to the Tsus Timer minus the BT Val. If the relevant parameters (BT, TSus) are configured using different resolutions then the Enqueuing process should convert to a common resolution, perform the calculation and determine the most appropriate Ring Buffer for its storage.

0176The Timer Expiry Process: works identically as before except it now dequeues and sets the appropriate expiry bit for four event types.

0177The Packet Scheduler Process now detects the following conditions in order to schedule an ATM SDU {H/O Exp=SET OR {Tmin Exp=SET AND Tsus-Limit=SET AND (Remaining+Q Hi*)>=47) OR {QHi+QLo>=47 AND Tsus=SET) Upon detection it triggers the CPS-PDU Assembly Sub-process to be described with the identity of the scheduled VCC. In addition the packet scheduler subprocess does the following tasks <ul id="ul0052" list-style="none"><li id="ul0052-0001" num="0000"><ul id="ul0053" list-style="none"><li id="ul0053-0001" num="0178">If necessary (i.e H/O Exp=0, H/O Val< >NULL) it triggers the Timer Dequeuing Process to dequeue an unexpired Holdover Timer.</li><li id="ul0053-0002" num="0179">If Tmin Val< >0 it will trigger the Timer Enqueuing Process to recalculate and requeue the Tmin Timer and resets the Tmin Exp flag.</li><li id="ul0053-0003" num="0180">If Tsus Val< >0 it will trigger the Timer Enqueuing Process to recalculate and requeue the Tsus Timer and Tsus-Limit Timer (and resets the Tsus Exp flag and Tsus_Limit_Exp flag}.</li><li id="ul0053-0004" num="0181">Further if after assembly of the just scheduled CPS-PDU, there are remaining unscheduled octets for that VCC (within either of the two queues) it will trigger (to the Timer Enqueuing Process) the re-queuing and recalculation of a new Holdover Timer (and reset the H/O Exp flag). If no unscheduled octets remain it simply resets the H/O Set flag. * Note in this case if Hi/Lo indicates that the Remaining Octets are from the high priority queue then Remaining is already included in the Q-Hi count and therefore not counted twice.</li></ul></li></ul>

0182The CPS-PDU Assembly Process works as previously described.

0183Note that since both the Tmin and Tsus-Limit timers both expire before a packet may be scheduled it is possible to optimise these events into a single timer. To do this the packet enqueuing at each calculation point determine which of the two conditions generates the timer that expires last and use this to set a timed event.

0184It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art without departing from the spirit and scope of the invention.