100% found this document useful (1 vote)
410 views5 pages

83603645-Ericsson-RBS-6000-Sync-Alarm (Enregistré Automatiquement)

The document discusses an Ericsson RBS 6000 synchronization alarm that occurs when using certain radio backhaul connections but not others for transporting NTP synchronization messages. The key points are: 1) The alarm occurs when using other radios as backhaul instead of MiniLink radios, indicating a potential issue with clock synchronization over the alternative transport. 2) Analysis of NTP packets shows the server is reporting very low clock precision, while the RBS responds with an unspecified stratum, suggesting it is unable to reliably synchronize. 3) A counter measuring maximum delay variation experienced by the synchronization reference is recommended to compare "good" and "problem" transmission solutions, as this may indicate instability causing loss of sync

Uploaded by

Wissem Ben Attia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
410 views5 pages

83603645-Ericsson-RBS-6000-Sync-Alarm (Enregistré Automatiquement)

The document discusses an Ericsson RBS 6000 synchronization alarm that occurs when using certain radio backhaul connections but not others for transporting NTP synchronization messages. The key points are: 1) The alarm occurs when using other radios as backhaul instead of MiniLink radios, indicating a potential issue with clock synchronization over the alternative transport. 2) Analysis of NTP packets shows the server is reporting very low clock precision, while the RBS responds with an unspecified stratum, suggesting it is unable to reliably synchronize. 3) A counter measuring maximum delay variation experienced by the synchronization reference is recommended to compare "good" and "problem" transmission solutions, as this may indicate instability causing loss of sync

Uploaded by

Wissem Ben Attia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Ericsson RBS 6000 Sync Alarm

$ setclock yyyy-mm-dd hh:mm:ss


eg:$ setclock 2006-10-26 18:39:00
XXXX> sget synchro
=========================================================
========================================================
10 TransportNetwork=1,Synchronization=1
=========================================================
========================================================
SynchronizationId 1
degradationIsFault 0 (DEGR_NOT_FAULT)
nodeSystemClock 2 (LOCKED_MODE)
syncRefActivity i[8] = 1 1 2 1 1 1 1 1 (INACTIVE INACTIVE ACTIVE INACTIVE INACTIVE
INACTIVE INACTIVE INACTIVE)
syncRefPriority i[8] = 0 0 1 2 0 0 0 0
syncRefStatus i[8] = 0 0 3 3 0 0 0 0 (FAILED FAILED OK OK FAILED FAILED FAILED
FAILED)
syncReference [8] =
>>> syncReference =
>>> syncReference =
>>> syncReference = IpSystem=1,IpAccessHostEt=1,IpSyncRef=1
>>> syncReference = IpSystem=1,IpAccessHostEt=1,IpSyncRef=2
>>> syncReference =
>>> syncReference =
>>> syncReference =
>>> syncReference =
userLabel
=========================================================
========================================================
1553 NodeBFunction=1,RbsSynchronization=1
=========================================================
========================================================
RbsSynchronizationId 1
masterTu 1 (PLUG_IN_UNIT_REF1)
nodeIsStable true
nodeIsSynchronized true
plugInUnitRef1 Subrack=1,Slot=1,PlugInUnit=1
plugInUnitRef2
timDeviceRef1 Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,TimDeviceSet=1,TimDevice=1
timDeviceRef2
userLabel
=========================================================

========================================================
Total: 2 MOs

Hello, what parameters the Ericsson 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.

Re: Ericsson RBS 6000 Sync Alarm


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.

Re: Ericsson RBS 6000 Sync Alarm


Hello Laser
Now that I read my post...it's not really clear.
We are using a Ericsson 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 Ericsson (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 Ericsson..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 Ericsson 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.

Re: Ericsson RBS 6000 Sync Alarm


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-HSRProuters_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

Re: Ericsson RBS 6000 Sync Alarm


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.

Re: Ericsson RBS 6000 Sync Alarm


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!!

You might also like