Vous êtes sur la page 1sur 43

WCDMA RAN, Rel.

WCDMA
17, Operating Documentation,
Issue 09

Troubleshooting RF Sharing
DN09206431
Issue 03
Approval Date 2015-10-13

 
Troubleshooting RF Sharing

The  information  in  this  document  applies  solely  to  the  hardware/software  product  (“Product”)  specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).

This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes  defined  in  the  agreement  between  You  and  Nokia  (“Agreement”)  under  which  this  document  is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or  means  without  the  prior  written  permission  of  Nokia.  If  You  have  not  entered  into  an  Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.

The  document  has  been  prepared  to  be  used  by  professional  and  properly  trained  personnel,  and  You
assume  full  responsibility  when  using  it.  Nokia  welcomes  your  comments  as  part  of  the  process  of
continuous development and improvement of the documentation.

This  document  and  its  contents  are  provided  as  a  convenience  to  You.  Any  information  or  statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an  “as  is”  and  “as  available”  basis  in  this  document,  and  Nokia  reserves  the  right  to  change  any  such
information  and  statements  without  notice.  Nokia  has  made  all  reasonable  efforts  to  ensure  that  the
content  of  this  document  is  adequate  and  free  of  material  errors  and  omissions,  and  Nokia  will  correct
errors  that  You  identify  in  this  document.  Nokia's  total  liability  for  any  errors  in  the  document  is  strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.

NO  WARRANTY  OF  ANY  KIND,  EITHER  EXPRESS  OR  IMPLIED,  INCLUDING  BUT  NOT  LIMITED  TO
ANY  WARRANTY  OF  AVAILABILITY,  ACCURACY,  RELIABILITY,  TITLE,  NON-INFRINGEMENT,
MERCHANTABILITY  OR  FITNESS  FOR  A  PARTICULAR  PURPOSE,  IS  MADE  IN  RELATION  TO  THE
CONTENT  OF  THIS  DOCUMENT.  IN  NO  EVENT  WILL  NOKIA  BE  LIABLE  FOR  ANY  DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR  ANY  LOSSES,  SUCH  AS  BUT  NOT  LIMITED  TO  LOSS  OF  PROFIT,  REVENUE,  BUSINESS
INTERRUPTION,  BUSINESS  OPPORTUNITY  OR  DATA  THAT  MAY  ARISE  FROM  THE  USE  OF  THIS
DOCUMENT  OR  THE  INFORMATION  IN  IT,  EVEN  IN  THE  CASE  OF  ERRORS  IN  OR  OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.

Nokia  is  a  registered  trademark  of  Nokia  Corporation.  Other  product  names  mentioned  in  this  document
may be trademarks of their respective owners.

Copyright © 2018 Nokia. All rights reserved.

f Important Notice on Product Safety


  This product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only  trained  and  qualified  personnel  may  install,  operate,  maintain  or  otherwise  handle  this
product and only after having carefully read the safety information applicable to this product.

The  safety  information  is  provided  in  the  Safety  Information  section  in  the  “Legal,  Safety  and
Environmental Information” part of this document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We
would  like  to  encourage  you  as  our  customers  and  users  to  join  us  in  working  towards  a  cleaner,  safer
environment. Please recycle product packaging and follow the recommendations for power use and proper
disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia for any additional information.

2 © 2018 Nokia DN09206431 Issue: 03
Troubleshooting RF Sharing

Table of Contents
This document has 43 pages
   
Summary of changes..................................................................... 7
   
1 Introduction to troubleshooting RF Sharing....................................9
   
2 Key points to remember for the RF Sharing troubleshooting
process.........................................................................................10
   
3 Reference documents for RF Sharing.......................................... 11
   
4 Preventive maintenance for RF Sharing...................................... 13
4.1 Be aware of the known problems in SW releases........................13
4.2 Analyze active BTS alarms.......................................................... 14
4.3 Analyze BTS alarm history...........................................................15
4.4 Use TRX Continuous Transmission in 2G BTS Manager............ 16
4.5 Run TRX Test...............................................................................19
4.6 Fetch VSWR Values table............................................................ 20
   
5 Typical RF Sharing troubleshooting cases...................................22
5.1 Undetected RFMs........................................................................ 22
5.1.1 Undetected RFMs during or after commissioning........................ 22
5.1.1.1 Recovery procedure for detection problems with RFMs during or
after commissioning..................................................................... 22
5.1.2 Undetected RFMs when Sync Hub Direct Forward is in use....... 24
5.1.2.1 Recovery procedure for detection problems with RFMs when Sync
Hub Direct Forward is in use........................................................24
5.1.3 Undetected RFMs when GSM BTS hands back the Sync Master
role............................................................................................... 25
5.1.3.1 Recovery procedure for detection problems with RFMs when
GSM BTS hands back the Sync Master role................................25
5.2 Undetected System Module......................................................... 26
5.2.1 Recovery procedure for detection problems with System Module...
26
5.3 GSM commissioning failures........................................................26
5.3.1 Recovery procedure for GSM commissioning failure...................27
5.4 Unexpected RSSI or Rx Signal Level Failure alarms...................27
5.4.1 Recovery procedure for unexpected RSSI or Rx Signal Level
Failure alarms.............................................................................. 27
5.5 Unexpected VSWR alarms.......................................................... 29
5.5.1 Possible root cause of unexpected VSWR alarms.......................29
5.5.2 Recovery procedure for unexpected VSWR alarms.................... 33
5.6 TRX object allocation failed - GSM alarms.................................. 34
5.6.1 Recovery procedure for TRX object allocation failed................... 35
5.7 RF Module failure (0125) or (1900) alarm....................................35
5.7.1 Recovery procedure for RF Module failure alarm........................ 36

DN09206431 Issue: 03 © 2018 Nokia 3
Troubleshooting RF Sharing

5.8 Increased BER detected on the optical connection to Radio
Module (1955) fault...................................................................... 36
5.8.1 Recovery procedure for Increased BER detected on the optical
connection to Radio Module fault.................................................36
5.9 Incorrect filter shift in RX diversity sharing................................... 37
5.9.1 Recovery procedure for incorrect filter shift in RX diversity sharing.
37
5.10 Incorrect RP3 cabling...................................................................37
5.10.1 Recovery procedure for incorrect RP3 cabling............................ 38
5.11 Remote connection to the Slave BTS is lost................................ 39
5.11.1 Recovery procedure for loss of the Slave BTS remote connection..
39
5.12 Problems when Sync Hub Direct Forward is in use..................... 39
5.12.1 BTS reference clock missing during normal operation when Sync
Hub Direct Forward is in use........................................................39
5.12.1.1 Recovery procedure for BTS reference clock missing................. 40
5.12.2 PPS reference clock missing at startup when Sync Hub Direct
Forward is in use..........................................................................41
5.12.2.1 Recovery procedure for PPS reference clock missing at startup.....
41
5.12.3 Undetected RFMs when Sync Hub Direct Forward is in use....... 42
5.12.3.1 Recovery procedure for detection problems with RFMs when Sync
Hub Direct Forward is in use........................................................42

4 © 2018 Nokia DN09206431 Issue: 03
Troubleshooting RF Sharing

List of Figures
Figure 1 The reported Interference level value (I.LEV) equal to 0....................17
Figure 2 The reported Interference level value (I.LEV) not equal to 0..............18
Figure 3 Enable EIF2 as RP3-01 interface....................................................... 26
Figure 4 Typical C-type configuration of WCDMA-GSM RF Sharing................30
Figure 5 Recommended sector configuration...................................................32
Figure 6 Typical measurement setup................................................................33

DN09206431 Issue: 03 © 2018 Nokia 5
Troubleshooting RF Sharing

List of Tables
Table 1 RAT releases covered by the document...............................................7
Table 2 Input values........................................................................................ 31

6 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Summary of changes

Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
This document is common for Radio Access Technologies (RATs) listed in the below
table.
Table 1 RAT releases covered by the document
Radio Access Technology Product release
(RAT)
GSM/EDGE (BSS) GSM16, GSM17
WCDMA RAN WCDMA 16, WCDMA 17, WCDMA 18
Long Term Evolution FDD-LTE 16, FDD-LTE 16A, FDD-LTE17A

