E******* RBS 6000 Sync Alarm

[SolMX]

Hello, what parameters the E******* RBS 3G BST expect so if the synch is being done only via Ethernet works with no issues, we are using minlink radios to backhaul and we have no issues but we use radios from other providers a synch alarm related to the quality of the clock triggers, where can I find synch information and how it works at the NTP level.

Thank you all.

[LaserSport]

Hi, are the refered RBS GPB or CBU based?

The clock extraction in the GPB is less robust than in the CBU, you can find some info about this in alex documentation. The limits in the transmission variation delay are more tolerated in the CBU.

There are a counter pm...VariationDelay to evaluate this possible problem in the IP transmission solution.

Regards

[SolMX]

Hello Laser

Now that I read my post...it's not really clear.

We are using a E******* 6102 3G BST all this is all new to me, I'm not really in charge of the 3G BST but I would like to understand why we are getting alarms.

Let me explain with more detail, we are using all IP connectivity to the BST so the synch is traveling in the transport network as NTP messages, thats what I understand from E******* (I don't have Alex access) when the MiniLink radios are used as backhaul all is good and no synch alarms appear, as soon as we change the backhaul for other radios we get the alarm:

SubNetwork=ONRM_ROOT_MO_R,SubNetwork=CRHER1R.MeContext=BST400
Severity:Major
Event Type: Quality of service alarm
ProbableCause: Clock synchronisation problem
specificProblem:Synch Reference Not Reliable
managedObjectClass: Synchronization
managedObjectinstance: ManagedElement=1, TransportNetwork=1,Synchronization=1

after few seconds later we get the System Clock in Holdover mode as the synch is lost.

When we compare the latency and jitter of both radios, the Minilink and the other radio both have similar response times, so we are trying to figure out what is causing the synch alarm to trigger.

About your question Laser, about who extracts the clock is hard to say, I don't know if it's the GPB or the CBU, how can I now? only via configuration?

I'm by no means expert on E*******..not even a Junior..just plain new.

Now because of this issue we capture some packets and we discover that the NTP packets are just plain wrong, please help me to understand how the E******* BST synch with the RNC when it's done via NTP.


I have to move...but later I will post the NTP server packet.

THank you for your insight.

Any help or docs that can help to understand this synch process is much appreciated.

Cheers!

[SolMX]

I'm adding the NP server frame here:

Frame 6: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
Ethernet II (VLAN tagged), Src: Cisco_6c:6b:80 (c4:7d:4f:6c:6b:80), Dst: MasterIn_c2:67:78 (00:1e:df:c2:67:78)
Internet Protocol Version 4,
User Datagram Protocol, Src Port: ntp (123), Dst Port: 65501 (65501)
Network Time Protocol
Flags: 0x24 00.. .... = Leap Indicator: no warning (0)
..10 0... = Version number: NTP Version 4 (4)
.... .100 = Mode: server (4)
Peer Clock Stratum: primary reference (1)
Peer Polling Interval: invalid (0)
Peer Clock Precision: 67108864.000000 sec
Root Delay: 0.0000 sec
Root Dispersion: 0.0000 sec
Reference ID: Generic pulse-per-second
Reference Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Origin Timestamp: Not representable
Receive Timestamp: Not representable
Transmit Timestamp: Not representable

Please note the values in Peer clock precision.

And the BST reply to this packet:

Frame 728: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
Ethernet II (VLAN tagged), Src: MasterIn_c2:67:78 (00:1e:df:c2:67:78), Dst: All-HSRP-routers_04 (00:00:0c:07:ac:04)
User Datagram Protocol, Src Port: 65501 (65501), Dst Port: ntp (123)
Network Time Protocol
Flags: 0x23
00.. .... = Leap Indicator: no warning (0)
..10 0... = Version number: NTP Version 4 (4)
.... .011 = Mode: client (3)
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: invalid (0)
Peer Clock Precision: 1.000000 sec
Root Delay: 0.0000 sec
Root Dispersion: 0.0000 sec
Reference ID: NULL
Reference Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Origin Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Transmit Timestamp: Not representable


Thanks!

[LaserSport]

The RBS6102 is the latest HW outdoor, so at least it should have the same performance has the CBU based RBSs.

In solution that I now the RNC is the NTP server and the RBS (GPB, CBU or in this case DUW) extracts the CLK from IP frames (see attach).

The most interesting counter to see the performance of this sync solution is this one:

"pmMaxDelayVariation:This counter shows the Maximum Delay Variation (see ITU-T Y.1540 for definition of the delay variation) experienced by the active IP synchronization reference during the PM interval.

Condition: This counter is calculated on the basis of maximum and minimum packet delays for the active IP reference at the end of each GP, as follows:
Max Delay Variation = Max Packet Delay - Min Packet Delay"

Ask the guys from radio dpt to get this counter for a few IP based RBS's working and with problems and check the differences, you will see the "good" and the "bad" transmission solution.

Regards

[SolMX]

Hello LaserSport!!

This indeed is gold! Thank you so much for pointing me in the right direction, with this specifications and the statistics in the RBS now I now what KPI to watch.

Could you please share the password for the document you attached, I'm using winrar to open it and request a password.

I'm really eager to read such document!!

I will read the document carefully.

Once again thank you LaserSport.

[spatkad]

The RBS6102 is the latest HW outdoor, so at least it should have the same performance has the CBU based RBSs.

In solution that I now the RNC is the NTP server and the RBS (GPB, CBU or in this case DUW) extracts the CLK from IP frames (see attach).

The most interesting counter to see the performance of this sync solution is this one:

"pmMaxDelayVariation:This counter shows the Maximum Delay Variation (see ITU-T Y.1540 for definition of the delay variation) experienced by the active IP synchronization reference during the PM interval.

Condition: This counter is calculated on the basis of maximum and minimum packet delays for the active IP reference at the end of each GP, as follows:
Max Delay Variation = Max Packet Delay - Min Packet Delay"

Ask the guys from radio dpt to get this counter for a few IP based RBS's working and with problems and check the differences, you will see the "good" and the "bad" transmission solution.

Regards


LaserSport (http://www.finetopix.com/members/lasersport.html),

Avail us with password please

[javed_gtl]

thanks to all my friend

[hakimgsm]

hi freind;
PW please.
many thanks in advance.


The RBS6102 is the latest HW outdoor, so at least it should have the same performance has the CBU based RBSs.

In solution that I now the RNC is the NTP server and the RBS (GPB, CBU or in this case DUW) extracts the CLK from IP frames (see attach).

The most interesting counter to see the performance of this sync solution is this one:

"pmMaxDelayVariation:This counter shows the Maximum Delay Variation (see ITU-T Y.1540 for definition of the delay variation) experienced by the active IP synchronization reference during the PM interval.

Condition: This counter is calculated on the basis of maximum and minimum packet delays for the active IP reference at the end of each GP, as follows:
Max Delay Variation = Max Packet Delay - Min Packet Delay"

Ask the guys from radio dpt to get this counter for a few IP based RBS's working and with problems and check the differences, you will see the "good" and the "bad" transmission solution.

Regards