Vous êtes sur la page 1sur 58

Sync Hub Direct Forward

Network Engineering Information


RP554, LTE1710, RAN3001, RG602339
SRAN15, RL70MP/RL55MP, RU50EP1, RG40

Check the latest version of this NEI


For internal use Network Engineering / Sergey Antipov / 18 March 2015 © Nokia Solutions and Networks 2014
Preface
Disclaimer

Please note that the NEI materials are for internal use only. If they shall be used as a
source for the customer presentation, it is mandatory to align the contents with the
Product Management and/or local sales teams at first!

2 Network Engineering / Sergey Antipov / 18 March 2015


Preface
History

Version Date Handled by Comments and status


0.2 14-Apr-2014 Sergey Antipov Draft for the first review
1.0 15-May-2014 Sergey Antipov This is the initial public version
1.01 11-Jun-2014 Sergey Antipov C3 milestone note added
1.1 16-Jun-2014 Sergey Antipov Interdependencies updates; Minor improvements
1.2 03-Jul-2014 Sergey Antipov GSM-specific updates for parameters gpsTotalAntennaLineDelay and btsSyncSource
1.21 17-Mar-2015 Sergey Antipov Update: The feature postponed behind LTE TDD RL55
1.22 18-Mar-2015 Sergey Antipov SW releases updated
1.23 14-Jul-2015 Andrzej Maciołek SW releases updated (GSM/WCDMA)

3 Network Engineering / Sergey Antipov / 18 March 2015


Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

4 Network Engineering / Sergey Antipov / 18 March 2015


Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

5 Network Engineering / Sergey Antipov / 18 March 2015


Introduction
Dependency Table

RL release eNB NetAct


FDD LTE RL70MP LN7.0 -
TDD LTE RL55MP LNT5.0 -
FlexiZone Micro (FZM) x x x

Specified by
HW & IOT HW requirements MME SAE GW UE
3GPP
Release/version - - - - -

6 Network Engineering / Sergey Antipov / 18 March 2015


Introduction

Release Information Sales Information


RAS Release RU50 EP1 BSW/ASW BSW

Flexi Direct Release - RAS SW Component RAN


RNC Release - License Control in
Network Element -
mcRNC Release -
BTS Flexi Release WBTS9.1 2.0 License Control Attributes -

BTS Flexi Lite Release -


NetAct Release -
UE Release -

7 Network Engineering / Sergey Antipov / 18 March 2015


Introduction

Release Information Sales Information


Release RG40(GSM15) BSW/ASW BSW
BSC S16.2 License Control in Network
Element -
Flexi MR 10 BTS GF1 2.0.0
Flexi Compact BTS - License Control Attributes -
Flexi MR BTS -
Flexi EDGE BTS EX5_2 2.0
UltraSite BTS -
MetroSite BTS -
BTSplus -
Horizon BTS -
NetAct -

8 Network Engineering / Sergey Antipov / 18 March 2015


Introduction
RAN level synchronization vs. Site level synchronization

RAN level phase and time synchronization requires BTSs of a single RAT
to be synchronized in terms of the phase and time between each other

LTE
TDD:1.5 μs; OTDOA:1 μs; eICIC:3-10 μs

WCDMA
no phase and time sync
 No sync   No sync 
GSM
DFCA: 18 μs

RAN level phase and time synchronization is acquired by synchronizing


the phase and time of each BTS to the Primary Reference Time Clock (PRTC)

9 Network Engineering / Sergey Antipov / 18 March 2015


Introduction
RAN level synchronization vs. Site level synchronization

Site level phase and time synchronization requires BTSs of different RATs at a single
site to be synchronized in terms of the phase and time between each other

RF RF
sharing No phase and time sync sharing

 0.5 μs   0.5 μs 

Site level phase and time synchronization does not require


synchronization of the phase and time to the PRTC

10 Network Engineering / Sergey Antipov / 18 March 2015


Introduction
RAN level synchronization vs. Site level synchronization

Both levels may perfectly coexist

LTE
TDD:1.5 μs; OTDOA:1 μs; eICIC:3-10 μs
RF WCDMA RF
sharing
sharing
no phase and time sync
 0.5 μs   0.5 μs 
GSM
DFCA: 18 μs

11 Network Engineering / Sergey Antipov / 18 March 2015


Introduction
The feature Sync Hub Direct Forward at glance

The feature improves sync redistribution between co-sited BTS


The main intent of the feature is the site
SyncHub Master level synchronization
Any sync source
(except RP3-01/CPRI)
System Module (SM) SYNC-OUT

1PPS & ToD


SyncHub Slave SYNC-IN
Site level sync
System Module (SM) SYNC-OUT The feature can also be used as a part of
RAN level sync solution distributing sync
1PPS & ToD between BTSs of a same or different RATs
SYNC-IN at a single site
SyncHub Slave

System Module (SM)


RAN level sync
12 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Introduction
The feature at glance

To align sync capabilities among RATs, the feature also enables WCDMA BTS to
synchronize the phase and ToD from an external GNSS receiver

GNS
(GPS/GLONASS)

SYNC-IN

Phase & ToD sync


System Module (SM)

13 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Introduction
The feature at glance