Changes between issues 02 (2015-09-18) and 03 (2015-10-13)

Typical RF Sharing troubleshooting cases


• Information on temporarily activated alarms has been added.

Changes between issues 01 (2015-06-16) and 02 (2015-09-18)

Key points to remember for the RF Sharing troubleshooting process


• Section has been updated.

Reference documents for RF Sharing


• References to Compatibility Matrix and RF-Sharing Regular Maintenance Newsletter
documents have been added.

Analyze active BTS alarms


• Step Run ZEOL (BSC) or ZAAP (RNC) or ZAHO (iOMS) command to obtain the
active BTS alarms has been updated.

Analyze BTS alarm history


• Step Check that BTS related alarms are not blocked (filtered out / not visible) with
ZEOE and ZEOO (BSC) or ZAFP (RNC) has been updated.
• Step Run ZEOH (BSC) or ZAHP (RNC and iOMS) command to obtain the active
BTS alarm history log has been updated.

Run TRX Test


• Information on TRX Test feature has been added.
• Detectable and preventable problems have been updated.

Fetch VSWR Values table


• Description has been updated.

Undetected RFMs

DN09206431 Issue: 03 © 2018 Nokia 7
   

Summary of changes Troubleshooting RF Sharing

• Section has been added to combine the cases related to problems with detection of
RFMs.

Recovery procedure for detection problems with RFMs during or after


commissioning
• Section has been updated.

Undetected RFMs when Sync Hub Direct Forward is in use


• Section has been added.

Undetected RFMs when GSM BTS hands back the Sync Master role
• Section has been added.

Undetected System Module


• Section has been added.

Unexpected RSSI or Rx Signal Level Failure alarms


• Faults 133 and 4046 have been added to symptoms.

Recovery procedure for unexpected RSSI or Rx Signal Level Failure alarms


• Step Check whether any external UL interference is present has been updated and
moved to the end of the list.
• Reference to RAN3060 and LTE1434 has been added to step Check whether
Passive Intermodulation (PIM) is present in the affected sector/cell.

Possible root cause of unexpected VSWR alarms


• Section has been added.

Recovery procedure for unexpected VSWR alarms


• Prerequisite has been added.

Recovery procedure for Increased BER detected on the optical connection to


Radio Module fault
• Step Check whether the cell configuration is supported has been updated.

Problems when Sync Hub Direct Forward is in use


• Section has been added to combine all sections related to SHDF.

BTS reference clock missing during normal operation when Sync Hub Direct
Forward is in use
• Note about secondary sync source for SyncHub Slaves has been added.

Recovery procedure for BTS reference clock missing


• Step If the reporting element is the Sync Hub Master has been updated.

8 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Introduction to troubleshooting RF Sharing

1 Introduction to troubleshooting RF Sharing


Explanation of troubleshooting in RF Sharing.

This document describes troubleshooting in RF sharing and in Rx diversity sharing,
however, the Rx diversity sharing term is not repeated, but treated as part of RF sharing.
Most of the terms and tools in this document are taken from RF sharing WCDMA-GSM
and LTE-GSM, but the general RF sharing troubleshooting principles are the same for
WCDMA-LTE, WCDMA-GSM, and LTE-GSM.

w NOTICE: This document is intended for competent enough persons only, having good
BTS, RF and system level skills. The document contains many detailed steps and
instructions and wrong conclusions can easily be drawn if used by non-competent
persons. The instructions can be modified and localized to take into account the local
requirements and specific network setups.
Troubleshooting overview
Troubleshooting is needed when a system does not perform as expected/designed while
finding the cause and correcting it correspondingly. In order to correct faults the
symptoms need to at first be detected and analyzed. It is also important to be able to
recognize whether the system is performing normally. In most cases, a systematic
approach works best: study, test, and plan before you act.

Troubleshooting RF sharing
After RF sharing deployment, it is possible to perform certain preventive activities
remotely to evaluate the condition of the BTS sites and to detect possible problems early.
These activities are listed in the Preventive maintenance for RF Sharing section.
Troubleshooting in RF sharing refers to tracing and correcting faults and unexpected
problems during or after RF sharing activation. The Typical RF Sharing troubleshooting
cases section covers most common troubleshooting scenarios and fault symptoms, such
as commissioning problems or unexpected alarms after the activation.

DN09206431 Issue: 03 © 2018 Nokia 9
   

Key points to remember for the RF Sharing Troubleshooting RF Sharing
troubleshooting process

2 Key points to remember for the RF Sharing


troubleshooting process
List of key points to remember when working on RF Sharing configurations:

• SW faults are listed in the LGF (List of Generic Faults) documents, published in
NOLS regularly. The LGF documents describe the current unsolved problems in
different SW releases as well as their possible workarounds and correction targets.
Although the documents are NW element and technology specific, they also contain
cases related to RF sharing configurations.
• In RF sharing configurations, only certain Master-Slave BTS SW combinations, SW
upgrade paths and configurations are tested, recommended and officially supported.
Using any other SW combinations, upgrade path or configuration might cause
unknown and unexpected problems. In worst-case scenario, the unsupported
upgrade path might permanently damage the HW.
• Check that the running BTS SW in the System Module (SM) is the correct version,
before commissioning. Upgrade the BTS SW, if needed.
• Always use the matching BTS Site Manager version, considering the running BTS
SW version.
• Check the BTS Site Manager Online Help to find troubleshooting instructions for
alarms and so on.
• In RF Sharing configurations, the Radio Master (either WCDMA or LTE) determines
the running RF module SW version for all shared RFMs. Therefore, if a certain RFM
SW fault causes a problem (for example, unexpected alarm) in Slave BTS, the
Master BTS SW upgrade might well be needed to fix it. So, check the Master
(WCDMA or LTE) LGF documents as well even if the problem is visible only in Slave
BTS.
• If Master BTS (WCDMA or LTE) configuration is changed after initial RF Sharing
activation, Slave BTS (GSM) must be recommissioned again by using the updated
Master BTS SCF file. For more details see the Recommissioning RF Sharing to
change particular settings in Master technology section in the Configuring RF
Sharing document. Failure to do this might cause unexpected alarms, sleeping cells
and so on, depending on which SCF parameters were changed in Master BTS.
• Some RFM/RRH modules might have different versions, which in turn have different
RF properties. For example, FXDA version A.101 has different DL and UL BW
compared to FXDA version A.203.
• Whenever an unexpected alarm is seen, first refer to the technology specific
troubleshooting documentation to seek alarm specific troubleshooting steps (GSM,
WCDMA, LTE).
• Never replace any BTS HW modules without conducting the troubleshooting
process. The root cause might be a known SW fault, a configuration error, use of
unsupported configuration or completely external to the BTS so replacing just HW
modules might not fix the root cause.
• Unexpected RSSI and/or Rx Signal Level failure alarms might occur after activating
RF Sharing and when antenna lines (and antenna element) are exposed to multiple
high power Tx carriers. In many cases, the root cause is Passive Intermodulation
(PIM). PIM products can occur in passive devices (for example, cables, antennas
and so on) and can cause severe interference in the Rx (UL) band. For a more
detailed explanation of PIM, see Avoiding Passive Intermodulation during RF Module
and RRH operation in the Flexi Multiradio BTS RF Module and Remote Radio Head
Description document.

10 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Reference documents for RF Sharing

3 Reference documents for RF Sharing


List of reference documents.

