A Queue Handler contains two queues. All functionality related directly to processing this queue pair is implemented in the Queue Handler. One queue in each queue pair is being readied for the next STM-16 frame while the other queue is feeding the current STM-16 frame. Hereafter, the former will be called the active queue and the latter the inactive queue.
A conceptual diagram of the Queue Handler can be seen below. In this diagram the active queue has received a complete HDLC frame and is processing the queue (ie. calculating the BIP, scrambling, etc.) for the next STM-16 frame.
The following tasks have to be done to ready the contents of a queue ready for transmission in the next STM-16 frame:  - 9 Path Overhead bytes must be added to the queue in specific byte locations
Each active queue is filled with either one or zero HDLC-framed PPP packets, depending on whether or not there is data to transmit. HDLC-framed PPP packets can be anywhere from approximately 16 bytes to greater than 2340 bytes; for packets smaller than exactly 2340 bytes, the data must be padded with HDLC idle characters until it reaches 2340 bytes. This requirement is due to the fixed size of SDH frames.
For information on how the queue handlers are interconnected, see Queue Handler Interconnect.
After the initially empty queue receives an HDLC-framed PPP packet, it contains only the bytes of that frame. In order to add Path Overhead in the correct positions and pad with HDLC idle bytes, the HDLC-framed PPP packet must be dequeued and then re-enqueued with the necessary additional bytes. Before each byte of the padded VC-4 is enqueued it is included in the BIP calculation and then scrambled.
An example of the process by which the active queue is readied for transmission is shown below. The 1st step shows the active queue after receiving a 546 byte HDLC frame. All queues are 2349 bytes long to accommodate a VC-4 with 261 columns and 9 rows of bytes.
Step 2 shows that the first byte that is processed by the BIP calculation and the scrambler is the 1st byte of overhead being inserted into the queue. Path Overhead is the first byte processed and then every 261st byte thereafter until 9 bytes in total have been inserted.
The 3rd step shows the bytes of the HDLC frame being processed by the BIP calculation and the scrambler. As can be seen, there are 154 bytes that have been enqueued since the process started. The first of these bytes was the Path Overhead byte being processed in step 2 and the other 153 are bytes from the HDLC frame. One byte of the frame is being processed and 392 have yet to be dequeued and processed, giving us a total of 546 bytes of HDLC frame.
Step 4 shows the second byte of Path Overhead being processed. As specified, it is the 261st byte to be processed since the first Path Overhead byte was inserted.
Step 5 shows that 549 bytes have been enqueued thus far. The 549 bytes consist of the 546 byte HDLC frame and 3 bytes of Path Overhead. At this point there is no longer any bytes of the HDLC frame left to be dequeued and processed so the HDLC idle character is being used to pad the data.
This process must be completed for all 16 active queues before the end of the current STM-16 frame arrives. The Virtual Container Processing takes place according to the state diagram below.