In context of RF sharing the feature allows to decouple synchronization


from RP3-01 interface
Common RF Module (RFM)

RP3-01 RP3-01

RP3-01

Any
sync source
System Module (SM) SYNC-OUT SYNC-IN System Module (SM)
1PPS & ToD

14 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Introduction
The feature at glance

The feature also allows the radio slave to temporarily take over the radio master role
when the radio master fails
Common RF Module (RFM)

RP3-01 RP3-01

RP3-01
Radio Master Temp Radio Master

System Module (SM) SYNC-OUT SYNC-IN System Module (SM)


1PPS & ToD

15 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

16 Network Engineering / Sergey Antipov / 18 March 2015


Technical Details
High Accuracy Sync Chain

Sync distribution via 1PPS & ToD uses connection


between SYNC-IN (SIN) and SYNC-OUT (SOUT) ports
SYNC-OUT SYNC-IN SYNC-OUT SYNC-IN SYNC-IN SYNC-OUT
(MDR-14) (MDR-26) (MDR-14) (MDR-26) (HDMI) (HDMI)

ESMB/ESMC FSMv2 FSMv3


SYNC-IN port pinout SYNC-OUT port pinout
Pin Number Pin Number
Signal Signal
ESMB/ESMC FSMv2 FSMv3 ESMB/ESMC FSMv2 FSMv3
1PPS in P (RS-422) 3 1 7 1PPS out P (RS-422) 3 1 7
1PPS in N (RS-422) 4 2 9 1PPS out N (RS-422) 4 2 9
GPS Time in P (RS-422) 5 3 1 GPS Time out P (RS-422) 5 3 1
GPS Time in P (RS-422) 6 4 3 GPS Time out N (RS-422) 6 4 3

17 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Technical Details
High Accuracy Sync Chain

Sync cables available for order from NSN

Sales Item Short Name Description Length


472509A FTSF FSMF HDMI SYNC OUT to FSMF HDMI SYNC IN 2m
472846A FTSN FSMF HDMI SYNC OUT to FSMF HDMI SYNC IN 15m
472808A FTSK FSMF HDMI SYNC OUT to FSME MDR26 SYNC IN 2m
472799A FSCB FSMF HDMI SYNC OUT to ESMB/C MDR26 SYNC IN 5m
472576A FTSG FSMC/D/E MDR14 SYNC OUT to FSMF HDMI SYNC IN 2m
472086A FSGA FSMC/D/E MDR14 SYNC OUT to FSMC/D/E MDR26 SYNC IN 2m
472798A FSCC FSMC/D/E MDR14 SYNC OUT to ESMB/C MDR26 SYNC IN 5m
472685A ESFB ESMB/C MDR14 SYNC OUT to FSMF HDMI SYNC IN 12m
472840A FTSL ESMB/C MDR14 SYNC OUT to FSMC/D/E MDR26 SYNC IN 2m
471371A ESFA ESMB/C MDR14 SYNC OUT to ESMB/C MDR26 SYNC IN 12m

18 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Technical Details
High Accuracy Sync Chain

Sync distribution between BTSs at a single site via 1PPS & ToD interface
is to become the default approach
SyncHub Master
Any sync source gpsInUse = False/True
gpsCtrlBlockForCoLocatedBts = False
(except RP3-01/CPRI) OCXO
syncPropagationEnabled = True
FSMv3/ESMB1/ESMC1 SOUT

• SyncHub Master: FSMv3/ESMB1/ESMC1 1PPS & ToD


• SyncHub Slave: FSMv3/FSMv2/ESMB2/ESMC2 SyncHub Slave SIN
gpsInUse = False
gpsCtrlBlockForCoLocatedBts = True
• LTE: FSMv2/FSMv3 OCXO
syncPropagationEnabled = True
• WCDMA: FSMv2/FSMv3 FSMv3/FSMv2/ESMB2/ESMC2 SOUT

• GSM: ESMB/ESMC/FSMv33 1PPS & ToD


SyncHub Slave SIN
1 Only if RAN level phase/time synchronization gpsInUse = False
is not required in the sync chain gpsCtrlBlockForCoLocatedBts = True
2
OCXO
ESMB/ESMC cannot function as a SyncHub Slave, syncPropagationEnabled = True/False
if SyncHub Master is also ESMB/ESMC FSMv3/FSMv2/ESMB2/ESMC2
3 After FSMv3 support is implemented in GSM

19 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Technical Details
High Accuracy Sync Chain

Phase synchronization requires sync signal compensation


The phase offset can be compensated with: • SH Master sync signal delay components**
• BTSSCL/gpsTotalAntennaLineDelay – Cable from GNSS receiver to SH Master
• BTSSCL/gpsCableLength* – SYNC-IN port on SH Master