The following documents are available in Nokia Online Services (NOLS:
https://online.networks.nokia.com) and are important when working on RF Sharing
configurations:

• Classical RF Sharing Released Configurations


An Excel file containing details about configuration types, SW and bands, supported
configuration combinations and power levels, RFM/RRH properties and so on.
Available at the following NOLS directory: NOLS ► Product Information Center ►
Documentation finder ► Radio Network ► Base Stations ► Flexi Multiradio 10
BTS EDGE / Flexi Multiradio BTS EDGE / Flexi Multiradio BTS WCDMA / Flexi
Multiradio BTS LTE/AirScale BTS LTE  ► Operating documentation ► Classical
RF Sharing Released Configurations (XLS format)
• Nokia Base Station Optional Items Description
The Nokia Base Station cables and SFPs section listing the approved SFP types,
optical cable lengths and so on.
Available at the following NOLS directory: NOLS ► Product Information Center ►
Documentation finder ► Radio Network ► Base Stations ► Flexi Multiradio 10
BTS EDGE / Flexi Multiradio BTS EDGE / Flexi Multiradio BTS WCDMA / Flexi
Multiradio BTS LTE  ► Operating documentation ► GSM/EDGE BSS / WCDMA
RAN / LTE Radio Access, Rel. xx, Operating documentation, Issue yy (Online
format)
• Technical Support Notes (TSN)
There are many TSNs in NOLS and some of them contain important information
about supported SFP types, SM replacement procedures, configuration restrictions
and so on. Depending on the desired RF Sharing RAT combination, you can check
the potentially valid TSNs in all RATs. Always use the latest version of each TSN.
Available at the following NOLS directory: NOLS ► Product Information Center ►
Documentation finder ► Radio Network ► Base Stations ► Flexi Multiradio 10
BTS EDGE / Flexi Multiradio BTS EDGE / Flexi Multiradio BTS WCDMA / Flexi
Multiradio BTS LTE  ► Technical Support Note
• List of Generic Faults (LGF)
SW defects are listed in RAT specific LGFs, which are updated in NOLS regularly.
Always use the latest version of each LGF document.
Available at the following NOLS directory: NOLS ► Product Information Center ►
Documentation finder ► Radio Network ► Base Stations ► Flexi Multiradio 10
BTS EDGE / Flexi Multiradio BTS EDGE / Flexi Multiradio BTS WCDMA / Flexi
Multiradio BTS LTE  ► List of Generic Faults
• Flexi Multiradio BTS Descriptions
Contain, for example, Flexi Multiradio BTS RF Module and Remote Radio Head
Description (frequency bands, BW and so on).
Available at the following NOLS directory: NOLS ► Product Information Center ►
Documentation finder ► Radio Network ► Base Stations ► Flexi Multiradio 10
BTS EDGE / Flexi Multiradio BTS EDGE / Flexi Multiradio BTS WCDMA / Flexi
Multiradio BTS LTE  ► Operating documentation ► GSM/EDGE BSS / WCDMA
RAN / LTE Radio Access, Rel. xx, Operating documentation, Issue yy (Online
format)
• BTS troubleshooting documentation

DN09206431 Issue: 03 © 2018 Nokia 11
   

Reference documents for RF Sharing Troubleshooting RF Sharing

Use RAT specific troubleshooting documents to see detailed alarm specific
information.
Available at the following NOLS directory: NOLS ► Product Information Center ►
Documentation finder ► Radio Network ► Base Stations ► Flexi Multiradio 10
BTS EDGE / Flexi Multiradio BTS EDGE / Flexi Multiradio BTS WCDMA / Flexi
Multiradio BTS LTE  ► Operating documentation ► GSM/EDGE BSS / WCDMA
RAN / LTE Radio Access, Rel. xx, Operating documentation, Issue yy (Online
format)
• Compatibility Matrix
Contains the latest SW release combinations.
Available at the following NOLS directory: NOLS ► Product Information Center ►
Compatibility Matrix ► Compatibility Matrix - Access Networks

For the recommended SW combinations, NetAct compatibility with BTS SW and RF
Sharing, and the restrictions, see also RF-Sharing Regular Maintenance Newsletter. RF
Sharing Newsletter is published internally. For details, contact Technical Support.

12 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Preventive maintenance for RF Sharing

4 Preventive maintenance for RF Sharing


List of topics describing the preventive activities for RF sharing.

The activities listed in this section can be executed remotely to evaluate the condition of
the BTS sites and to detect possible problems early. They can be done regularly, but are
especially recommended before any special events where, for example, high traffic loads
expected. Furthermore, these activities can be used to troubleshoot the intermittent
alarms.
These preventive activities provide the following benefits:
• maximal BTS capacity
• reduced number of BTS alarms
• better KPIs
• fewer site visits
• reduced number of BTS HW module replacements

4.1 Be aware of the known problems in SW releases


Preventive action: Be aware of the known problems in SW releases.

Description
SW bugs are listed in the List of Generic Faults (LGF) documents, which are regularly
published in NOLS. The LGF documents describe the current unsolved problems in
different SW releases as well as their possible workarounds and correction targets.
Although the documents are product and technology specific, they also contain cases
related to RF sharing configurations.

Impact

• Unnecessary or wrong troubleshooting actions performed for problems already
known and explained in the LGF document.
• Possible workaround for known problems not used.
• Service outages and dropped calls because of unnecessary resets to overcome
sudden alarms.
• Unnecessary site visits and HW module replacements, which do not solve the root
cause.

Detectable and preventable problems

• Potential workaround for known problems (for example, unnecessary or unexpected
alarms).

DN09206431 Issue: 03 © 2018 Nokia 13
   

Preventive maintenance for RF Sharing Troubleshooting RF Sharing

Preventive actions

Procedure

1 Check the current BSC, RNC and BTS SW releases used in the live network.

2 Download the latest LGF documents from NOLS.

Always use the latest document version.

3 Analyze the cases listed in the LGF to find potential problems, which might be expected
considering the current SW levels.

4 Consider making BSC, RNC or BTS SW upgrade to fix known problems.

4.2 Analyze active BTS alarms


Preventive action: Analyze active BTS alarms.

Description
Active BTS alarms and disturbance observations detected in the radio network are
stored in BSC, RNC, and iOMS and can be viewed for analysis.

Impact
Active alarms might indicate a blocked site or object, reduced site capacity and so forth.

Detectable and preventable problems

• configuration problems
• cabling or connector issues
• external interference
• power supply issues
• poor transmission
• hanging alarms
• broken HW and so forth

Preventive actions

Procedure

1 Check that BTS related alarms are not blocked with ZEOE and ZEOO (BSC) or ZAFP
(RNC).

14 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Preventive maintenance for RF Sharing

2 Run ZEOL (BSC) or ZAAP (RNC) or ZAHO (iOMS) command to obtain the active BTS
alarms.

3 Analyze active alarms and their supplementary information fields.

4 Check the List of Generic Faults (LGF) document for any known issues.

5 Troubleshoot each alarm by following alarm specific instructions.

4.3 Analyze BTS alarm history


Preventive action: Analyze BTS alarm history.

Description
Historical BTS alarms and disturbance observations are stored in BSC, RNC, and iOMS
and can be viewed for analysis.

Impact
Alarm history might reveal hiding problems and give important information when
troubleshooting various issues.

Detectable and preventable problems

• sites in reset loops
• intermittent alarms
• occurrence of an issue happened always at a certain time
• occurrence of an issue happened after the site visit (check MMI connection alarm in
GSM or a door alarm if EAC is used)
• external interference and so forth

Preventive actions

Procedure

1 Check that BTS related alarms are not blocked (filtered out / not visible) with ZEOE and
ZEOO (BSC) or ZAFP (RNC).

2 Run ZEOH (BSC) or ZAHP (RNC and iOMS) command to obtain the active BTS alarm
history log.

DN09206431 Issue: 03 © 2018 Nokia 15
   

Preventive maintenance for RF Sharing Troubleshooting RF Sharing

3 Analyze alarms and their supplementary information fields with suitable log analyzer.

4 Check the List of Generic Faults (LGF) document for any known issues.

5 Search for any intermittent (start/cancel) alarms, pay attention to the time stamps.

6 Seek for behavioral patterns (is alarm activated/cancelled at certain times) or preceding
events, which can help identify the root cause.

7 If intermittent Rx Signal Level failure (WCDMA), RSSI (GSM) or VSWR alarms are
found, use TRX Continuous Transmission and TRX Tests (in GSM) to troubleshoot
further.

8 Check for 7708 – TRX RESTARTED alarm events.

Sub-steps

a) Typically most of 7708 alarm events are expected after recovery from power
breaks or manual TRX/BTS/BCF lock/unlock activities.

