Channels and Tributary Unit Groups

Having discussed the way in which up to 63 individual TU12s are multiplexed into a VC4, it is now necessary to examine more closely the internal structure of the VC4. For this purpose, it is helpful to consider a VC4 not as a linear string of bytes, but instead, as a two dimensional block of bytes which is arranged as 9 rows, each of 261 bytes. For transmission purposes, this block is serialised by scan­ning left to right, top to bottom. (See Figure 42.12.) With this structure, a TU12 can be seen to occupy 4, widely separated, 9 byte columns, rather than the contiguous block of bytes, as suggested by Figures 42.10 and 42.11. (See Figure 42.13.) Since a VC4 repeats every 125μs, this implies that a TU12 contains 36 bytes per 125μs i.e. rather more than the 32 bytes nominally required by a plesiochronous 2.048 Mbit/s signal. This, however, is consistent with the need for a TU12 to include a pointer, overflow byte positions, VC12 overhead byte, plesiochronous stuffing etc. Each such group of four columns represents a separate channel within the VC4 and when a VC12 slips phase relative to the VC4 it slips within its own channel i.e. it does not overflow into another channel, as this would ob­viously corrupt the data in the other channel. As mentioned earlier, the position of the pointer within this channel is constant, only the VC12 part of the TU12 is allowed to wander in phase.

A group of three such TU12 channels within aVC4 is known as a Tributary Unit Group (TUG). As with the concept of a channel, a TUG is not a multiplexing level (such as a VC12) but a group of defined byte positions within a VC4. Some of these positions are reserved for TU pointers, while the others are for the rest of the TUs i.e. the VCs. The reason for introducing the concept of a TUG, instead of sticking with that of a channel, is that, as mentioned in Section 42.3, a C12 and hence VC12, is not the only size of Synchronous Container which has been defined. (See Figure 42.14.) For example, there exists a C2 which is designed to accommodate the North American 6.3Mhit/s plesiochronous rate. In the event of a PTO needing to transport both 2Mbit/s circuits and 6.3Mhit/s ones, they can both be accommodated within the same VC4 by assigning some TUGs to carry groups of three TU12s while other TUGs are assigned to each carry a single TU2.

The TUG in this example is known as a TUG2, because at 12 columns of 9 bytes, it is large enough to accommodate a single TU2. Beyond this, a TUG3 has also been defined. This is slightly larger than 7 TUG2s, and designed to accommodate a single 45Mbit/s circuit, after this has been mapped into its appropriate Synchronous Container (in this case, a VC3). A 34Mbit/s signal can also be mapped into a VC3, in an operation that appears somewhat wasteful on bandwidth, as the C3 has been sized for a 45Mhit/s signal. It is interesting to note that, rather than use a more aptly sized container, this bandwidth sacrifice was agreed to by European PTOs in order to reduce the potential network control problem posed by a larger variety of VCs.

A TUG3 is one third of the payload capacity of a VC4, and together with the TUG2, it constitutes an extremely flexible mechanism for partitioning the payload bandwidth of a VC4. The poten­tially complicated nature of this partitioning can he better understood by replacing the two dimensional representation of the VC4 payload structure by a three dimensional one. (See Figure 42.15.) For this representation, the order of transmission is left to right, front to back, top to bottom. Figure 42.15 not only shows TU12s and TU3s, as we have already discussed, but also, examples of other types of TUs, notably the TU11, which is the TU used to accommo­date a 1.5Mbit/s (DS1) signal in North America. This payload flexibility extends to alternative mechanisms for constructing a VC4 payload in which, for instance, a normal 140Mbit/s signal is mapped directly into the C4, without any need for recourse to the notion of TUGs. Because of the variety of possible VC4 payloads, part of the VC4 overhead (i.e. the H4 byte) is reserved for indicating the exact structure of this payload. This ability of a single VC4 to carry a mixture of different sized VCs within its payload is con­sidered to be especially useful in the Access portion of the network, where a PTO will not usually have the freedom to dedicate particu­lar VC4s to carrying a single type of lower order VC.

Figure 42.12 Representation of a VC4 as a block of 261 x 9 bytes together with its incorporation within an STM signal

Figure 42.13 Internal structure of VC4 showing fixed pointer locations and distribution of a single TU12 over 4 separate columns