* The gpsCableLength may only be used SyncHub Master • SH Slave#1 sync signal delay
on the SyncHub Master and only when – SYNC-OUT port on SH Master
an official NSN cable is used to connect OCXO
– Cable from SH Master to SH Slave#1
a GNSS receiver – SYNC-IN port on SH Slave#1
• SH Slave#2 sync signal delay
– SYNC-OUT port on SH Master
Processing delay (ns) SyncHub Slave#1 – Cable from SH Master to SH Slave#1 Sync signal delay
at SH Slave#1
Port – SYNC-IN port on SH Slave#1
ESMB/ESMC FSMv2/FSMv3
OCXO
– SYNC-OUT port on SH Slave#1
SYNC-IN 30 ± 20 12 ± 4 – Cable from SH Slave#1 to SH Slave#2
SYNC-OUT 30 ± 20 8±3 – SYNC-IN port on SH Slave#2

• Cable propagation delay may be estimated SyncHub Slave#2 ** Compensation of the phase offset on the SyncHub
as 5.4 ns/m with an accuracy of ±10% Master is required only when it uses GNSS
OCXO as a source of the phase synchronization

20 Network Engineering / Sergey Antipov / 18 March 2015

▼ ▼ ▼ view slide notes for more insights ▼ ▼ ▼


Technical Details
High Accuracy Sync Chain

Example: Compensation of the phase offset in the SyncHub Chain


• SH Master sync signal delay: 1080 ns + 12 ns = 1 092 ns
– Cable from GNSS receiver to SH Master: 200 m * 5.4 ns/m = 1 080 ns
– SYNC-IN port on SH Master: 12 ns
3rd party cable: 200 m
SyncHub Master • SH Slave#1 sync signal delay: 8 ns + 10.8 ns + 12 ns = 30.8 ns ~ 31 ns
– SYNC-OUT port on SH Master: 8 ns
OCXO
– Cable from SH Master to SH Slave#1: 2 m * 5.4 ns/m = 10.8 ns
– SYNC-IN port on SH Slave#1: 12 ns
LTE FSMv3
• SH Slave#2 sync signal delay: 31 ns + 8 ns + 27 ns + 30 ns = 96 ns
FTSK cable: 2 m – SYNC-OUT port on SH Master
SyncHub Slave#1 – Cable from SH Master to SH Slave#1 Sync signal delay : 31 ns
at SH Slave#1
– SYNC-IN port on SH Slave#1
OCXO
– SYNC-OUT port on SH Slave#1: 8 ns
– Cable from SH Slave#1 to SH Slave#2: 5 m * 5.4 ns/m = 27 ns
WCDMA FSMv2 – SYNC-IN port on SH Slave#2: 30 ns
FSCC cable: 5 m Processing delay (ns)
Port
SyncHub Slave#2 ESMB/ESMC FSMv2/FSMv3
SYNC-IN 30 ± 20 12 ± 4
OCXO
SYNC-OUT 30 ± 20 8±3
GSM ESMC
21 Network Engineering / Sergey Antipov / 18 March 2015
Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

22 Network Engineering / Sergey Antipov / 18 March 2015


Interdependencies

The main feature is prerequisite


The limiting feature limits the main feature for another feature
Limiting Feature Prerequisite Feature

The prerequisite feature


The main feature limits the limiting feature is required for the main feature
Main Feature
The main feature gives extra benefits/gains
Minor impact on the main feature to the supporting feature
(e.g. in some very specific
and rare scenarios)

Impacted Feature
Minor impact of the main feature,
e.g. in some very specific/rare scenarios

Supporting Feature
The supporting feature gives extra
Potentially Impacted benefits/gains to the main feature
Feature An impact might seem to be present,
but there is no impact

23 Network Engineering / Sergey Antipov / 18 March 2015


Interdependencies
Synchronization Hub

The feature Sync Hub Direct Forward integrates to the principals established by the feature
Synchronization Hub*, while also improving it and adding the new functionality

LTE1710 LTE612
Sync Hub Direct
Synchronization Hub
Forward

RAN3001 RAN1707*
Sync Hub Direct Flexi WCDMA
Forward integrated CESoPSN

⃰ The functionality of the feature Synchronization Hub was implemented in WCDMA as a part of the CESoPSN feature

24 Network Engineering / Sergey Antipov / 18 March 2015


Interdependencies
Phase Synchronization Application Features

By transferring clock/phase and time information between different BTS at a single site, RAT
specific applications requiring phase synchronization can operate with just one BTS on each
site synchronized to a phase sync reference source (e.g. GPS, ToP-P)

LTE1710 RG602339
Sync Hub Direct Sync Hub Direct
Forward Forward

LTE426 LTE495 LTE1113 BSS21391


System Time Broadcast
OTDOA eICIC - Macro DFCA support for OSC
for SIB8

25 Network Engineering / Sergey Antipov / 18 March 2015


Interdependencies
RF Sharing Related Features

By decoupling synchronization from the RP3-01 interface, the feature Sync Hub Direct Forward
can provide clock, phase and time information to RF sharing features

LTE435 RAN1770 RAN2126 RAN2556


RF Sharing RF Sharing WCDMA- RF Sharing WCDMA- 3-RAT RF Sharing
WCDMA-LTE GSM LTE 2G-3G & 2G-4G

LTE447 LTE1710 RAN3001 RG602339 BSS21520


SW Support for RF Sync Hub Direct Sync Hub Direct Sync Hub Direct
RF Sharing GSM-LTE
Sharing GSM-LTE Forward Forward Forward