b) If there are any 7708 alarm events, which have occurred with no preceding
alarms or activities, troubleshoot further. The alarms might indicate a problem in
the site.

4.4 Use TRX Continuous Transmission in 2G BTS


Manager
Preventive action: Use TRX Continuous Transmission in 2G BTS Manager.

Description
TRX Continuous Transmission test starts Tx transmission on all timeslots on the selected
TRX.

Impact

• No impact on ongoing traffic, if it exists.
• No impact on BCCH TRX as it is transmitting on all timeslots anyway.
• All selected TCH-TRXs transmits at full power which temporarily increases the DL
interference.

Detectable and preventable problems

16 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Preventive maintenance for RF Sharing

• PIM (Passive Intermodulation) problems in antenna lines
• RSSI alarms
• VSWR alarms
• power supply (rectifier) capacity problems or lose power cable connections

Preventive actions

Procedure

1 Start BSC MML connection.

2 Establish Remote 2G BTS Manager connection.

3 Start TRX Continuous Transmission test on 2G BTS Manager on as many TRXs as
possible.

The test automatically stops after a timeout and therefore it is best practice to
activate as many TRXs as possible.

4 Check interference level.

Sub-steps

a) While the test is running, run ZERO command for a few times on BSC MML and
check the reported Interference level values.

b) The reported Interference level value (I.LEV) should be 0 for all TRXs as shown
in the figure. This is expected result indicating no UL interference.

Figure 1 The reported Interference level value (I.LEV) equal to 0

DN09206431 Issue: 03 © 2018 Nokia 17
   

Preventive maintenance for RF Sharing Troubleshooting RF Sharing

c) If the I.LEV values rise while the test is running, one of the reasons might be PIM
problem in the antenna line, which generates interference in the UL. In the figure,
I.LEV was 0 before the test but rose to 4 while TRX Continuous Transmission
test was running.

Figure 2 The reported Interference level value (I.LEV) not equal to 0

5 Check impact on peer BTS.

In RF sharing configurations, also check the impact on WCDMA BTS (monitor Rx
Signal Level values in 3G BTS Site Manager, if the feature license is active).

6 Check alarms.

Sub-steps

a) Check active alarms in 2G BTS Manager Alarms view.

b) If VSWR alarms are started, follow alarm specific troubleshooting steps.

c) If RSSI alarms are started, follow alarm specific troubleshooting steps.

d) In RF Sharing configurations, also check if any new alarms in the peer
technology BTS Manager.

7 Check site stability.

Sub-steps

a) Activate TRX Continuous Transmission on as many TRXs as possible to
maximize the BTS power consumption.

b) Check that the site remains stable and that all modules are visible in 2G BTS
Manager while the test is running.

18 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Preventive maintenance for RF Sharing

c) Any problems might indicate issues with the power supply (too small capacity,
loose connectors and so forth).

4.5 Run TRX Test


Preventive action: Run TRX Test.

Description
TRX Test runs a Tx-to-Rx loop test for a selected TRX object. Two free radio timeslots
are needed for the test. The test cannot be run for BB or antenna hopping sectors.
For information on the TRX Test feature, see the Feature Descriptions document in GSM
Operating documentation.

Impact
No impact on ongoing traffic in other timeslots.

Detectable and preventable problems

• Lost or missing RF cables
• 7607 – RSSI alarms
• 7725 - Traffic channel activation failure alarms
• 7744 - Excessive TCH interference alarms
• 7745 - Channel failure rate above defined threshold alarms
• Possible RP3 collision problems with shared RFMs when there is no traffic

Preventive actions

Procedure

1 Actions for BSC MML.

Sub-steps

a) Start TRX Test from BSC (ZUBS) TRX (run the test for at least one TRX per
sector).

b) Print results (ZUBP).

DN09206431 Issue: 03 © 2018 Nokia 19
   

Preventive maintenance for RF Sharing Troubleshooting RF Sharing

2 Actions for BTS Manager.

Sub-steps

a) Establish (local or remote) 2G BTS Manager connection.

b) Run TRX Test for the specified TRX (run the test for at least one TRX per sector).

c) If TRX Test fails, follow instructions given in the TRX test run from the BSC


section in Trouble Management of Flexi Multiradio BTS GSM/EDGE document
for next steps.

3 Check reported Rx Result.

Sub-steps

a) Check the Rx Result values for both Main and Diversity branches:

• Typical 2G UL (Rx) level values in live networks range from -100 to -112 dBm
for both RxD and RxM when no excessive UL interference is present.
• If a very low value is reported (for example, -114 dBm or lower which might
be unrealistic) in either RxD or RxM, it indicates that the BTS is not receiving
the UL interference correctly indicating problems in the physical UL path.
• Both RxM and RxD values must be quite equal as in typical antenna line
configuration both branches are receiving signal from the same antenna.
However, if there is a big (several dB) difference between the values, it
indicates problems in the physical UL path.

b) Visit the site and check for any possible problems.

4.6 Fetch VSWR Values table


Preventive action: Fetch VSWR Values table.

Description
2G BTS O&M SW collects VSWR samples every minute and enters them into an internal
database from each Tx/Rx antenna port. The database contains samples from the last
60 min (monitoring period). Monitoring begins when the BCF reaches the Supervisory
(WO) state. The period then restarts every 60 minutes automatically. A table containing
RAW and NEWEST VSWR Values can be fetched via Supervision | VSWR menu in 2G
EM:

20 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Preventive maintenance for RF Sharing

• RAW VSWR Value: An average over the last X minutes (from 1 to 60) since the
beginning of last 60 min monitoring period. The value is updated in database every
minute.
• NEWEST VSWR Value: The average over the last complete 60 min monitoring
period. The value is updated every 60 minutes.

The 60 min timer used to collect the VSWR values is the same as the one used for the
2G RSSI monitoring feature.
For monitoring VSWR information via BTS Site Manager in WCDMA, see RAN2304:
VSWR Monitoring.

Impact
No impact on ongoing traffic, if it exists.

Detectable and preventable problems

• developing problems in antenna lines
• Rx Signal Level, RSSI or VSWR alarms

Preventive actions

Procedure

1 Establish (local or remote) 2G BTS Manager connection.

2 Under Supervision menu, fetch VSWR Values table.

3 Compare the reported results with the current thresholds. If the reported values are near
to the current (alarm) thresholds, VSWR alarms might occur sooner or later. In this case,
check all the antenna line equipment and if no obvious problems are found, consider
adjusting the thresholds to avoid unexpected alarms later.

DN09206431 Issue: 03 © 2018 Nokia 21
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

5 Typical RF Sharing troubleshooting cases


List of topics describing the most common problems and solutions to them in RF
sharing.

During or after RF sharing activation, unexpected problems might occur. The purpose of
this section is to provide help when troubleshooting typical problems, such as
commissioning problems or unexpected alarms after RF Sharing activation.
Whenever an unexpected alarm is raised, the latest technology specific troubleshooting
documentation (GSM, WCDMA or LTE) must be checked for alarm specific
troubleshooting steps. This information is not repeated in the Troubleshooting RF
Sharing document, apart from couple of examples listed in this section.
The alarms might temporarily be activated also in Slave RAT during the Master RAT SW
upgrade. However, no unexpected alarms should remain active after the SW upgrade is
completed and the site is back On Air.
When troubleshooting live sites, always perform remote troubleshooting first by using
remote BTS Site Manager connections.
Most examples in this section describe RF sharing GSM-WCDMA troubleshooting,
however they can also be applied to RF sharing GSM-LTE.

5.1 Undetected RFMs


List of topics related to problems with RF Modules detection.

5.1.1 Undetected RFMs during or after commissioning


Effects of and solution to problems with detection of RFMs during or after
commissioning.

