Troubleshooting VCG and LCAS in SDH: Configuration, Compatibility & Error Resolving

Overview & Thematic Scope

This technical FAQ addresses the most critical configuration and troubleshooting challenges engineers face when deploying Virtual Concatenation Groups (VCG) and Link Capacity Adjustment Scheme (LCAS) in SDH transport networks. Whether you are provisioning Ethernet over SDH (EoS) services, resolving differential delay alarms, or validating member link integrity, the answers below provide direct, actionable guidance for field and design engineers.

Frequently Asked Questions

Q1: What is the difference between a VCG and LCAS in SDH, and do I need both?

A VCG is the virtual concatenation group that bonds multiple SDH containers (e.g., VC-4 or VC-12) into a single logical payload for transporting Ethernet or other packet services, while LCAS is the control protocol that dynamically adjusts the VCG’s member links without interrupting traffic. You need both when you require hitless bandwidth adjustment and automatic member-failure resilience; VCG alone provides fixed bandwidth bonding but no dynamic re-sizing or protection.

Q2: How do I configure a basic VCG for Ethernet over SDH on a typical SDH ADM?

You configure a basic VCG by creating the virtual concatenation group, assigning the required number of member containers (e.g., VC-4-4v), binding the VCG to an Ethernet mapping function (GFP or LAPS), and enabling LCAS if dynamic bandwidth is required. The exact CLI/GUI steps vary by vendor, but the sequence is: create VCG ID, set container type and count, map the Ethernet port to the VCG, then provision cross-connects for each member.

Q3: What causes a ‘differential delay’ alarm in a VCG, and how do I resolve it?

A differential delay alarm occurs when the propagation delay difference between VCG member links exceeds the configured buffer size (typically 32 ms or 64 ms), causing the receiver to drop frames due to mis-sequencing. Resolve it by first measuring the delay difference (using vendor diagnostic commands), then either re-routing members over paths with similar latency, increasing the differential delay buffer if supported, or reducing the VCG size to a value within the network’s delay tolerance.

Q4: How does LCAS handle a member link failure, and what should I check if LCAS is not restoring bandwidth?

LCAS automatically removes a failed member from the VCG’s active group and re-allocates its bandwidth to remaining members in a hitless manner (if sufficient capacity exists). If LCAS is not restoring bandwidth, verify that LCAS is enabled on both ends, that the MST (Member Status) and RS-ACK bits are being exchanged correctly, and that the far-end is not configured for manual (non-LCAS) operation.

Q5: What are the compatibility requirements for VCG/LCAS between different SDH equipment vendors?

Interoperability requires both ends to use the same container type (e.g., VC-4-Xv), the same LCAS control settings (enabled/disabled and RS-ACK mode), and the same mapping method (GFP-F or LAPS). Most interoperability failures stem from mismatched LCAS configurations or different differential delay buffer capabilities; always validate with a test set before commissioning multi-vendor VCGs.

Q6: Why does my VCG report ‘member mismatch’ or ‘LCAS down’ after a cross-connect change?

Member mismatch or LCAS down after a cross-connect change typically indicates that one or more member cross-connects were mis-provisioned, reversed, or missing on one side, causing the VCG member sequence numbers to misalign. Verify that every member has a bidirectional cross-connect on both ends, that the member order matches the VCG configuration, and that LCAS is not administratively disabled on any member port.

Q7: Can I change the VCG size (add or remove members) without service interruption, and how does LCAS support that?

Yes, you can change the VCG size without service interruption when LCAS is enabled, because LCAS adds or removes members gracefully using the ADD/DELETE control fields while keeping the traffic-carrying members active. The process requires provisioning the new cross-connects first, then issuing the LCAS add/remove command; without LCAS, resizing causes a brief outage.

Q8: What performance monitoring counters should I watch to validate a healthy VCG/LCAS service?

To validate a healthy VCG/LCAS service, monitor the differential delay (should be below the buffer threshold), LCAS state (all members should show ‘OK’ or ‘UP’), member bit-error-rate (BER) counters, and the VCG-level frame loss and out-of-sequence counters. Rising out-of-sequence or frame-loss counters alongside zero LCAS alarms usually point to a delay-buffer or member-BER issue rather than a control-plane fault.