RAN2757 RAN2953
LTE1556 RAN2568
RF Sharing WCDMA- Mixed System Module
3-RAT RF Sharing RF Sharing Support
LTE with Extension SM Configurations with RF
2G-3G & 2G-4G with Extension SM
for WCDMA Sharing in RU50

26 Network Engineering / Sergey Antipov / 18 March 2015


Interdependencies
Synchronization Input Related Features

Synchronization input related features can provide SyncHub Master


with a source of sync reference

LTE891
LTE080 LTE134 BSS21439
Timing over Packet with
GPS Synchronization Timing over Packet Synchronous Ethernet
Phase Synchronization

LTE711 LTE1710 RAN3001 RG602339 BSS30450


Synchronization from Sync Hub Direct Sync Hub Direct Sync Hub Direct
Timing over Packet
2.048Mhz Forward Forward Forward

RAN1222
External GPS RAN1708 RAN1254 BSS101684
LTE713
Synchronization for BTS Synchronous Timing over Packet for Timing over Packet with
Synchronous Ethernet
Flexi BTS System Ethernet BTS Application SW Phase Synchronization
Module Rel 1

27 Network Engineering / Sergey Antipov / 18 March 2015


Interdependencies
Synchronization Output Related Features

Synchronization output related features can use synchronization reached


with the feature Sync Hub Direct Forward to provide synchronization reference to other nodes

RAN3001 RAN2071
Sync Hub Direct Synchronous Ethernet
Forward Generation

28 Network Engineering / Sergey Antipov / 18 March 2015


Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

29 Network Engineering / Sergey Antipov / 18 March 2015


Benefits and Gains

1. By transferring clock/phase and time information with a very high


accuracy between multiple BTS at a single site, the feature
Sync Hub Direct Forward satisfies tight sync demands
required by RF sharing scenarios. Additionally, regardless
if RF sharing is used or not, the feature allows just a
single BTS per site to be synchronized from another
mean of a reference source (e.g. GPS, ToP, SyncE)
2. By decoupling synchronization from the RP3-01 interface
in RF sharing configuration, the feature Sync Hub Direct
Forward makes the first step to completely remove RP3-01
inter-BTS interface in a future release (by another feature)
3. By enabling WCDMA BTS to synchronize the phase and ToD
from an external GNSS receiver, the feature Sync Hub Direct
Forward creates a base for a uniform solution that is agnostic
to a specific RAT
4. By enabling the radio slave to temporarily take over the radio
master role when the radio master fails, the feature Sync Hub
Direct Forward improves availability and reliability of RF sharing
solutions
30 Network Engineering / Sergey Antipov / 18 March 2015
Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

31 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Definition of terms and rules for parameter classification*


The ‘Basic Parameters’ category contains primary The ‘Advanced Parameters’ category contains the
parameters which should be considered during cell parameters for network optimisation and fine tuning:
deployment and must be adjusted to a particular scenario.
These are: > Decent network performance should be achieved without
tuning these parameters
> Network Element (NE) identifiers > Universal defaults ensuring decent network performance need
> Planning parameters, e.g. neighbour definitions, frequency, to be defined for all parameters of this category. If this is not
scrambling codes, PCI, RA preambles possible for a given parameter it must be put to the ‘Basic
> Parameters that are the outcome from dimensioning, i.e. basic Parameters’ category
parameters defining amount of resources > Parameters requiring detailed system knowledge and broad
> Basic parameters activating basic functionalities, e.g. power experience unless rules for the ‘Basic Parameters’ category
control, admission control, handovers are violated
> Parameters defining operators’ strategy, e.g. traffic steering, > All parameters (even without defaults) related to advanced
thresholds for power control, handovers, cell reselections, and very complex features
basic parameters defining feature behaviour

* - purpose: categories of parameters have been defined to simplify network parameterization. Parameterization effort shall be focused mainly on parameters included in
basic category. Categorization will be reflected in a ‘view’ definition in NetAct CM Editor (planned in RL60) i.e. parameters will be displayed according to the
category: either in the ‘Basic parameters’ view or the ‘Advanced parameters’ view.

32 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management
Configuration of Synchronization Input Reference Source

• Configuration of various supported sync input reference sources (like ToP-P,


ToP-F, GPS, SyncE, PDH, 2MHz) is subject to numerous parameters defined by
their own dedicated features and described in respective materials
• The feature SyncHub Direct Forward does not change the configuration of these
sync input reference sources, but ensures interoperability with all of them
– The only exception is that a 1PPS/ToD sync input may either be used for
connecting a GPS receiver or a SyncHub Master; As a result either only
gpsInUse or gpsCtrlBlockForCoLocatedBts parameter can be true at any time

33 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New/Related parameter
btsSyncMode Network synchronization mode
Object (LTE): BTSSCL This parameter selects the synchronization mode of a BTS element.
Object (WCDMA): BTSSCW Note: A SyncHub Master and SyncHub Slaves can individually work either in
Frequency or in Phase synchronization mode. Selecting the correct
Range: [FreqSync (0),
synchronization mode is subject to the radio applications the given network
PhaseSync (1)]
element is to provide.
Default: FreqSync (0)
Note: In RF sharing scenarios SyncHub Slaves must have this parameter set to
Multiplicity: 1 the value PhaseSync (1) even if phase synchronization is not required for other
Modification: BTS restart needed RAT specific applications.