Symptoms
The RFMs are not visible in BTS Site Manager during or after commissioning.

Description
The dedicated or shared RFMs are not detected in BTS Site Manager during or after
commissioning.

5.1.1.1 Recovery procedure for detection problems with RFMs during or


after commissioning

Steps to resolve the problem.

22 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

Procedure

1 Check that the RF sharing enabled option is selected in the Master BTS


Commissioning.

2 Check that the RP3 and 1PPS sync link is enabled between Master and Slave SM:

• Check that the Slave SM is visible (RP3) in the Master BTS Site Manager.
• Check BTS Properties - Sync source (to check 1PPS) in the Slave BTS Site
Manager.

3 Check that BCF object synchronization parameters are correctly set in BSC, when using
FSMF module for GSM.

The sync settings in BSC differ between the FSMF and the ESMB/C.

4 Check that the RF Sharing license is active in WCDMA BTS.

5 Check that the RP3 sync cable between the Master and Slave SM is physically
connected in the correct optical ports and the correct SFP types are used and properly
fitted.

6 Check that the GSM is commissioned with the current Master's SCF.

7 Check that the RFM optical cables are connected into correct OPT ports in each SM.

8 Check that the correct and supported SFP plug-in types and manufacturers are used in
both ends of each optical cable.

9 Check that the correct type of fiber cables are used.

10 Check that the target configuration is supported considering the BTS SW levels being
used.

11 Block / un-block the RFM (RFM takes reset) from the Master technology.

12 Check that the RFMs are powered up.

DN09206431 Issue: 03 © 2018 Nokia 23
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

13 Toggle RFM 48 VDC supply via Power Control menu in BTS Site Manager (only possible
if the RFM Power cables are connected into SM).

14 Perform HW reset from 2G EM.

15 If the problem persists, switch off the Slave SM and then commission Master SM to
dedicated mode to determine, whether the problem is related to SW configuration or HW.

Repeat if necessary by switching off the Master SM and then commission Slave SM
into Dedicated mode instead.

16 Use Rx/Tx Statistics and SIR to check the SFP/RP3 status.

5.1.2 Undetected RFMs when Sync Hub Direct Forward is in use


Effects of and solution to problems with RF Modules detection and commissioning of
new BTS (as SyncHub Master/Radio Slave) when Sync Hub Direct Forward is active.

Symptoms
When new, un-commissioned BTS is connected to the site with Sync Hub Direct
Forward, shared RFMs are undetected by BTS Site Manager. The commissioning can
subsequently not commence.

Description
Site with a single BTS is extended for RF sharing with Sync Hub Direct Forward. The
new BTS operates as a SyncHub Master/Radio Slave. After connecting the new BTS the
shared RFMs are undetected and commissioning cannot proceed.
Pre-conditions:
BTS working as SyncHub Master/Radio Slave is un-commissioned.
BTS working as SyncHub Slave/Radio Master is commissioned and operational.

5.1.2.1 Recovery procedure for detection problems with RFMs when Sync
Hub Direct Forward is in use

Steps to resolve the problem.

Before you start


• Check that BTS is synchronized. In Sync Hub scenario radios are not detected if
BTS does not receive synchronization.
• Check the PPS reference clock missing at startup when Sync Hub Direct Forward is
in use section.

24 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

To resolve the problem, either commission the BTS remotely via NetAct with an SCF file
(if available), or perform the following procedure:

Procedure

1 Power down the BTS acting as the SyncHub Slave/Radio Master.

2 Reset the un-commissioned BTS acting as the SyncHub Master/Radio Slave.

3 Commission the BTS acting as the SyncHub Master/Radio Slave via the BTS Site
Manager.

4 If the BTS acting as the SyncHub Master/Radio Slave is commissioned, power up the
BTS acting as the SyncHub Slave/Radio Master.

5.1.3 Undetected RFMs when GSM BTS hands back the Sync
Master role
Effects of and solution to detection problems with RFMs when the GSM BTS hands back
the Sync Master role.

Symptoms
The GSM SM cannot detect the RFMs after it handed back the Sync Master role.

Description
In GSM, when synchronization with the Master BTS is lost, the GSM SM temporarily acts
as the Synchronization Master. The GSM BTS hands back the Sync Master role after the
synchronization from the original Master BTS is regained, but GSM BTS still does not
detect the RFMs.

5.1.3.1 Recovery procedure for detection problems with RFMs when GSM
BTS hands back the Sync Master role

Steps to resolve the problem.

Procedure

1 Check that the Master SM detects RFMs.

If the Master SM detects RFMs but the Slave SM does not then the problem most
probably concerns the RP3-01 synchronization between technologies.

DN09206431 Issue: 03 © 2018 Nokia 25
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

Select from the available options

• Check the cable, the SFP and the master configuration (RP3 port) in case of
FSMF.

5.2 Undetected System Module


Effects of and solution to detection problems with the System Module in case of FSMF.

Symptoms
The FSMF is not detected when it assumes the Slave role.

5.2.1 Recovery procedure for detection problems with System


Module
Steps to resolve the problem.

Procedure

1 Check that the TRS parameter "Enable FSM EIF2 as RP3-01 interface" is selected in the
master and/or slave FSMF.

Figure 3 Enable EIF2 as RP3-01 interface

5.3 GSM commissioning failures


Effects of and solution to GSM commissioning failure.

Symptoms

26 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

Despite a successful start-up of GSM commissioning, the process ultimately fails or an
unexpected alarm is reported.

Description
Send SCF button is grayed out in GSM BTS Site Manager at the end of commissioning.
After pressing Send SCF button, the commissioning initially starts but ultimately fails or
an unexpected alarm is reported.

5.3.1 Recovery procedure for GSM commissioning failure


Steps to resolve the problem.

Procedure

1 Ensure that the GSM BTS Site Manager version corresponds with the GSM BTS SW
version.

2 Check that the target configuration is supported considering which the BTS SW and HW
are in use.

3 Select Undo Commissioning option in GSM BTS Site Manager, select also Remove
traffic bypass capacity option and try the commissioning again.

To save time and minimize possible errors, retrieve and store the existing GSM SCF
and use it later as a template to commission GSM transmission parameters.

5.4 Unexpected RSSI or Rx Signal Level Failure alarms


Effects of and solution to unexpected RSSI or Rx Signal Level Failure alarms.

Symptoms

• WCDMA: 7654 CELL OPERATION DEGRADED - 133 Rx signal level


failure , 134 Rx signal level failure alarm is raised.
• LTE: 7654 CELL OPERATION DEGRADED - 4046 Antenna line
operation degraded alarm is raised.
• GSM: 7607 TRX OPERATION DEGRADED - RSSI detected Rx signal
difference exceeding threshold alarm is raised.

5.4.1 Recovery procedure for unexpected RSSI or Rx Signal


Level Failure alarms
Steps to resolve the problem.

DN09206431 Issue: 03 © 2018 Nokia 27
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

Procedure

1 Check that the GSM is commissioned with the current Master (WCDMA or LTE) BTS
SCF.

2 Check that the BTS is commissioned correctly.

Ensure that especially MHA and any other optional antenna line devices having an
impact on total UL gain are correctly taken into account in commissioning.

3 In case Rx diversity sharing configuration is used:

Select from the available options

• Check that all RF cross-connection cables are firmly fitted and in the correct
antenna ports of each RFM.
Select from the available options

• Check that the BTS is commissioned correctly, paying special attention to total
gain and UL filter position in each Rx chain. For further details, see the RX
diversity sharing section in the Configuring RF Sharing document.
Select from the available options

• The parameters for WCDMA Master Additional RX- gain and Feeder


loss need to be correctly commissioned.

4 Check whether Passive Intermodulation (PIM) is present in the affected sector/cell.

Use TRX Continuous Transmission option in GSM BTS Site Manager, for details


see the Use TRX Continuous Transmission in 2G BTS Manager section.
For PIM detection, see RAN3060: Flexi Multiradio BTS Antenna Rx RF-sniffing and
LTE1434: Flexi Multiradio BTS Antenna Rx RF-sniffing features.

