No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


1588v2 can't work between CX600 v6r1 and Huawei NodeB as different 1588v2 protocol implementation

Publication Date:  2012-07-27 Views:  237 Downloads:  0

Issue Description

In One IP-RAN project, composed of CX600(v6r1) devices, Huawei is obliged to support 1588v2. But after test in Customer lab we have found that 1588v2 can't work between CX600 and Huawei NodeB. It was very funny and hard to explain that Huawei to Huawei devices can't work consistently.


Alarm Information


Handling Process

When we faced this problem in customer office, we followed the following steps in order to solve the problem.

1) check if upe is synchronized using 1588v2 with PE-AGG.

dis ptp all
device config info
ptp state :enabled domain value :1
slave only :no device type :bc
set port state :no local clock id :286ed4fffe93fed9
acl :no virtual clock id :no

bmc run info
grand clock id :286ed4fffe953e22
receive number :gigabitethernet8/1/0
parent clock id :286ed4fffe953e22
parent portnumber :8448
priority1 :1 priority2 :128
step removed :1 clock accuracy :49
clock class :187 time source :160
utc offset :0 utc offset valid :false
time scale :arb time traceable :false
leap :none frequence traceable:true

port info
name state delay-mech ann-timeout type domain
gigabitethernet1/2/0 master pdelay 9 bc 1
gigabitethernet1/2/3 faulty pdelay 9 bc 1
gigabitethernet8/1/0 slave pdelay 9 bc 1
gigabitethernet8/1/6 faulty pdelay 9 bc 1
gigabitethernet8/1/7 faulty pdelay 9 bc 1

time performance statistics(ns): slot 8 card 1 port 0
realtime(t2-t1) :347 pathdelay :350
max(t2-t1) :355
min(t2-t1) :287

clock source info
clock pri1 pri2 accuracy class timesrc signal switch direction in-status
local 128 128 0x31 187 0xa0 - - - -
bits0 128 128 0x20 6 0x20 none off -/- abnormal
bits1 128 128 0x20 6 0x20 none off -/- abnormal
bits2 128 128 0x20 6 0x20 none off -/- abnormal

The command result show that UPE can trace the clock source, and so we have conclude that the problem exist between cx600 and NodeB.

2) change the ptp encapsulation mode in upe and nodeb:

We have found that the only mode supported by NodeB is L3 unicast encapsulation.

3) capture the packet between nodeb and upe

After analyzing the packet capture, R&D find that the 1588v2 protocol on CX600 is not consistent with the NodeB. CX600 support standard ieee1588v2 which don’t need negotiation with peer, but the 1588v2 running on NodeB need to negotiate with peer.

After this step we have found our self blocked, since the R&D said that only way is to upgrade CX600 to v6r3.
but with the patient of local team we have found one small way. The project mainly concern CX600 and not NodeB, so we asked the wireless team to check if they have some Nodeb version that support other ptp encapsulation mode.after checking they said we can try to use RAN12 version in NodeB.
4) upgrade NodeB to R12 and test other ptp encapsulation mode:

After testing other ptp encapsulation mode, Nodeb has succeed after 20 min to trace the clock source using L2 multicast encapsulation mode,because in this scenario no negotiation is required between NodeB and CX600.


Root Cause

1588v2 implementation in NodeB and CX600 are different.


In this kind of scenario, the only encapsulation mode that can work between CX600(v6R1) and NodeB(R12) is L2 multicast encapsulation mode.