Category: Basic

34 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New/Related parameter
ext1ppsClkOutOn PPS synchronization output in use in HO mode
Object (LTE): BTSSCL Controls if the BTS regenerates sync signal on the 1PPS output in the holdover
mode.
Object (WCDMA): BTSSCW
Note: In case the BTS has lost all supported reference sources for generating
Range: [false (0), true (1)]
1pps pulse, the BTS starts running in hold-over mode. This parameter controls if
Default: false (0) in holdover mode the external 1pps output is switched on (true) or off (false).
Multiplicity: 1 Note: In RF sharing scenarios the parameter should be set to true (1) on non-
Modification: On-line tail BTSs in the SyncHub chains, because otherwise the elements are loosing
synchronization between each other, which prevents RF sharing from the proper
Category: Basic functioning.
Note: In non RF sharing scenarios, it depends on the holdover performance of
SyncHub Master compared to SyncHub Slaves. If the holdover performance of
the SyncHub Master is better than the holdover performance of the SyncHub
Slaves, the 1PPS/ToD output should remain switched on during holdovers. If the
holdover performance of the SyncHub Master is worse than the holdover
performance at the SyncHub Slaves, the 1PPS/ToD output should be switched off
during holdovers, making the SyncHub Slaves to rely on their own holdover.

35 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New/Related parameter
gpsCableLength GPS cable length
Object (LTE): BTSSCL This parameter defines the cable length used between GPS receiver and the BTS
for official NSN cable with length of 30 m, 100 m or 300 m.
Object (WCDMA): BTSSCW
Note: If this parameter is set, the parameter gpsTotalAntennaLineDelay
Object (GSM): GPS
must not be set.
Range: [30m (0), 100m (1),
Note: If an official NSN cable is replaced by a non-NSN delivered cable the
300m (2)]
parameter gpsTotalAntennaLineDelay must be used instead of this
Default: - parameter. NSN does not assure the validity of delay calculation when using
Multiplicity: 1 cables not ordered officially.

Modification: BTS restart needed Note: This parameter must not be used on SyncHub Slaves. Instead, the
parameter gpsTotalAntennaLineDelay must be used to compensate signal
Category: Basic propagation from the SyncHub Master to the SyncHub Slave.

36 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Related parameter
gpsCtrlBlockForCoLocatedBts GPS control interface blocked for co-located BTS
Object (LTE): BTSSCL This parameter controls the mode of operation of the GPS/1pps synchronization input
interface and defines if fault management is enabled for indicating faults related to the sync
Object (WCDMA): BTSSCW
signal provided by SyncHub Master BTS via the 1pps sync input:
Range: [false (0), true (1)] – false (0): The local BTS does not expect to receive 1pps sync signal from another BTS.
The lack of signal does not indicates to the system a fault condition, and the system does
Default: false (0)
not raise corresponding alarms. If, however, valid sync signal is provided by another BTS
Multiplicity: 1 via the 1pps sync input, it will be anyway used for synchronization of the local BTS (unless
there is another sync source with a higher priority). When connected to external GNSS
Modification: BTS restart
receiver, the local BTS will send TSIP control commands to the receiver, and will process
needed
TSIP response messages from the receiver.
Category: Basic – true (1): The local BTS expects to receive 1pps sync signal from another BTS. The lack
of the sync signal is considered a fault condition. The local BTS does not send any TSIP
commands for controlling a GPS receiver, but process received TSIP response messages
that are forwarded by the previous BTS in a 1pps synchronization chain.
Additionally, this parameter is also used for consistency checks with other parameters related
to the 1pps/GPS sync input.
Note: This parameter must be set to true (1) on SyncHub Slaves.
Note: On the SyncHub Master, this parameter must be set to false (0).

37 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Related parameter
gpsInUse GPS in use
Object (LTE): BTSSCL This parameter defines if GNSS receiver is connected to the system module:
Object (WCDMA): BTSSCW
– false (0): Indicates to the system that no external GNSS receiver is
connected to the 1pps/GPS sync input and that lack of signal at the sync input
Range: [false (0), true (1)] does not mean a fault condition.
Default: false (0) – true (1): Indicates to the system that an external GNSS receiver is
connected to the 1pps/GPS sync input and that the connected GNSS receiver
Multiplicity: 1 should provide a valid sync signal at the sync input.
Modification: BTS restart needed Independent from the setting of this parameter, a connected external GNSS
Category: Basic receiver will be activated and if it provides a valid signal to the 1pps/GPS sync
input, that signal will be used for synchronization of the BTS.
In addition to enabling the fault management, this parameter is also used for
consistency checks with other parameters related to the internal GNSS receiver.
Note: This parameter must not be set to true (1), if parameter
gpsCtrlBlockForCoLocatedBts is set to true (1). As a result gpsInUse
must be set to false (0) on SyncHub Slaves.

