CONCATENATION

Concatenation is the process of summing the bandwidth of X containers (C-i) into a larger container. This provides a bandwidth X times bigger than C-i. It is well indicated for the transport of big payloads requiring a container greater than VC-4, but it is also possible to concatenate low-capacity containers, such as VC-11,VC-12, or VC-2.

Figure An example of contiguous concatenation and virtual concatenation. Contiguous concatenation requires support by all the nodes. Virtual concatenation allocates bandwidth more efficiently, and can be supported by legacy installations.

There are two concatenation methods:

1. Contiguous concatenation: which creates big containers that cannot split into smaller pieces during transmission. For this, each NE must have a concatena- tion functionality.
2. Virtual concatenation: which transports the individual VCs and aggregates them at the end point of the transmission path. For this, concatenation functionality is only needed at the path termination equipment.

Contiguous Concatenation of VC-4

A VC-4-Xc provides a payload area of X containers of C-4 type. It uses the same HO-POH used in VC-4, and with identical functionality. This structure can be transported in an STM-n frame (where n = X). However, other combinations are also possible; for instance, VC-4-4c can be transported in STM-16 and STM-64 frames. Concatenation guarantees the integrity of a bit sequence, because the whole container is transported as a unit across the whole network .

Obviously, an AU-4-Xc pointer, just like any other AU pointer, indicates the position of J1, which is the first byte of the VC-4-Xc container. The pointer takes the same value as the AU-4 pointer, while the remaining bytes take fixed values equal to Y=1001SS11 to indicate concatenation. Pointer justification is carried out the same way for all the X concatenated AU-4s and X x 3 stuffing bytes .

However, contiguous concatenation, today, is more theory than practice, since other alternatives more bandwidth-efficient, such as virtual concatenation, are gaining more importance.

 

Virtual Concatenation

Connectionless and packet-oriented technologies, such as IP or Ethernet, do not match well the bandwidth granularity provided by contiguous concatenation. For example, to implement a transport requirement of 1 Gbps, it would be necessary to allocate a VC4-16c container, which has a 2.4-Gbps capacity. More than double the bandwidth that is needed.

 

Virtual concatenation (VCAT) is a solution that allows granular increments of bandwidth in single VC-n units. At the MSSP source node VCAT creates a continuous payload equivalent to X times the VC-n units . The set of X containers is known virtual container group (VCG) and each individual VC is a member of the VCG. All the VC members are sent to the MSSP destination node independently, using any available path if necessary. At the destination, all the VC-n are organized, according the indications provided by the H4 or the V5 byte, and finally delivered to the client

Differential delays between VCG member are likely because they are transported individually and may have used different paths with different latencies. Therefore, the destination MSSP must compensate for the different delays before reassembling the payload and delivering the service.

Virtual concatenation is required only at edge nodes, and is compatible with legacy SDH networks, despite the fact that they do not support concatenation. To get the full benefit from this, individual containers should be transported by different routes across the network, so if a link or a node fails the connection is only partially affected. This is also a way of providing a resilience service.

 Higher Order Virtual Concatenation

Higher Order Virtual Concatenation (HO-VCAT) uses X times VC-3 or VC4 containers (VC-3/4-Xv, X = 1 … 256), providing a payload capacity of X times 48384 or 149760 kbit/s.

 

The virtual concatenated container VC-3/4-Xv is mapped in independent VC-3 or VC-4 envelopes that are transported individually through the network. Delays could occur between the individual VCs, this obviously has to be compensated for when the original payload is reassembled .

A multiframe mechanism has been implemented in H4 to compensate for differential delays of up to 256ms:

• Every individual VC has a H4 multiframe indicator (MFI) that denotes the virtual container they belong to
• The VC also traces its position X in the virtual container using he SEQ number which is carried in H4. The SEQ is repeated every 16 frames

The H4 POH byte is used for the virtual concatenation-specific sequence and multiframe indication

 Lower Order Virtual Concatenation

Lower Order Virtual Concatenation LO-VCat. uses X times VC-11, VC12, or VC2 containers (VC-11/12/2-Xv, X = 1 … 64).

A VCG built with V11, VC12 or VC2 members provides a payload of X containers C11, C12 or C4; that is a capacity of X times 1600, 2176 or 6784 kbit/s. VCG members are transported individually through the network, therefore differential delays could occur between the individual components of a VCG, that will be compensated for at the destination node before reassembling the original continuous payload ).

A multiframe mechanism has been implemented in bit 2 of K4. It includes a sequence number (SQ) and the multiframe indicator (MFI), both enable the reordering of the VCG members. The MSSP destination node will wait until the last member arrives and then will compensate for delays up to 256ms. It is important to note that K4 is a multiframe itself, received every 500ms, then the whole multiframe sequence is repeated every 512 ms.

Testing VCAT

When installing or maintaining VCAT it is important to carry out a number of tests to verify not only the performance of the whole Virtual Concatenation, but also every single member of the VCG. For reassembling the original client data, all the members of the VCG must arrive at the far end, keeping the delay between the first and the last member of a VCG below 256 ms. A missing member prevents the

reconstruction of the payload, and if the problem persists causes a fault that would call for the reconfiguration of the VCAT pipe. Additionally, Jitter and Wander on individual paths can cause anomalies (errors) in the transport service.

BER, latency, and event tests should verify the capacity of the network to perform the service. The VCAT granularity capacity has to be checked as well, by adding/removing. To verify the reassembly operation it is necessary to use a tester with the capability to insert differential delays in individual members of a VC.