5 Check which RFM/RRH the alarming TRX objects are allocated in:

Select from the available options

• Shared RFM/RRH: Check the latest WCDMA/LTE BTS LGF for any known SW
bugs.
• Dedicated GSM RFM/RRH: Check the latest GSM BTS LGF for any known SW
bugs.

6 Check whether any external UL interference is present.

Site visits with a spectrum analyzer might be required to check this.

28 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

5.5 Unexpected VSWR alarms


Effects of and solution to unexpected VSWR (Voltage Standing Wave Ratio) alarms.

Symptoms

• WCDMA: 7654 CELL OPERATION DEGRADED - 1838 VSWR minor alarm


alarm is raised.
• GSM: 7607 TRX OPERATION DEGRADED - RF Module detected VSWR
above minor limit alarm is raised.

5.5.1 Possible root cause of unexpected VSWR alarms


Possible root cause of the problem with unexpected VSWR alarms.

Description

g Note: When VSWR alarms are raised, do not replace any RFMs/RRHs until fully
establishing the root cause of the incident.

Despite there being no problems with the BTS itself, VSWR alarms can be raised even
when antenna line sweep (Return Loss / VSWR) tests made with external test equipment
do not report any problems.
The RL (Return Loss) measures the reflected power of the system compared to the
transmitted power. In an ideal situation, all BTS Tx power is radiated by the BTS antenna
and no power is reflected back. In real situations however, some of the own BTS Tx
power is always reflected back because of RF mismatch between antenna line
components, for example, between the antenna and feeder line connectors. The RL is
generally used to determine condition of the antenna line and can also be expressed as
the VSWR value.
During normal BTS operation the condition of the Tx antenna line is continuously
monitored with the VSWR feature:
• Antenna VSWR measurement in GSM
• RAN907: Antenna line supervision in WCDMA
It is an optional feature, which requires a specific SW license before VSWR alarms
are visible. Without the license, only 4057 Radio resources switched off
fault is raised and Tx transmission is disabled to protect the HW from excessive
VSWR value conditions (for example, when jumper cable is disconnected).
RAN2304: VSWR Monitoring in WCDMA from WCDMA 16 onwards
This feature shares the same license with RAN907: Antenna Line Supervision.
• LTE899: Antenna Line Supervision in LTE

The VSWR circuitry within the RFM and RRH consist of directivity coupler and power
detection for forward and reverse signals. The detector for the reverse power is wide-
band and can only measure the total reverse power level within the BTS Tx band.
The total reverse power seen by the BTS can include RF power from up to three different
sources:

DN09206431 Issue: 03 © 2018 Nokia 29
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

• Reflected power caused because of RF mismatch in antenna line components.
• External RF signals, even out-of-band (for example, from other nearby BTS or
reflection from any obstacle or structure near the BTS antenna).
• Internal leakage between the own antenna lines, for example between two antenna
ports in a typical X-pol antenna.

During normal BTS operation, all BTS Tx signals are present and a certain RFM antenna
port can only compare its own forward and total reverse power to determine the VSWR
condition of the antenna line. The RFM can measure its own Tx power very accurately
however, due to a certain level of tolerance when measuring the total reverse power,
accuracy of the results in VSWR measurements is also limited. These limitations are of
no major concern considering any typical BTS use cases where VSWR alarms are
raised in case of any obvious problems are detected.
Considering a typical BTS site with antenna lines that are in good condition, the reverse
power generated by the leakage (for example, in X-pol antenna between antenna ports)
can be the highest when comparing it to the reflected power caused by RF mismatch in
the antenna line components. This reverse power (caused by leakage) is not present
when using external antenna line test equipment. Therefore measured VSWR values
cannot be used in BTS commissioning as such. This can lead to situations where no
obvious problems are seen during the measurements but intermittent VSWR alarms still
occur during normal BTS operation. This depends on BTS configuration, isolation
between the antenna lines (incl. isolation value of the X-pol antenna itself), the VSWR
minor and major alarm threshold values and the traffic conditions.
Figure 4: Typical C-type configuration of WCDMA-GSM RF Sharing presents an example
RF sharing configuration where these alarms can be expected (focus on sector 1 only).

Figure 4 Typical C-type configuration of WCDMA-GSM RF Sharing
GSMBCCH TRXpower
A + TCH TRXspower
+WCDMA TXpower
X-polantenna
B GSM TCH TRXspower

C Leakagepower
C
Powerreflected
D duetoRFmismatch
Sumofleakagepower
E andreflectedpower D E
RFM-1
A

B
RFM-2

30 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

Description of the configuration in the example:

• WCDMA-GSM RF Sharing with 1+1+1 40W in WCDMA and 4+4+4 20W in GSM.
• Two shared RFMs are referred as RFM-1 and RFM-2.
• Local Cell 1 in WCDMA is commissioned to use RFM-1 Ant1 for Tx/Rx and RFM-2
Ant1 for RxDiv.
• Local Sector 1 in GSM is commissioned to use RMF-1 Ant1 and RFM-2 Ant1 and
has internally (by using the automatic Resource Allocation Algorithm) allocated the
BCCH TRX and one TCH TRX into RFM-1 Ant 1 and remaining two TCH TRXs into
RFM-2 Ant1.
• VSWR Minor threshold value set to 1.5.
• X-pol antenna is with limited isolation between the two antenna ports.
• RxDiv signals are passed in optical cables and via the System Module between two
RFMs.

As presented in the figure, RFM-1 Ant1 contains continuous high Tx power level
because of GSM BCCH and WCDMA carrier allocations. However, RFM-2 Ant1 port
contains TCH-TRXs only which can, at times, transmit at very low power levels because
of DL power control algorithm in BSC.
Calculation of Return Loss / VSWR for this example configuration
Table 2 Input values
Property Value
Average RL of the antenna line 20 dB (VSWR 1,22)
Isolation in X-pol antenna between the antenna ports 27 dB

ForwardPowerinRFM-1Ant1:
2GBCCHTRX20W+43.0dBm
3Gcarrier40W+46.0dBm
Total60W+47.8dBm

ForwardPowerinRFM-1Ant1:
2GTCHTRX2W+33.0dBm(duetoDLpowercontrol)

ReversePowerdetectedbyRFM-2Ant1:
ReflectedpowerduetoRL+13.0dBm(+33.0dBm-20dB)
OthersamebandTxsignal-30.0dBm(justanexamplevalue)
Reversepowerduetoisolation+20.8dBm(+47.8dBm-27dB)
Totalreversepower+21.5dBm

RL/VSWRconditionseenbyRFM-2Ant1:
Forwardpower2W+33.0dBm
Reversepower(total)+21.5dBm
Returnloss:11.5dBm(ConvertstoVSWR1.7)

Conclusions:
• Total reverse power detected by RFM-2 Ant 1 consists of three sources from which
the reverse power is clearly the highest. This is because of limited antenna isolation
• True RL of both antenna lines is 20 dB (VSWR 1.22) as measured with external
antenna line test equipment.

DN09206431 Issue: 03 © 2018 Nokia 31
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

• However, the VSWR condition reported by RFM-2 is 1.7, which triggers VSWR minor
alarm as it exceeds the alarm threshold (1.5 in this example).

In the above example the highest and dominating component is the leakage from the
other antenna port. But the total reverse power can be high also because of the high-
level external Tx signal coming, for example, from another nearby BTS. High total
reverse power can also be caused by the leakage coming from an external combiner
used in the antenna lines.
The expected VSWR / Return Loss measurement tolerance in the RFM and RRH HW
circuitry is ±2.6 dB. This tolerance is not considered in the example calculation shown
above but can have an adverse impact, causing some VSWR alarms to become more
sensitive. For details, see VSWR feature descriptions.

Recommended solution
Figure 5: Recommended sector configuration presents a recommended sector
configuration.

Figure 5 Recommended sector configuration
WCDMA RXDiv
A GSMBCCH TRX
GSM TCH TRX
WCDMA TX/RX
B GSM TCH TRXs