38 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New/Related parameter
gpsTotalAntennaLineDelay GPS antenna line delay
Object (LTE): BTSSCL This parameter is used to compensate sync signal propagation delay introduced by
a sync cable as well as delay introduced on the SYNC-IN and SYNC-OUT ports.
Object (WCDMA): BTSSCW
Note: This parameter must be used on SyncHub Slaves in a phase synchronized
Range: {1, 2000}
SyncHub chain or an RF sharing scenario to compensate signal propagation from
Step: 1 the SyncHub Master to the given SyncHub Slave.
Default: - Note: The parameter may also be used on the SyncHub Master instead of the
Unit: ns parameter gpsCableLength, if a 3rd party cable is used instead of NSN official
cable (30 m, 100 m or 300 m) to connect a GNSS receiver. The maximum length of
Multiplicity: 1 cable must be no more 400 meters, and an operator is obliged to measure the
Modification: BTS restart needed delay of the cable.
Category: Basic Note: If this parameter is set, the parameter gpsCableLength must not be set.
Note: In GSM the parameter gpsTotalAntennaLineDelay is only used on the
SyncHub Master and is not relevant to the feature SyncHub Direct Forward.
Instead, the parameter cablePropagationDelay performs the same role at
GSM BTS in compensation of phase offset between SyncHub Master and SyncHub
Slaves as the parameter gpsTotalAntennaLineDelay in other RATs.

39 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New/Related parameter
holdOverModeUsed Holdover Mode Usage In Temperature Control
Object (LTE): BTSSCL This parameter determines whether System Module fan speed is optimized by
oscillator temperature or noise level:
Object (WCDMA): BTSSCW
– false (0): The fan speed is controlled by different criteria, like minimization
Range: [false (0), true (1)] of noise.
Default: false (0) – true (1): The fan speed is controlled such that the temperature variation at
the OCXO is minimized, with the intention to minimize temperature dependent
Multiplicity: 1 phase drift during holdover. In the normal tuning mode, the fan speed is
Modification: BTS restart needed controlled differently, with the intention to cause some temperature changes at
the OCXO which are used for “learning” the temperature dependency of the
Category: Basic Phase Locked Loop.
Note: This parameter may be set to true (1), only if btsSyncMode is set to
PhaseSync (1).
Note: This parameter was introduced on WCDMA BTS by the feature RAN3001
Sync Hub Direct Forward to align sync capabilities among RATs and enable
WCDMA BTS to synchronize the phase and ToD from an external GNSS
receiver.

40 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Related parameter
rfSharingEnabled RF sharing enabled
Object (LTE): BTSSCL This parameter controls if RF sharing is enabled on the BTS.
Object (WCDMA): BTSSCW Note: In RF sharing scenarios SyncHub Slaves must have btsSyncMode set to
the value PhaseSync (1) even if phase synchronization is not required for
Range: [false (0), true (1)]
other RAT specific applications.
Default: false (0)
Multiplicity: 1
Modification: On-line
Category: Basic

41 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Related parameter
syncPropagationEnabled Forward synchronization in co-siting
Object (LTE): BTSSCL This parameter activates the feature "Synchronisation Hub“ and enables
regeneration of the sync signal on output synchronization interfaces (1PPS,
Object (WCDMA): BTSSCW
2MHz, PDH).
Range: [false (0), true (1)]
Note: This parameter must be set to true (1) on non-tail BTSs in SyncHub
Default: false (0) chains.
Multiplicity: 1 Note: SyncHub Slaves forward the 1PPS/ToD signal directly through the
Modification: On-line element, while SyncHub Master generates the 1PPS/ToD from the OCXO.

Category: Basic

42 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New parameter
actTempRadioMaster Activate temporary radio master role
Object (LTE): LNBTS This parameter activates the slave BTS in RF Sharing to temporarily take over
the radio master role upon the detection of the master failure.
Range: [false (0), true (1)]
Note: This parameter may be set to true (1) only if rfSharingEnabled is
Default: false (0)
set to true (1), and syncMaster in all SMOD MOC instances is set to true
Multiplicity: 1 (1).
Modification: On-line
Category: Basic

43 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New parameter
tempRadioMasterRecovTime Temporary radio master recovery time
Object (LTE): LNBTS This is the timer started in Temporary Radio Master state after it detects that
configured Radio Master has recovered. This is done to ensure that peer tech
Range: {0, 60}
BTS is stable enough to take over Radio Master role again.
Step: 1
Note: When this parameter is set to 0, there is no waiting period before the
Default: 1 Temporary Sync Master starts to use synchronization provided by the recovered
Unit: minute Sync Master.

Multiplicity: 1
Modification: On-line
Category: Basic

44 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New parameter
tempRadioMasterTriggerTime Temporary radio master trigger time
Object (LTE): LNBTS This is the timer started in Radio Slave state after slave BTS detects loss of
Radio Master, before it takes over Temporary Master Role. Wait time is used to
Range: {0, 60}
allow Radio Master to recover from a reset.
Step: 1
This is the timer started in Sync Slave state after slave BTS detects SYNC loss
Default: 5 (from Peer Technology BTS ) on RP3-01 ports. This is done to rule out any
Unit: minute maintenance activity planned for peer technology BTS.

