Publication Date: 2012-07-25 | Views: 190 | Downloads: 0 | Author: Oscar Serrano | Document ID: EKB0000531773
In the RTN 950 V1R1 (5.76.01.33) a CES service was configured over the CD1 board to transport STM-1 traffic. After inter-connecting RTN with VNODE-S NEC multiplexer and test the E1s disaggregated in a DDF traffic didn't pass.
When CD1 board is used to configure a CES "STM-1" service, if some the overhead bytes of the board don't match with the overhead bytes of the other equipment connected to the RTN, service is not going to pass.
- In the case of the VNODE-S, by default the multiplexer is utilizing the J0 and J2 bytes and it is sending and expecting to received a "00 (cero)" 16 bytes mode hexadecimal value.
- In the case of the RTN, by default it is sending the "HuaWei SBS" 16 byte mode value in the J0, J1 and J2 overhead bytes.
To solve the incompatibility problem the RTN overhead bytes must be configured as follow:
J0: 00 hexadecimal,16 byte mode
J1: Doesn't care. Default value can be leave
J2: All the 63 E1s in 00 hexadecimal, 16 byte mode
Following, the steps done to verify the interoperability problem between RTN and VNODE-S:
1. Verify that the 63 CES services were created in order to send the full STM-1.
2. Verify the order in which the RTN was creating the services. If it was ITU-T mode or Interleave and also verify VNODE-S services order.
3. Verify synchronization priorities
4. Test STM-1 and E1s separately per vendor with loops in boards in order to guarantee a good service configuration
5. Verify J0, J1 and J2 overhead bytes in both equipments. Check what kind of values are sending and expecting to received.
Verify always the overhead bytes when the RTN is connected to other vendor equipment