RFM-1
A

RFM-2
B

To reduce the risk of the increased reverse power, configure GSM BCCH TRX and
WCDMA carriers in different antenna ports to ensure that the forward power in both
antenna ports is high compared to the total reverse power in normal BTS condition (that
is no problems in antenna lines). This ensures the BTS can detect the real antenna line
problems rather than generating unexpected VSWR alarms caused by antenna leakage.
In the recommended configuration, the BCCH TRX is on a separate antenna port than
the WCDMA carrier. During WCDMA commissioning, the antenna port usage (Tx/Rx or
RxDiv) can be defined by user whereas in GSM, the Resource Allocating Algorithm
allocates the TRXs automatically on the user-defined antenna ports.
However, in some configurations TCH TRX only antenna lines cannot be avoided. In
these cases, any reverse RF power could cause unexpected VSWR alarms, especially if
low VSWR alarm threshold is used.

Additional measurement of reverse power

32 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

The forward and reflected power levels in a certain antenna line can be measured using
an external power meter equipped with a directional power sensor while the BTS is in
normal operation mode and handling traffic. The power meter and sensor must be
selected by considering the BTS Tx power level, used the frequency band, possible DC
voltage in the feeder line (if MHA’s are used) and so on.

w NOTICE: In order to prevent damage to equipment and ensure accurate results, the
tests must be conducted by an experience system engineer with advanced RF skills
and highly trained in operating BTSs.

Figure 6 Typical measurement setup

A ForwardPower

B ReversePower

A B
RFM-1

Directional
PowerSensor
RFM-2 RFPowerMeter

Note that RFM internal VSWR measurement has much wider tolerance compared to
directional power sensor.

5.5.2 Recovery procedure for unexpected VSWR alarms


Steps to resolve the problem.

Before you start


Ensure that the RF sharing configuration has the well-balanced forward powers in
antenna ports in order to avoid raising unnecessary and unexpected VSWR alarms, for
details see the Possible root cause of unexpected VSWR alarms section.

Procedure

1 Check which antenna port the alarming TRX objects/WCEL are allocated in by using
GSM/WCDMA BTS Site Manager.

DN09206431 Issue: 03 © 2018 Nokia 33
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

2 While the VSWR alarm is active, establish a GSM BTS Site Manager connection and
select Supervision | VSWR values.

3 Check the newest and raw VSWR values of the affected antenna port with the Current
Threshold values to determine, whether there is a true problem in the antenna lines or
whether the threshold values are too sensitive in the alarming sector/cell.

4 Use TRX Continuous Transmission option in GSM BTS Site Manager, for details see


the Preventive maintenance for RF Sharing section.

g Note: Like other BTS parameters, the VSWR minor and major values should be
selected according to the physical BTS environment to ensure that BTS detects real
VSWR problems while avoiding unnecessary alarms. For example, the VSWR condition
might be diminished if there are any causes for increased reverse power, such as two
main antenna ports that are connected to an external combiner with poor isolation that
is causing RF leakage (reverse power) between ports. Other typical reason for
increased reverse power is leakage between the two ports in X-pol antenna, which can
cause intermittent VSWR alarms. The VSWR condition can also be expected to
fluctuate if the antenna element vibrates during heavy wind periods.

g Note: The expected VSWR / Return Loss measurement tolerance in the RFM and
RRH HW circuitry is ±2.6 dB. So for example, when the default VSWR minor limit 1.9 is
used (= Return Loss 10 dB) the minor VSWR alarm (7607) is triggered if the real Return
Loss condition is between 7.4 to 12.6 dB.

5.6 TRX object allocation failed - GSM alarms


Effects of and solution to TRX object allocation failed alarm in RF sharing.

Symptoms

• WCDMA:
– Cells in the shared RFMs/RRHs stay on air.
– The carriers are operational. The minor faul Licence missing... (1885)
is reported.

• GSM:
– 7606 TRX FAULTY TRX object allocation failed in RF Module
fault is reported.
– Shared RFMs/RRHs are blocked; the Operational state indicates Blocked:
dedicated to peer. The fault: TRX object allocation failed in
RF module (diagnostic info: 05) is reported.

34 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

5.6.1 Recovery procedure for TRX object allocation failed


Step to resolve the problem.

Procedure

1 Check the alarm supplementary information (the first byte) which notifies the user of the
reason for the alarm as there are many possible options for this alarm.

For example, in this case the first byte in supplementary info field is 01 which means
“RFM dumb” (not detected):
7606 TRX FAULTY
TRX object allocation failed in RF module
01 00 00 82 00 00

2 See the Trouble Management of Flexi Multiradio BTS GSM/EDGE document for


supplementary information based on recovery procedures. The Diagnostic info in GSM
BTS Site Manager indicates the possible root cause.

3 Install the WCDMA RF Sharing license if the minor fault: Licence missing...
(1885) is reported.

g Note: Site reset is not required.

Step result
GSM TRXs in the shared RFMs/RRHs go on air.

5.7 RF Module failure (0125) or (1900) alarm


Effects of and solution to RF Module failure (0125) or (1900) alarm.

Symptoms
Either RF Module failure (0125) alarm is active in WCDMA or 1900 RF
Module configuring failed fault is active in LTE in WCDMA-LTE RF Sharing
configuration.

Description
Usually the alarm is activated in that RAT which allocated its own carrier last in the
shared pipe. This is possible for example, when WCDMA WCEL’s are locked in RNC
and the LTE carriers are active. Now, if WCEL’s are unlocked from RNC, fault 0125 is
activated when WCDMA carriers experience configuration errors.

DN09206431 Issue: 03 © 2018 Nokia 35
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

5.7.1 Recovery procedure for RF Module failure alarm


Steps to resolve the problem.

Procedure

1 Check whether the cell configuration is supported, for example 3+3+3 WCDMA and
1+1+1 15MHz LTE is not supported.

2 Check whether the total BW required by LTE and WCDMA carriers fit in the used RFM,
considering its HW capabilities.

3 Check whether the total power budget is exceeded.

4 Check whether the LTE and WCDMA carrier frequencies overlap.

If the carriers overlap, there is no active alarm in practice.

5 Check whether the optical link has sufficient capacity (3 or 6 Gbps).

5.8 Increased BER detected on the optical connection


to Radio Module (1955) fault
Effects of and solution to 1955 Increased BER detected on the optical
connection to Radio Module fault.

Symptoms
1955 Increased BER detected on the optical connection to Radio
Module fault is active either in WCDMA or in LTE.

5.8.1 Recovery procedure for Increased BER detected on the


optical connection to Radio Module fault
Step to resolve the problem.

36 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

Procedure

1 Check whether the cell configuration is supported, for example 2+2+2 WCDMA and
1+1+1 15MHz LTE is not supported.

For supported configurations, see Classical RF Sharing Released Configurations. To


find this document, see Reference documents for RF Sharing section.

2 Check BER on WCDMA BTS Site Manager.

In WCDMA BTS Site Manager, use the Rx/Tx Statistics view to check the optical port
conditions.

5.9 Incorrect filter shift in RX diversity sharing


Effects of and solution to incorrect filter shift in RX diversity sharing.

Symptoms

• WCDMA/LTE: RF Module failure (1840) fault is reported.


• GSM: 7603 BTS FAULTY or/and 7606 TRX FAULTY - TRX object
allocation failed in RF module alarm is raised with diagnostic info: 06.

Description
The problem happens when the filter frequency has been manually shifted and the filter
exceeds the RFM BW or channel BW.

5.9.1 Recovery procedure for incorrect filter shift in RX diversity


sharing
Step to resolve the problem.

Procedure

1 Recommission the BTS, setting the correct filter shift value.

Step result
After recommissioning the alarms are cleared and cells/TRXs go on air.

5.10 Incorrect RP3 cabling


Effects of and solutions to incorrect RP3 cabling in RF sharing.

DN09206431 Issue: 03 © 2018 Nokia 37
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

Symptoms

• WCDMA: Cells in the shared RFM/RRH stay on air. Failure in optical RP3