Multiplicity: 1 Note: When this parameter is set to 0, there is no waiting period before the
Radio Slave takes over the Temporary Sync Master role.
Modification: On-line
Category: Basic

45 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Related parameter
syncMaster Synchronization master
Object (all RATs): SMOD This parameter defines source that is used on the BTS as a synchronization
reference in RF sharing scenarios:
Range: [false (0), true (1)]
– false (0): RP3-01 interface is used as a source of synchronization
Default: true (1) reference. If system module is configured to act as RP3-01 sync slave, it will
Multiplicity: 1 always use RP3-01 signal for synchronization and will never fallback to a
different sync input source even if available.
Modification: BTS restart needed – true (1): OCXO (and related selected sync input source) is used as a
Category: Basic source of synchronization reference.
Note: Prior introduction of the feature Sync Hub Direct Forward, system module
acting as a radio slave in an RF sharing setup had to be configured as an RP3-
01 sync slave. With introduction of the feature Sync Hub Direct Forward, the
radio slave may choose whether to use 1PPS/ToD as a sync input source, or
operate as before, using RP3-01 signal as sync input source.

46 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• Related parameter
btsSyncSource BTS Synchronization Source
Object (GSM): BTSNE This parameter can be used to configure BTS to take sync from 1PPS+TOD
clock signal coming from different sources when not BSC defined:
Range: [BSC defined (0),
1pps + ToD NodeB (1),
– BSC defined (0): Indicates that the BTS Sync source is defined from BSC
(in BTS_CONF_DATA). Display value is BSC Defined.
1pps + ToD ENodeB (2),
1pps + ToD GPS Device (3)]
– 1pps + ToD NodeB (1): Indicates that the user wants to use a Sync
Source which can not be defined by BSC and it is 1PPS+TOD received from
Default: BSC defined (0) peer NodeB BTS in CMCC format. Display value is peer 1PPS+ToD CMCC
Multiplicity: 1 format source.
– 1pps + ToD ENodeB (2): Indicates that the user wants to use a Sync
Modification: BTS restart needed Source which can not be defined by BSC and it is 1PPS+TOD received from
Category: Basic LTE e-NodeB or WCDMA NodeB (Protocol in TSIP format). Display value is
peer 1PPS+ToD TSIP format source.
– 1pps+ToD GPS Device (3): Indicates that the user wants to use a Sync
Source which can not be defined by BSC and it is 1PPS+TOD received from a
Third party GPS Device. Display Value is GPS 1PPS+ToD TSIP format
source.
Note: The value 1pps + ToD NodeB (1) is not supported with the feature
SyncHub Direct Forward.
47 Network Engineering / Sergey Antipov / 18 March 2015
Configuration Management

• New parameter
cablePropagationDelay Cable propagation delay
Object (GSM): BTSNE Specifies the cable compensation for the 1PPS signal to the 2G BTS from the
LTE e-NodeB or WCDMA NodeB (Protocol in TSIP format) sync source , used for
Range: {0, 2000}
cable delay compensation.
Step: 1
Note: This parameter has the same purpose as gpsTotalAntennaLineDelay
Default: 0 in WCDMA and LTE and is used in a similar way.
Unit: ns Note: This parameter should be specified when 2G BTS is configured to take
Multiplicity: 1 1PPS signal from the LTE e-NodeB or WCDMA NodeB (Protocol in TSIP format)
sync source.
Modification: BTS restart needed
Note: This parameter is used only if btsSyncSource parameter is set to value
Category: Basic 1PPS+ToD eNodeB.

48 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New parameter
holdover1ppsOutEnabled Holdover 1PPS clock output Enabled
Object (GSM): SMOD This parameter is used to control whether 1PPS/TOD should be active at
holdover.
Range: [false (0), true (1)]
Note: This parameter has the same purpose as ext1ppsClkOutOn in WCDMA
Default: true (1)
and LTE and is used in a similar way.
Multiplicity: 1
Note: This parameter is used only if the parameter syncHubEnabled is set to
Modification: BTS restart needed true (1).
Category: Basic

49 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New parameter
syncHubEnabled Sync Hub Enabled
Object (GSM): SMOD This parameter is used to enable or disable Sync Hub Direct Forward feature.
Range: [false (0), true (1)] Note: If BTS does not derive it's sync from a peer BTS, it will function as
SyncHub Master.
Default: false (0)
Note: This parameter may only be used if the BTS sync source is not in CMCC
Multiplicity: 1
format or if the sync is not derived from LMU. LMU as a sync source is a mode
Modification: BTS restart needed of sync source defined at the BSC. All the sync modes that can be defined at
Category: Basic BSC are encapsulated under one heading called "BSC defined". Hence if the
BTS sync source is configured as LMU at BSC, the user should take care that
this options is not selected with the BTS sync source as "BSC defined" in the
BTS manager or configurator tool.

50 Network Engineering / Sergey Antipov / 18 March 2015


Configuration Management

• New parameter
syncPropagationEnabled Forward 1PPS Clock Enabled
Object (GSM): SMOD This parameter is used to control whether PPS+ToD signal should be transmitted
on Sync Out port of Sync Hub Slave.
Range: [false (0), true (1)]
Note: This parameter is used only if syncHubEnabled is set to true (1).
Default: true (1)
Note: This parameter has a similar purpose as syncPropagationEnabled in
Multiplicity: 1
WCDMA and LTE.
Modification: BTS restart needed
Category: Basic