interface (4039) fault is reported.
• GSM: 7603 BTS FAULTY or/and 7606 TRX FAULTY - ESMx System Module
has lost connection to RF Module or 7602 BCF NOTIFICATION -
Invalid or un-commissioned shared RF module HW
configuration detected alarms are raised.

Description
WCDMA is commissioned to RF Sharing but GSM is not commissioned yet. RFM/RRH
cables are connected incorrectly to the GSM System Module.
• WCDMA (correct connection): The first shared RFM/RRH is connected to OPT1, the
second shared RFM to OPT2.
• GSM (incorrect connection): The first shared RFM/RRH is connected to OPT2, the
second shared RFM to OPT1.

5.10.1 Recovery procedure for incorrect RP3 cabling


Steps to resolve the problem.

Procedure

1 Correct the cable connections - the first RFM to OPT1, the second RFM to OPT2, if
7603 BTS FAULTY or/and 7606 TRX FAULTY - ESMx System Module has
lost connection to RF Module alarm is raised.

Step result
The alarm is cleared, GSM is ready for commissioning.

2 Check the RP3 cable orders in Shared RFM.

Master RP3 cable should be connected to RFM OPT1 and Slave RP3 cable to RFM
OPT2.

3 Commission the GSM, if 7602 BCF NOTIFICATION - Invalid or un-


commissioned shared RF module HW configuration detected alarm is
raised.

Step result
The alarm is cleared, GSM TRXs go on air.

38 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

5.11 Remote connection to the Slave BTS is lost


Effects of and solution to loss of the Slave BTS remote connection in RF sharing.

Symptoms

• Master technology: No effect.
• Slave technology: Remote connection is not possible.

5.11.1 Recovery procedure for loss of the Slave BTS remote


connection
Step to resolve the problem.

Procedure

1 Reset the Master technology BTS. It resets also the Slave technology BTS.

Step result
Remote connection is restored.

2 If the DC supply for the Slave SM originates from one of the PWR ports in Master SM,
then that PWR port can be toggled by means of the Power On/Off buttons in Master SM.
In result, the Slave SM power is toggled, too.

5.12 Problems when Sync Hub Direct Forward is in use


List of topics related to problems when Sync Hub Direct Forward is in use.

5.12.1 BTS reference clock missing during normal operation


when Sync Hub Direct Forward is in use
Effects of and solution to the BTS reference clock missing fault in RF sharing
when Sync Hub Direct Forward is in use.

Symptoms

• WCDMA/LTE: BTS reference clock missing (3080) fault is reported.


• GSM: 7600 BCF FAULTY or/and 7602 BCF NOTIFICATION - BSS
Synchronization failed alarm is raised .

Description

DN09206431 Issue: 03 © 2018 Nokia 39
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

If the reporting element is the Radio Master/Sync Hub Master, then RF sharing setup
continues operation and stays on air.
If the reporting element is the Radio Slave/Sync Hub Slave or the Radio Slave/Sync Hub
Master, then the reporting element discontinues services allocated to the shared RF
module.
If the reporting element is the Radio Master/Sync Hub Slave, then the element
connected to the reporting element discontinues services allocated to the shared RF
module.

g Note: Do not define a secondary sync source for SyncHub Slaves. Otherwise SyncHub
Slave might not be able to maintain its local phase relationship to the SyncHub Master
anymore, when the SyncHub Master is losing its reference clock. The radio slave might
discontinue services allocated to the shared RF module in this case.

5.12.1.1 Recovery procedure for BTS reference clock missing

Steps to resolve the problem.

• If the reporting element is the Sync Hub Slave:

Select from the available options

– Check that the Sync Cable is properly connected and not damaged.
– Check the status of the element being Sync Hub Master and fix this element if it
is unavailable for example commission the Sync Hub Master if not yet
commissioned, this requires also the Slave to be commissioned again (undo
commissioning in case of GSM)

• If the reporting element is the Sync Hub Master:

Select from the available options

– Troubleshoot the configured synchronization reference source(s):
• Determine which synchronization reference source(s) is configured to be
used.
• Check whether the other reported faults are active providing further
information about a fault with the configured synchronization reference
source(s).
• Check the troubleshooting/fault handling instructions related to the feature
which provides the synchronization reference source(s) used at the Sync
Hub Master (for example, GPS synchronization, Timing over Packet, SyncE,
…).

Result
Alarms are cleared. All elements in the RF sharing setup go back on air.

40 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

5.12.2 PPS reference clock missing at startup when Sync Hub


Direct Forward is in use
Effects of and solution to Reference clock missing in startup fault in RF
sharing when Sync Hub Direct Forward is in use.

Symptoms

• WCDMA/LTE: 4153 Reference clock missing in startup fault is


reported.
• GSM: 7600 BCF FAULTY or/and 7602 BCF NOTIFICATION - BSS
Synchronization failed alarm is raised .

Description
The reporting element does not detect RF Modules and does not go on air.

g Note: Do not define a secondary sync source for Sync Hub Slave. Otherwise Sync Hub
Slave might not be able to maintain its local phase relationship to the Sync Hub Master
anymore, when the Sync Hub Master is losing its reference clock. The radio slave might
discontinue services allocated to the shared RF module in this case.

5.12.2.1 Recovery procedure for PPS reference clock missing at startup

Steps to resolve the problem.

• If the reporting element is the Sync Hub Slave:

Select from the available options

– Check that the Sync Cable is properly connected and not damaged.
– Check the status of the element being Sync Hub Master and fix this element if it
is unavailable (for example, commission the Sync Hub Master if not yet
commissioned).

• If the reporting element is the Sync Hub Master:

Select from the available options

– Troubleshoot the Synchronization reference source configured to be used.

• WCDMA/LTE: In case of misconfiguration, it is only possible to change settings by either
commissioning the BTS remotely via NetAct, or by uncommissioning the reporting
element by pressing the reset button for five seconds.

Result
Alarms are cleared. All elements in the RF sharing setup go back on air.

DN09206431 Issue: 03 © 2018 Nokia 41
   

Typical RF Sharing troubleshooting cases Troubleshooting RF Sharing

5.12.3 Undetected RFMs when Sync Hub Direct Forward is in use


Effects of and solution to problems with RF Modules detection and commissioning of
new BTS (as SyncHub Master/Radio Slave) when Sync Hub Direct Forward is active.

Symptoms
When new, un-commissioned BTS is connected to the site with Sync Hub Direct
Forward, shared RFMs are undetected by BTS Site Manager. The commissioning can
subsequently not commence.

Description
Site with a single BTS is extended for RF sharing with Sync Hub Direct Forward. The
new BTS operates as a SyncHub Master/Radio Slave. After connecting the new BTS the
shared RFMs are undetected and commissioning cannot proceed.
Pre-conditions:
BTS working as SyncHub Master/Radio Slave is un-commissioned.
BTS working as SyncHub Slave/Radio Master is commissioned and operational.

5.12.3.1 Recovery procedure for detection problems with RFMs when Sync
Hub Direct Forward is in use

Steps to resolve the problem.

Before you start


• Check that BTS is synchronized. In Sync Hub scenario radios are not detected if
BTS does not receive synchronization.
• Check the PPS reference clock missing at startup when Sync Hub Direct Forward is
in use section.

To resolve the problem, either commission the BTS remotely via NetAct with an SCF file
(if available), or perform the following procedure:

Procedure

1 Power down the BTS acting as the SyncHub Slave/Radio Master.

2 Reset the un-commissioned BTS acting as the SyncHub Master/Radio Slave.

3 Commission the BTS acting as the SyncHub Master/Radio Slave via the BTS Site
Manager.

42 © 2018 Nokia DN09206431 Issue: 03
   

Troubleshooting RF Sharing Typical RF Sharing troubleshooting cases

4 If the BTS acting as the SyncHub Master/Radio Slave is commissioned, power up the
BTS acting as the SyncHub Slave/Radio Master.

DN09206431 Issue: 03 © 2018 Nokia 43