51 Network Engineering / Sergey Antipov / 18 March 2015


Table of Contents

Introduction Configuration Management


Motivation and Feature Overview Parameters and Parameterization Scenarios

Technical Details Deployment Aspects


Functionality and Implementation, Message Flows Activation, Configuration Examples, Fault Mgmt, Trial Area

Interdependencies
Interdependencies with other features and functions

Benefits and Gains


Simulation, Lab and Field Findings

52 Network Engineering / Sergey Antipov / 18 March 2015


Deployment Aspects
Use Cases

• Only frequency synchronization is required


• No RF sharing

gpsCtrlBlockFor syncPropagation gpsTotalAntenna


BTS Role btsSyncMode syncMaster ext1ppsClkOutOn rfSharingEnabled
CoLocatedBTS Enabled LineDelay

SyncHub Master default


false true FreqSync true true/false false
(SHM)

SyncHub Slave #1
true true FreqSync default true true/false false
(SHS#1)

SyncHub Slave #2
true true/false FreqSync default true true/false false
(SHS#2)

53 Network Engineering / Sergey Antipov / 18 March 2015


Deployment Aspects
Use Cases

• No RF sharing
• Phase sync is required on SyncHub Slave #2

gpsCtrlBlockFor syncPropagation gpsTotalAntenna


BTS Role btsSyncMode syncMaster ext1ppsClkOutOn rfSharingEnabled
CoLocatedBTS Enabled LineDelay

SyncHub Master
false true PhaseSync GNSS↔SHM true true/false false
(SHM)

SyncHub Slave #1
(SHS#1)
true true PhaseSync SHM↔SHS#1 true true/false false

SyncHub Slave #2
(SHS#2)
true true/false PhaseSync SHM↔SHS#2 true true/false false

54 Network Engineering / Sergey Antipov / 18 March 2015


Deployment Aspects
Use Cases

• Only frequency synchronization is required


• RF sharing

gpsCtrlBlockFor syncPropagation gpsTotalAntenna


BTS Role btsSyncMode syncMaster ext1ppsClkOutOn rfSharingEnabled
CoLocatedBTS Enabled LineDelay

SyncHub Master default


false true FreqSync true true true
(SHM)

SyncHub Slave #1
(SHS#1)
true true PhaseSync SHM↔SHS#1 true true true

SyncHub Slave #2
(SHS#2)
true true/false PhaseSync SHM↔SHS#2 true true/false true

55 Network Engineering / Sergey Antipov / 18 March 2015


Deployment Aspects
Use Cases

• RF sharing
• Phase sync is required on SyncHub Slave #2

gpsCtrlBlockFor syncPropagation gpsTotalAntenna


BTS Role btsSyncMode syncMaster ext1ppsClkOutOn rfSharingEnabled
CoLocatedBTS Enabled LineDelay

SyncHub Master
false true PhaseSync GNSS↔SHM true true true
(SHM)

SyncHub Slave #1
(SHS#1)
true true PhaseSync SHM↔SHS#1 true true true

SyncHub Slave #2
(SHS#2)
true true/false PhaseSync SHM↔SHS#2 true true/false true

56 Network Engineering / Sergey Antipov / 18 March 2015


Deployment Aspects
Use Cases

Backward compatibility use case:


• Radio master does not support the feature Sync Hub Direct Forward
• Only frequency synchronization is required
• RF sharing
gpsCtrlBlockFor syncPropagation gpsTotalAntenna
BTS Role btsSyncMode syncMaster ext1ppsClkOutOn rfSharingEnabled
CoLocatedBTS Enabled LineDelay

SyncHub Master default


true/false true/false FreqSync true true/false true
(SHM)

SyncHub Slave #1
true/false true/false PhaseSync default false true/false true
(SHS#1)

57 Network Engineering / Sergey Antipov / 18 March 2015


Deployment Aspects
Alarms

Fault name Radio slave has taken temporary radio master role
Fault ID and name 4220: EFaultId_TemporaryRadioMasterAl
Reported alarms 7654 CELL OPERATION DEGRADED
Unit status Degraded
LED display N/A
Meaning Radio slave has taken temporary radio master role because radio master is unavailable. Cell is otherwise
working normally but because radio slave cannot configure antenna line devices (for example MHAs) the
cell capacity is affected and thus the cell is reported as degraded.
Unit actions after fault detect None
Detection method Radio master either is missing at startup or is lost at runtime and radio slave has taken temporary radio
start/transient master role. Before radio slave takes temporary radio master role it will wait for radio master to become
available for a user defined time.
Detection method cancel Radio master is available and radio slave has given up temporary radio master role. Before radio slave
gives up temporary radio master role it will wait for a user defined time for radio master to stay available.
Effect None
Instructions Check that the radio master is powered on and that the RP3-01 cables of radio master are properly
attached

58 Network Engineering / Sergey Antipov / 18 March 2015

Vous aimerez peut-être aussi