AP R12 Troubleshooting Guide

Doc. Code Product Name AP

Intended Audience

For internal use Product Version R12

Prepared by AP PDU Doc. Version V1.1

AP R12 Troubleshooting Guide

Prepared by AP R12 PDU Date 2011-06-17

Reviewed by Date

Reviewed by Date

Approved by Date

Huawei Technologies Co., Ltd.

All rights reserved.

AP R12 Troubleshooting Guide Internal Use

Change History

Data Revision

Version

Description Author

2011-01-11 V1.0 Completed the initial draft. R12 PDU

2011-04-30 V1.1 Add the troubleshooting guide about UAP2835&UAP2855

R12 PDU

2011-6-17 Huawei Confidential Page 2 of 132


Contents

Change History..................................................................................................................................2

1 Service Setup Faults.......................................................................................................................41.1 Failure to Initiate a Voice Call.................................................................................................................................4

1.2 Cell Management Faults........................................................................................................................................14

2 Handover Faults...........................................................................................................................212.1 Handover from a 3G Macro Cell to the HAP........................................................................................................21

2.2 Handover from a 3G Macro Cell to the ePico.......................................................................................................26

2.3 Handover from the AP to a 3G Macro Cell...........................................................................................................34

2.4 Inter-AP Hard Handover........................................................................................................................................43

2.5 Failure to Perform Blind Handover to a Macro Cell.............................................................................................48

2.6 A UE Fails to Reselect the AP from the Macro Network......................................................................................56

2.7 A UE Fails to Reselect the 2G Macro Network from the AP................................................................................60

2.8 A UE Fails to Reselect the 3G Macro Network from the AP................................................................................64

2.9 A UE Fails to Perform Reselection Between APs.................................................................................................70

2.10 Failure to Redirect an Emergency Call to a Macro Cell......................................................................................75

3 Voice Quality Problems................................................................................................................783.1 Abnormal Uplink AMR Voice...............................................................................................................................78

4 Upgrade Problems........................................................................................................................854.1 Failure to Synchronize Parameters Between the APM and the AP.......................................................................85

4.2 The AP Fails to Be Upgraded Through the APM..................................................................................................88

5 Data Transmission Problems.......................................................................................................935.1 Unstable Data Transmission in the HSDPA Service..............................................................................................93

5.2 Low Data Transmission Rate in the HSDPA Service............................................................................................97

5.3 Failure to Set Up the HSUPA Service.................................................................................................................103

5.4 Unstable Data Transmission in the HSUPA Service............................................................................................107

5.5 Low Data Transmission Rate in the HSUPA Service..........................................................................................110

6 Problems Related to Automatic Power Adjustment................................................................1136.1 Call-Based Automatic Pilot Adjustment of the AP..............................................................................................113

6.2 Statistics-Based Automatic Pilot Adjustment of the AP......................................................................................118

7 Transmission Faults....................................................................................................................122



7.1 Typical Methods of Locating Transmission and Power-on Faults in R12...........................................................122

8 HGW Faults................................................................................................................................1278.1 QoS Issues...........................................................................................................................................................128

8.2 Issues Related to Wi-Fi Distributed System........................................................................................................129

8.3 Diagnosing Network Congestion Through the Port Mirror Function.................................................................130

8.4 Diagnosing Network Congestion Through Characteristic Packet Capturing......................................................131

8.5 Checking the System Breakdown Issue Through Logs.......................................................................................132

1 Service Setup Faults

1.1 Failure to Initiate a Voice Call

1.1.1 Problem DescriptionA UE under the AP fails to initiate an AMR call.

1.1.2 Cause Analysis

Cause 1

Cause Description

The AP cell fails to be set up.

Cause-Identifying Method

Observe whether the RUN indicator on the AP is green at the near end. On the APM, check whether the AP status is Online, as shown in the following figure.



Cause 2

Cause Description

The User Access Policy used by the AP is Closed or Group, and the AP does not add the IMSI of the UE to the accessible UE list.


Log in to the AHR, and check the user access policy and accessible UE list of the AP, as shown in the following figure.





Cause 3

Cause Description

The radio parameters set on the AP are different from those set on the core network (CN). To implement radio communication, you need to set the PLMN, LAC, and SAC. The specific parameter values are provided by carriers.


Log in to the APM, and then check whether the PLMN and LAC under Zone Configuration are correctly set, as shown in the following figure.



On the APM, check whether the SAC under Single Configuration is correctly set, as shown in the following figure.



On the APM, check whether DefaultSai under Zone Configuration is correctly set, as shown in the following figure.

Cause 4

Cause Description

CSDomain is not configured for the AP under CnNodeInfo.


Log in to the APM, and check whether the parameters under Single Configuration are set correctly, as shown in the following figure.



Cause 5

Cause Description

The number of users under the AP exceeds the specification.


Check whether the number of users under the AP exceeds the current specification.

On the LMT, log in to the AP and select Cell performance monitoring to check whether the number of users served by a dedicated channel inside a cell exceeds the specification of the AP, as shown in the following figure.



Cause 6

Cause Description

The IUUP version of the AP is different from that of the CN.


Trace Iu signaling, and then check the IUUP version assigned by the CN in the RAB_ASSIGNMENT_REQ signaling, as shown in the following figure.



Whether the AP supports IUUP Version2 depends on the setting of IuupV2SupportSwitch. If IuupV2SupportSwitch is set to off, the AP supports IUUP Version1. If IuupV2SupportSwitch is set to on, the AP supports IUUP Version2. IuupV2SupportSwitch is set to off by default, that is, the AP supports IUUP Version1 by default. If uP-ModeVersions is set to 2, IUUP Version2 is assigned by the CN. In this case, modify the IUUP version of the AP.



Cause 7

Cause Description

The UE compatibility does not meet the requirement.


Return the traced messages of the UE and the UE model.

1.1.3 Information Collection ListIf the fault persists, collect necessary information according to the following table.

Item Optional or Mandatory

Test procedures and detailed problem descriptions Mandatory

CDT of the AP (turn on the L2 statistics switch), and Uu and Iu messages

Mandatory

AP configuration parameters, collected through the APM Mandatory

UE model Mandatory

UAG configuration file Mandatory

Before information collection, you are advised to exclude UE and CN faults by conducting a comparison test on a macro network.



1.2 Cell Management Faults

1.2.1 Cell ManagementThis section mainly describes the differences of the AP software in automatic network planning between R12 and R11/R10.

In R12, automatic network planning separates the procedure for searching frequencies and scrambling codes of AP cells from the procedure for searching neighboring cells. The two procedures can be controlled separately. The frequencies and scrambling codes of the AP cells and the neighboring cells support auto-configuration. For details, see the Automatic Network Planning and Optimization (HAP1130).doc and Automatic Network Planning and Optimization (ePico1130).doc.

The following describes the commands related to cell setup and neighboring cell management.

Auto-configuration

Neighboring cell auto-configuration switch (The neighboring cell combination switch also requires your attention for the ePico.)

When the neighboring cell auto-configuration switch is set to TRUE and the combination switch of neighboring 3G cells is set to ON, use the neighboring 3G cells configured manually and automatically; otherwise, use the manually configured neighboring cells only.

Focus on the commands shown in the following figure.

Neighboring cell combination switch unique to the ePico version:



Auto-configuration of neighboring 3G and 2G cells

Query the auto-configuration result of neighboring cells:

Set the neighboring cell auto-configuration function:

Auto-configuration of the frequencies and scrambling codes of AP cells



Cell Status Management

For the detailed configuration methods of the frequencies and scrambling codes of AP cells and the neighboring cells, and the detailed parameter descriptions, see "Adjusting the uBro Network" in the ePico3801B User Guide (V200R012_01).

1.2.2 Cause Values Attachment 1: Cause values of deleting cells

Generally, the cause values of deleting cells are printed on the serial port. The following is for your reference:



NBM_CCH_FAULT_CAUSE_NO_FAIL = 0,

NBM_CCH_FAULT_CAUSE_CFG_DEL_CCH = 1,

NBM_CCH_FAULT_CAUSE_CFG_BLOCK_CELL = 2,

NBM_CCH_FAULT_CAUSE_RSI_CAUSE_DEL = 3,

NBM_CCH_FAULT_CAUSE_AUDIT_CAUSE_DEL = 4,

NBM_CCH_FAULT_CAUSE_CCH_SETUP_FAIL = 5,

NBM_CCH_FAULT_CAUSE_DSP_FAULT = 6,

NBM_CCH_FAULT_CAUSE_RNCAP_L2RM_CELL_NOT_UNIFORM = 7,

NBM_CCH_FAULT_CAUSE_L2MAC_ERR = 8,

NBM_CCH_FAULT_CAUSE_L2RLC_ERR = 9,

NBM_CCH_FAULT_CAUSE_CELL_NONEUE_TIMEOUT = 10,

NBM_CCH_FAULT_CAUSE_NB_NO_ANSWER_FOR_CCH_DEL = 11,

NBM_CCH_FAULT_CAUSE_STLT_LICENSE_CTRL = 12,

NBM_CCH_FAULT_CAUSE_SYSINFO_UPDATE_FAIL = 13,

NBM_CCH_FAULT_CAUSE_OLC_CTRL = 14,

NBM_CCH_FAULT_CAUSE_CFG_MBMS_SESSION_REL_WAIT_TIMEOUT = 15,

NBM_CCH_FAULT_CAUSE_CFG_MBMS_STATE_NOTALLOWED = 16,

NBM_CCH_FAULT_CAUSE_MBMS_TRAIFF_NOTPRESENT = 17,

NBM_CCH_FAULT_CAUSE_UU_SYNC = 18,

NBM_CCH_FAULT_CAUSE_EIU_ERROR = 19,

NBM_CCH_FAULT_CAUSE_PERIOD_CELL_RESETUP = 20,

NBM_CCH_FAULT_CAUSE_AP_FREQ_LIST_UPT = 21,

NBM_CCH_FAULT_CAUSE_AP_CODE_LIST_UPT = 22,

NBM_CCH_FAULT_CAUSE_LC_FAULT = 23,

NBM_CCH_FAULT_CAUSE_UNKNOWN_ERR = 24,

NBM_CCH_FAULT_CAUSE_CELL_SETUP_ERROR = 25,

NBM_CCH_FAULT_CAUSE_ACCESS_REQ_TIME_OUT = 26,

NBM_CCH_FAULT_CAUSE_ACCESS_REQ_RETURN_FAULT = 27,

NBM_CCH_FAULT_CAUSE_3G_RF_SWITCH_OFF = 28

Attachment 2: Cause value of failure to request cell resources (the last three digits of the error code-0x7D0)

ePico:

NBM_CRA_CELL_ERR_CODE_BEGIN = NBM_CRA_ERR_BASE,//0xA0D07D0

NBM_CRA_CELL_RR_SUCC,



NBM_CRA_CELL_RR_UL_CAC_REJECT_FAIL,

NBM_CRA_CELL_RR_DL_CAC_REJECT_FAIL,

NBM_CRA_CELL_RR_HSDPA_USER_NUM_FAIL,

NBM_CRA_CELL_RR_HSUPA_USER_NUM_FAIL,

NBM_CRA_CELL_RR_HSPA_USER_NUM_FAIL,

NBM_CRA_CELL_RR_UL_CAC_FAIL,

NBM_CRA_CELL_RR_DL_CAC_FAIL,

NBM_CRA_CELL_RR_ULDL_CAC_FAIL,

NBM_CRA_CELL_RR_LCG_UL_FAIL,

NBM_CRA_CELL_RR_LCG_DL_FAIL,

NBM_CRA_CELL_RR_LCG_DUAL_FAIL,

NBM_CRA_CELL_RR_NODEB_UL_FAIL,

NBM_CRA_CELL_RR_NODEB_DL_FAIL, /

NBM_CRA_CELL_RR_NODEB_DUAL_FAIL,

NBM_CRA_CELL_RR_IUB_UL_REJECT_FAIL, /

NBM_CRA_CELL_RR_IUB_DL_REJECT_FAIL,

NBM_CRA_CELL_RR_IUB_DUAL_REJECT_FAIL,

NBM_CRA_CELL_RR_IUB_UL_FAIL,

NBM_CRA_CELL_RR_IUB_DL_FAIL,

NBM_CRA_CELL_RR_IUB_DUAL_FAIL,

NBM_CRA_CELL_RR_FAIL,

NBM_CRA_CELL_RR_CRM_FAIL,

NBM_CRA_CELL_RR_LC_UL_FAIL,

NBM_CRA_CELL_RR_LC_DL_FAIL, /

NBM_CRA_CELL_RR_LC_DUAL_FAIL,

NBM_CRA_CM_CFG_FAIL,

NBM_CRA_CELL_UNAVAIL,

NBM_CRA_CELL_RR_TOTAL_USER_NUM_FAIL,

NBM_CRA_CELL_RR_PS_USER_NUM_FAIL,

NBM_CRA_CELL_RR_PS_SERVICE_NUM_FAIL,

NBM_CRA_CELL_RR_SHO_USER_NUM_FAIL,

NBM_CRA_CELL_RR_VP_RAB_NUM_FAIL,

NBM_CRA_CELL_RR_BANDWIDTH_UP_FAIL,

NBM_CRA_CELL_RR_BANDWIDTH_DOWN_FAIL,

NBM_CRA_CELL_RR_BANDWIDTH_DUAL_FAIL,

NBM_CRA_CELL_RR_POWER_CONTROL_ACCESS_FAIL,

NBM_CRA_CELL_WILL_BE_DEL = (NBM_CRA_ERR_BASE + 100),

NBM_CRA_CELL_WILL_BE_BLOCK,

NBM_CRA_CELL_DISABLE,

NBM_CRA_CCH_WILL_BE_DEL,

NBM_CRA_CCH_DISABLE,

NBM_CRA_CELL_USER_ABNORMAL,

NBM_CRA_CELL_MBMS_SESSION_STOP,

NBM_CRA_CELL_ERR_CODE_END

HAP:

NBM_CRA_CELL_ERR_CODE_BEGIN = NBM_CRA_ERR_BASE,//err seg start CRA CELL RR

NBM_CRA_CELL_RR_SUCC=1,

NBM_CRA_CELL_RR_UL_CAC_REJECT_FAIL=2,

NBM_CRA_CELL_RR_DL_CAC_REJECT_FAIL=3,

NBM_CRA_CELL_RR_HSDPA_USER_NUM_FAIL=4,

NBM_CRA_CELL_RR_HSUPA_USER_NUM_FAIL=5,

NBM_CRA_CELL_RR_HSPA_USER_NUM_FAIL=6,

NBM_CRA_CELL_RR_UL_CAC_FAIL=7,

NBM_CRA_CELL_RR_DL_CAC_FAIL=8,



NBM_CRA_CELL_RR_ULDL_CAC_FAIL=9,

NBM_CRA_CELL_RR_LCG_UL_FAIL=10,

NBM_CRA_CELL_RR_LCG_DL_FAIL=11,

NBM_CRA_CELL_RR_LCG_DUAL_FAIL=12,

NBM_CRA_CELL_RR_NODEB_UL_FAIL=13,

NBM_CRA_CELL_RR_NODEB_DL_FAIL=14,

NBM_CRA_CELL_RR_NODEB_DUAL_FAIL=15,

NBM_CRA_CELL_RR_IUB_UL_REJECT_FAIL=16,

NBM_CRA_CELL_RR_IUB_DL_REJECT_FAIL=17,

NBM_CRA_CELL_RR_IUB_DUAL_REJECT_FAIL=18,

NBM_CRA_CELL_RR_IUB_UL_FAIL=19,

NBM_CRA_CELL_RR_IUB_DL_FAIL=20,

NBM_CRA_CELL_RR_IUB_DUAL_FAIL=21,

NBM_CRA_CELL_RR_FAIL=22,

NBM_CRA_CELL_RR_CRM_FAIL=23,

NBM_CRA_CELL_RR_LC_UL_FAIL=24,

NBM_CRA_CELL_RR_LC_DL_FAIL=25,

NBM_CRA_CELL_RR_LC_DUAL_FAIL=26,

NBM_CRA_CM_CFG_FAIL=27,

NBM_CRA_CELL_UNAVAIL=28,

NBM_CRA_CELL_RR_TOTAL_USER_NUM_FAIL=29,

NBM_CRA_CELL_RR_PS_USER_NUM_FAIL=30,

NBM_CRA_CELL_RR_PS_SERVICE_NUM_FAIL=31,

NBM_CRA_CELL_RR_VP_RAB_NUM_FAIL=32,

NBM_CRA_CELL_RR_BANDWIDTH_UP_FAIL=33,

NBM_CRA_CELL_RR_BANDWIDTH_DOWN_FAIL=34, /

NBM_CRA_CELL_RR_BANDWIDTH_DUAL_FAIL=35,

NBM_CRA_CELL_WILL_BE_DEL = (NBM_CRA_ERR_BASE + 100),

NBM_CRA_CELL_WILL_BE_BLOCK,

NBM_CRA_CELL_DISABLE,

NBM_CRA_CCH_WILL_BE_DEL,

NBM_CRA_CCH_DISABLE,

NBM_CRA_CELL_USER_ABNORMAL,

NBM_CRA_CELL_MBMS_SESSION_STOP,

NBM_CRA_CELL_ERR_CODE_END,//err seg end CRA CELL RR

Attachment 3: Query the cause value of cell setup failure.

On the APM, check the settings under Device.Services.FAPService.{i}.CellConfig.UMTS.RAN.FDDFAP.X_0D1F7B_QueryCellStatus.CellStatus for the status of the current cell. CellSetupFailCause indicates the specific cause for the failure to set up the current cell.



Common serial port commands are described as follows (note that these commands are special for AP development personnel and internal test personnel):

NBM_ShowApInfo: used to display the AP status and neighboring cell information.

NBM_ShowRem: used to display the auto-configuration information about the neighboring 3G and 2G cells of an AP cell.

NBM_ShowCellInfo: used to display the relevant information about an AP cell, including the frequency, scrambling code, power, status, and diagnosis information.

NBM_ShowLcInfo: used to display the status of the local cell and resource consumption criteria.

NBM_ShowUeInfo: used to display the channel information about the UE accessed to an AP cell.

NBM_CemReadPlmnFromFlash: used to read the PLMNID from the flash memory in the use of the network locking function.



2 Handover Faults

2.1 Handover from a 3G Macro Cell to the HAP

2.1.1 Problem Description The AP returns Relocation Failure during the relocation from a 3G macro network to the

AP.

The AP actively initiates Iu interface release during the relocation from the 3G macro network to the AP.

Others

2.1.2 Cause Analysis and Solution

I. The AP Returns Relocation Failure

Cause 1 Cause Description

The relocation from the 3G macro network to the AP fails, and the cause value is OM_INTERVENTION or RELOC_NOT_SUPP_IN_TARGET_RNC_OR_TARGET_SYS, indicating that the license for incoming relocation is unavailable or the function of prohibiting the incoming relocation is enabled.


Check the settings under Device.Services.FAPService.{i}.Capabilities.X_0D1F7B_LicenseInfo.LicenseOption for the license information about the current AP. If the license for the relocation from 3G macro cells is disabled, the relocation from 3G macro cells is not supported. Check the RRCTRLSWITCH command for whether the function of prohibiting the relocation from the 3G macro network is disabled. If the function is enabled, the relocation from 3G macro cells is not supported.

Solution

If the license for incoming relocation is unavailable, query whether the license is purchased on the AHR.

If the function of prohibiting the relocation from the 3G macro network is enabled, disable the function.

Typical Case

None




The relocation from the 3G macro network to the AP fails, and the cause value is OM_INTERVENTION, indicating that the RELOC REQ message does not carry the IMSI.


Check the RELOCATION REQ message. The following figure shows a RELOCATION REQ message that carries the IMSI.

Solution

For the incoming relocation, the RELOCATION REQ message must carry the IMSI; otherwise, the incoming relocation may fail. The source RNC needs to carry the IMSI in the RELOCATION REQ message.

Typical Case

None


The relocation from the 3G macro network to the AP fails, and the cause value is OM_IU_MSG_NOT_CMPAT_WITH_RECV_STATE, indicating that the repeated IUH resources exist during the incoming relocation.


Check the RELOCATION FAILURE message. The cause value is shown in the following figure.



Solution

This cause value indicates that the IUH resources of the UE are not released inside the AP, for example, hand-in occurs upon hand-out. In this case, the hand-in can be performed only after the UE DE REG message is sent.

Typical Case

None


The relocation from the 3G macro network to the AP fails, and the cause value is TRAFFIC_LOAD_IN_THE_TARGET_CELL_HIGHER_THAN_IN_THE_SRC_CELL, indicating that the CPU of the target AP is overloaded.


The cause value is TRAFFIC_LOAD_IN_THE_TARGET_CELL_HIGHER_THAN_IN_THE_SRC_CELL.

Solution

Recover the CPU of the AP to the normal state.

Typical Case

None


The relocation from the 3G macro network to the AP fails, and the cause value is unspecified-failure.


The cause value is unspecified-failure.

The cause cannot be located visually according to the cause value. Instead, the printed information about the CDT and serial port redirection is required.

Solution

View the Relocation REQ message on the Iu interface and check whether the information elements (IEs) in the message are correctly parsed. If the IEs fail to be parsed or the IEs of R7 and later versions are parsed, as shown in the following figure, the AP version set for the source cell is R7 or later. The AP cannot parse the IEs of versions later than R6. Therefore, change the AP version to R6 or an earlier version for the source cell.



Enable VOS_SetTraceLevel 71,0 and VOS_SetTraceLevel 73,0, and then perform incoming relocation again.

Typical Case

None

II. The AP Actively Initiates Iu Interface Release During the Relocation


After reporting the Relocation Command message, the AP initiates an IU Release Request message.


The Relocation Request ACK message is traced on the Iu interface. After a period of time, the AP actively initiates an IU Release Request message with the cause being Failure in the Radio Interface Procedure.

Solution

The Relocation Request ACK message contains an RB RECFG message that is constructed by the AP and needs to be sent by the source cell to the UE. After receiving the RB RECFG message, the UE performs air interface synchronization in the AP cell and reports an RB RECFG CMP message. After sending the Relocation Request ACK message, the AP starts a 5s timer. When failing to receive the RB RECFG CMP message from the UE within 5s, the AP initiates Iu interface release with the cause being Failure in the Radio Interface Procedure. In this case, enable Probe tracing to check whether the UE receives the RB RECFG message from the source cell and reports the RB RECFG CMP message.

Typical Case

None



III. Others

Cause Cause Description

The RELOCATION REQ ACK message returned by the AP contains a failed item with the cause being invalid RAB ID, as shown in the following figure.


Trace the messages on the Iu interface. It is found that the failure cause in the received RANAP_RELOCATION_REQ message and sent RELOCATION REQ ACK message is invalid RAB ID. In the RELOCATION REQ message, search the RAB information in RRC-Container, as shown in the following figure.

In the RELOCATION REQ message, search the RAB information in RAB-SetupList-RelocReq, as shown in the following figure.



If the RAB (RAB ID) in RAB-SetupList-RelocReq is not in the RAB list in RRC-Container, "0x1e (30):invalid-RAB-ID" is returned.

Solution

It is presumed that the relocation occurs before the UE receives the assignment message from the CN during service setup, thereby causing RAB information inconsistency between the RNC and CN. At present, no solution is provided.

Typical Case

None

2.1.3 Information CollectionIf the fault persists, collect necessary information according to the following table.



Iu and Uu messages of the AP Mandatory

CDT of the AP (turn on the L2 statistics switch) Mandatory

Serial port redirection information about the AP Optional

Probe tracing information about the UE Optional

2.2 Handover from a 3G Macro Cell to the ePico

2.2.1 Problem Description The AP returns Relocation Failure during the relocation from a 3G macro network to the

AP.



The AP actively initiates Iu interface release during the relocation from the 3G macro network to the AP.

Others


I. The AP Returns Relocation Failure

Cause 1

Cause Description



Run DSP_LICENSE to query the board type and corresponding license of the current AP.

If the board type of the AP is HAP, the incoming relocation is not supported.

If the license for the relocation from 3G macro cells is unavailable, the relocation from 3G macro cells is not supported.

Check the RRCTRLSWITCH command for whether the function of prohibiting the relocation from the 3G macro network is disabled. If the function is enabled, the relocation from 3G macro cells is not supported.

Solution

If the board type is HAP, replace the HAP with an EAP or ePico.

If the license for incoming relocation is unavailable, query whether the license is purchased on the AHR.

If the function of prohibiting the relocation from the 3G macro network is enabled, disable the function.

Typical Case

None

Cause 2

Cause Description



The user access policy used by the current AP is Closed or Group.




Solution

For the AP that uses the Closed or Group mode, the RELOCATION REQ message must carry the IMSI; otherwise, the incoming relocation may fail. The source RNC needs to carry the IMSI in the RELOCATION REQ message.

Typical Case

None

Cause 3

Cause Description

The relocation from the 3G macro network to the AP fails, and the cause value is OM_INTERVENTION, indicating that the UE to be relocated is not in the accessible UE list.


The user access policy that the current AP uses is Closed. View the RELOCATION REQ message. The IMSI must be in the accessible UE list of the AP, as shown in the following figure.



Solution

If the UE can be relocated to the AP, add the IMSI of the UE to the accessible UE list of the AP on the AHR.

Typical Case

None

Cause 4

Cause Description



View the RELOCATION REQ message. As shown in the following figure, the IMSI must be in the accessible UE list of the AP. If the user access policy of the current AP is Closed, add the IMSI to the accessible UE list of the AP. If the user access policy of the current AP is Group, add the IMSI to the accessible UE list of the AP, group, or other APs in the same group.



Solution

If the UE can be relocated to the AP, add the IMSI of the UE to the accessible UE list of the group to which the AP belongs on the AHR.

Typical Case

None

Cause 5

Cause Description




Solution


Typical Case

None

Cause 6

Cause Description





The cause value is unspecified-failure.


Solution

View the Relocation REQ message on the Iu interface and check whether the IEs in the message are correctly parsed. If the IEs fail to be parsed or the IEs of R7 and later versions are parsed, as shown in the following figure, the AP version set for the source cell is R7 or later. The AP cannot parse the IEs of versions later than R6. Therefore, change the AP version to R6 or an earlier version for the source cell.


Typical Case

None

II. The AP Actively Initiates Iu Interface Release During the Relocation

Cause

Cause Description




Solution

The Relocation Request ACK message contains an RB RECFG message that is constructed by the AP and needs to be sent by the source cell to the UE. After receiving the RB RECFG message, the UE performs air interface synchronization in the AP cell and reports an RB



RECFG CMP message. After sending the Relocation Request ACK message, the AP starts a 5s timer. When failing to receive the RB RECFG CMP message from the UE within 5s, the AP initiates Iu interface release with the cause being Failure in the Radio Interface Procedure. In this case, enable Probe tracing to check whether the UE receives the RB RECFG message from the source cell and reports the RB RECFG CMP message.

Typical Case

None

III. Others

Cause

Cause Description

The RELOCATION REQ ACK message returned by the AP contains a failed item with the cause being invalid RAB ID, as shown in the following figure.


Trace the messages on the Iu interface. It is found that the failure cause in the received RANAP_RELOCATION_REQ message and sent RELOCATION REQ ACK message is invalid RAB ID. In the RELOCATION REQ message, search the RAB information in RRC-Container, as shown in the following figure.



In the RELOCATION REQ message, search the RAB information in RAB-SetupList-RelocReq, as shown in the following figure.

If the RAB (RAB ID) in RAB-SetupList-RelocReq is not in the RAB list in RRC-Container, "0x1e (30):invalid-RAB-ID" is returned.

Solution

It is presumed that the relocation occurs before the UE receives the assignment message from the CN during service setup, thereby causing RAB information inconsistency between the RNC and CN. At present, no solution is provided.

Typical Case

None










2.3 Handover from the AP to a 3G Macro Cell

2.3.1 Problem Description The UE does not initiate the relocation from the AP to a 3G macro network (because the

RANAP_RELOCATION_REQUIRED message is not traced on the Iu interface).

When the UE relocates from the AP to the 3G macro network, the RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP.

When the UE relocates from the AP to the 3G macro network, call drops occur (because the RANAP_RELOCATION_COMMAND message is traced on the Iu interface and the RRC_RB_RECFG_CFG message is traced on the Uu interface).

Others

2.3.2 Cause Analysis and SolutionI. The Relocation Is Not Triggered Properly

Cause 1

Cause Description

No neighboring cell is configured or searched.


For the manually configured neighboring cells, check MO InterFreqCell or IntraFreqCell for the neighbor cell list. If the neighbor cell list is empty, the current neighboring macro cell is not configured correctly.

For the automatically searched neighboring cells, query the neighbor cell list under NeighborListInUse. If the required neighboring cell is not in the neighbor cell list, check whether the frequencies of neighboring macro cells are correctly configured under WCDMAFDD in the parameter area. If no information is available under WCDMAFDD, the frequencies of neighboring macro cells are not configured, and thereby searching neighboring macro cells fails.

Solution

For the manually configured neighboring cells, manually add neighboring 3G macro cells by adding instance configuration to InterFreqCell or IntraFreqCell.

For the automatically obtained neighboring cells, if the neighboring cell frequencies are not configured, add the frequencies of neighboring macro cells, deactivate the cell, and then activate the cell to trigger neighboring cell search. If the neighboring cell frequencies are correctly configured, check whether the current environment is covered by a macro network (for example, certain scenarios such as the basement are not covered by the macro network). If yes, deactivate and then activate the cell to re-trigger neighboring cell search.

Typical Case

None



Cause 2

Cause Description

The relocation-out switch is turned off.


Check whether CSTO3GSwitch or PSTO3GSwitch under RelocationToMacro MO is set to true. If it is set to false, the relocation to the corresponding domain is not initiated.

Check whether InterFreqRatCoexistChoice is set to INTERRAT in X_0D1F7B_InterFreqRatParaChoice MO. To support inter-frequency relocation, set this parameter to INTERFREQ or SIMINTERFREQRAT.

Solution

Set CSTO3GSwitch and (or) PSTO3GSwitch to true in RelocationToMacro, and InterFreqRatCoexistChoice to INTERFREQ or SIMINTERFREQRAT in X_0D1F7B_InterFreqRatParaChoice.

Typical Case

None

Cause 3

Cause Description

The signals of the AP cell are too strong.


Trace the messages on the Uu interface. It is found that the AP delivers a measurement control message after RB setup and receives the measurement report from the UE. If the AP and macro network use inter-frequency networking and the RRC_PH_CH_RECFG message is not traced on the Uu interface, the signal quality in the AP cell is good and no inter-frequency neighboring cell measurement is triggered. If the AP and macro network use intra-frequency networking and the UE does not report the 1d measurement report, the signal quality in the AP cell is good and the change to the best cell is not triggered, thereby failing to trigger intra-frequency relocation.

Solution

To retain the transmit power of the AP and the handover threshold, make the UE far away from the AP to trigger the relocation. If the AP and macro network use inter-frequency networking, increasing the values of Threshold2DCsRscp, Threshold2FCsRscp, Threshold2DPsRscp, and Threshold2FPsRscp in X_0D1F7B_PrivateInterFreqPara may make it easier to trigger inter-frequency received signal code power (RSCP) measurement. In this way, inter-frequency relocation may be easily triggered. If the AP and macro network use intra-frequency networking, decreasing the values of X_0D1F7B_HysteresisEvent1d and X_0D1F7B_TimeToTriggerEvent1d in IntraFreqMeas may make it easier to trigger intra-frequency relocation.

Typical Case

None



Cause 4

Cause Description

The signals of the neighboring macro cell are too poor.


Trace the messages on the Uu interface. It is found that the AP delivers a measurement control message after RB setup and receives the measurement report from the UE. If the AP and macro network use inter-frequency networking, trace the RRC_PH_CH_RECFG and RRC_PH_CH_RECFG_CMP messages on the Uu interface. If the AP and macro network use intra-frequency networking, the signals of the current cell have deteriorated according to the measurement report from the UE but the 1d report is not reported.

Solution

In the case of manual network planning, check whether the configured neighboring cell exists. Check whether the UE detects the neighboring cell according to the measurement report from the probe or UE. If the neighboring cell exists, check whether the signal quality of the current neighboring macro cell meets the relocation-out requirement. Attempt to make the UE far away from the AP for triggering relocation. This, however, may easily cause call drops.

Typical Case

None

II. The RANAP_RELOCATION_PREPARATION_FAILURE Message Is Received

Cause 1

Cause Description

The cause for relocation preparation failure is TRELOCalloc expiry.


The RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP, with the cause value being TRELOCalloc expiry.

The cause is that the CN times out in waiting for the Relocation Request ACK message from the target cell.

Solution

Determine whether the target cell (RNC) supports hard handover with incoming relocation and whether the function is controlled by a switch. This type of problem needs to be solved on the macro network side. On the AP side, no better solution is available.

Typical Case

None

Cause 2

Cause Description

The cause for relocation preparation failure is Relocation Failure in Target CN/RNC or Target



System.


The RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP, with the cause value being Relocation Failure in Target CN/RNC or Target System. The possible cause is that the CN or target cell does not support the relocation (to the domain).

Solution

Determine whether the CN and target cell (RNC) support hard handover with relocation and whether the function is controlled by a switch. This type of problem needs to be solved on the macro network and CN sides. On the AP side, no better solution is available.

Typical Case

None

Cause 3

Cause Description

The cause for relocation preparation failure is Relocation not supported in Target RNC or Target System.


The RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP, with the cause value being Relocation not supported in Target RNC or Target System. The possible cause is that the target cell does not support incoming relocation (for example, inter-RNC hard handover with relocation).

Solution

Determine whether the CN and target cell (RNC) support hard handover with relocation and whether the function is controlled by a switch. This type of problem needs to be solved on the macro network and CN sides. On the AP side, no better solution is available.

Typical Case

The hard handover with relocation from a Femto cell in Wuhan to Ericsson’s macro network fails.

In the AMR service, the hard handover with relocation from the AP to Ericsson’s macro network fails. The cause value in the RANAP_RELOCATION_PREPARATION_FAILURE message is Relocation not supported in Target RNC or Target System. The test on Ericsson’s macro network in Beijing is successful. This indicates that the failure is not caused by the AP. Ericsson provides the license and switch of inter-RNC hard handover with relocation. Whether to enable the license and turn on the switch needs to be confirmed with the macro network. In addition, it is also required to confirm whether the CN can support inter-MSC hard handover with relocation.

Cause 4

Cause Description

The cause for relocation preparation failure is Interaction with other procedure.




The RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP, with the cause value being Interaction with other procedure. The common cause is that the relocation occurs again just after the previous incoming relocation fails (relocation preparation failure). In this case, the CN returns the RANAP_RELOCATION_PREPARATION_FAILURE message with the cause value being Interaction with other procedure.

Solution

The protocol does not stipulate the cause for which the CN sends the cause value. In actual tests, however, it is found that such a failure may occur if a second relocation request is initiated just after the previous relocation fails. Such a failure does not occur if the second relocation request is delayed. Therefore, it is presumed that the state transition of a UE is not performed after the CN sends an RANAP_RELOCATION_PREPARATION_FAILURE message. As a result, the CN makes an incorrect decision after receiving the second relocation request. In this case, do not initiate relocation frequently or perform location on the macro network and CN sides. On the AP side, no better solution is available.

Typical Case

None

Cause 5

Cause Description

The cause for relocation preparation failure is unspecified-failure.


The RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP, with the cause value being unspecified-failure. The possible cause is that the CN or target cell is abnormal, thereby causing relocation preparation failure.

Solution

This type of problem needs to be solved on the macro network and CN sides. On the AP side, no better solution is available.

Typical Case

The relocation preparation failure with the cause being unspecified-failure occurs in Poland.

In an office of Poland, the handover from the PS domain to the macro network fails. The CN returns relocation preparation failure with the cause value being unspecified-failure. After the location on the CN and RNC sides, it is found that the CNID in the CNNODE of the PS domain is different on the SGSN and RNC. Modify the CNID on the RNC. Then the relocation is successful. The commands to be used are RV CNNODE and ADD CNNODE.

Cause 6

Cause Description

The cause for relocation preparation failure is message not compatible with receiver state.




The RANAP_RELOCATION_PREPARATION_FAILURE message is received on the Iu interface of the AP, with the cause value being message not compatible with receiver state. The possible cause is that the CN or target cell is abnormal, thereby causing relocation preparation failure.

Solution


Typical Case

The relocation preparation failure with the cause being message not compatible with receiver state occurs in Hongkong. After the location on the SGSN side, it is found that the inter-SGSN relocation from SGSN1 (the SGSN where the RNC of the macro network resides) to SGSN2 (SGSN where the AP resides)) occurs during hard handover. After the relocation, the UE performs RAU on the AP. At this moment, the relocation-out is initiated. SGSN2 determines that the current status is inconsistent, and therefore relocation preparation fails. SGSN personnel recommend that relocation should not be performed frequently to solve this problem.

III. Call Drop Occurs After the UE Initiates Relocation

Cause 1

Cause Description

The RB RECFG FAIL message with the cause value being Physical Channel Fail is traced on the Uu interface, and the call is dropped soon.


The RB RECFG FAIL message with the cause value being Physical Channel Fail is received on the Uu interface of the AP.

The cause is that the signals of the target cell are poor. As a result, the UE fails to be synchronized to the target cell and the signals continuously deteriorate, thereby causing call drop.

Solution

Check whether the configured neighboring cells are proper and whether the UE needs to be relocated to the cell with poor signals. Check whether the coverage of the AP cell is normal and whether it is necessary to expand the coverage of the AP cell to enlarge the overlapped area with neighboring cells and improve the handover success rate. For blind handover, check whether the neighboring cells are correctly configured.

Typical Case

None

Cause 2

Cause Description

The RB RECFG FAIL message with the cause value being Invalid Configure is traced on the Uu interface, and the call is dropped soon.




When the RB RECFG FAIL message with the cause value being Invalid Configure is received on the Uu interface of the AP, the common cause is that the IEs (for example, RB ID, RLC SIZE LIST, and compressed mode) in the RB RECFG message constructed by the target cell are incorrect. If the signals continuously deteriorate, the call may be dropped.

Solution

The RB RECFG message is mainly constructed by the target cell. If IncludeRbIdForHoSwitch is set to on (it is set to on by default to enhance the compatibility), the AP only forwards the RB RECFG message constructed by the target cell to the UE over the air interface, without changing any IE in the message. Therefore, if there are invalid parameters, check the IEs in the RB RECFG message and contact the personnel of the target RNC to locate the problem.

Typical Case

The relocation preparation fails due to the incorrect RB ID in the RB RECFG message.

The test procedure is as follows: The UE first initiates the PS service (RB ID = 5) and then the CS service (RB ID = 6, 7, and 8) under the AP. After releasing the PS service, the UE relocates the CS service to Ericsson’s macro network. The RB ID in the Relocation Required message is 6, 7, and 8 but it is 6, 5, and 8 in the RB RECFG message extracted from the Relocation Command message. As mentioned above, the RB whose ID is 5 has been released. Therefore, the UE reports an RB RECFG FAIL message.

The following problem occurs outside the lab. The RANAP_RELOCATION_REQUIRED message carries the current RB list (6, 7, and 8), as shown in the following figure.

On the target RNC, however, the RB list to be re-allocated in the RB RECFG message is 6, 5, and 8. In fact, the PS service corresponding to the TRB whose RB ID is 5 is already released. As a result, the UE reports failure.



The relocation preparation fails due to the incorrect compressed mode in the RB RECFG message.

The UE starts the compressed mode under the AP and attempts a relocation to a macro network (an Alcatel’s macro network). On the AP, tgpsi is set to 1 and tgmp to fdd-measurement. In the relocation reconfiguration message sent to the UE, the macro network is preconfigured with a compressed mode and a compressed mode sequence with tgpsi being 4 and tgmp being fdd-measurement. The UE is configured with two compressed mode sequences with the value of tgmp being the same, which conflicts with the protocol. As a result, the UE reports an RB RECFG FAIL message. In normal cases, deactivate the configurations with the value of tgmp being the same in the compressed mode preconfiguration. In this case, if the DL DCCH switch is turned on, the AP automatically adds the IEs with the compressed mode sequence deactivated for the compatibility with the compressed mode preconfiguration. For details, see 8.6.6.15 in 25.331.

The following problem occurs outside the lab. In the PH_CH_RECFG message, a sequence with tgmp set to fdd-measurement is configured.

In the relocation reconfiguration message sent to the UE, the compressed mode is



preconfigured for the target RNC and a sequence with tgmp set to fdd-measurement is configured. This conflicts with the protocol. As a result, the UE reports failure.

IV. Others

Cause

Cause Description

After the RB RECFG message is sent from the Uu interface, an Iu release request with the cause value being TRELOCoverall expiry is initiated.


After receiving the RANAP_RELOCATION_COMMAND message, the AP initiates an Iu release request with the cause value being TRELOCoverall expiry when failing to receive the IU RELEASE COMMAND message from the CN within 20s. The cause is that the AP expires when waiting for the RANAP_IU_RELEASE_COMMAND message from the CN.

Solution


Typical Case

None










2.4 Inter-AP Hard Handover

2.4.1 Problem Description The inter-AP handover is not initiated as expected.

The source AP receives a RANAP_RELOCATION_PREPARATION_FAILURE message during the inter-AP relocation.

The target AP returns a Relocation Failure message during the inter-AP relocation.

The source AP actively initiates Iu interface release during the inter-AP relocation.

The target AP actively initiates Iu interface release during the inter-AP relocation.

Others

2.4.2 Cause Analysis and SolutionI. The Source AP Receives a RANAP_RELOCATION_PREPARATION_FAILURE

Message




Run DSP_LICENSE to view the board type and license of the AP. If the board type of the AP is HAP, the incoming relocation is not supported. If the license for the relocation from 3G macro cells is unavailable, the relocation from 3G macro cells is not supported. Check the RRCTRLSWITCH command for whether the function of prohibiting the relocation from the 3G macro network is disabled. If the function is enabled, the relocation from 3G macro cells is not supported.

Solution

− If the board type is HAP, replace the HAP with an EAP or ePico.

− If the license for incoming relocation is unavailable, query whether the license is purchased on the AHR.

− If the function of prohibiting the relocation from the 3G macro network is enabled, disable the function.

Typical Case

None






The user access policy used by the current AP is Closed or Group.


Solution

For the AP that uses the Closed or Group mode, the RELOCATION REQ message must carry the IMSI; otherwise, the incoming relocation may fail. The source RNC needs to carry the IMSI in the RELOCATION REQ message.

Typical Case

None




The user access policy that the current AP uses is Closed. View the RELOCATION REQ message. The IMSI must be in the accessible UE list of the AP, as shown in the following figure.



Solution

If the UE can be relocated to the AP, add the IMSI of the UE to the accessible UE list of the AP on the AHR.

Typical Case

None


The relocation from the 3G macro network to the AP fails, and the cause value is OM_INTERVENTION, indicating that the UE to be relocated is not in the accessible UE list or the accessible UE list of the group.


The user access policy used by the current AP is Group.

Check the RELOCATION REQ message. As shown in the following figure, the IMSI must be in the accessible UE list of the AP, group, or other APs in the same group.



Solution

If the UE can be relocated to the AP, add the IMSI of the UE to the accessible UE list of the group to which the AP belongs on the AHR.

Typical Case

None





Solution


Typical Case

None







Solution

View the Relocation REQ message on the Iu interface and check whether the IEs in the message are correctly parsed. If the IEs fail to be parsed or the IEs of R7 and later versions are parsed, as shown in the following figure, the AP version set for the source cell is R7 or later. The AP cannot parse the IEs of versions later than R6. Therefore, change the AP version to R6 or an earlier version for the source cell.


Typical Case

None

II. The Target AP Sends a Relocation Failure Message





Solution

The Relocation Request ACK message contains an RB RECFG message that is constructed by the AP and needs to be sent by the source cell to the UE. After receiving the RB RECFG message, the UE performs air interface synchronization in the AP cell and reports an RB RECFG CMP message. After sending the Relocation Request ACK message, the AP starts a 5s timer. When failing to receive the RB RECFG CMP message from the UE within 5s, the AP initiates Iu interface release with the cause being Failure in the Radio Interface Procedure. In this case, enable Probe tracing to check whether the UE receives the RB RECFG message from the source cell and reports the RB RECFG CMP message.



Typical Case

None








2.5 Failure to Perform Blind Handover to a Macro Cell

2.5.1 Problem DescriptionThe CDT shows that the AP initiates a handover before receiving the measurement report from the UE and the handover fails.

When the UE meets the conditions for blind handover, the AP does not initiate blind handover. That is, the RANAP_RELOCATION_REQUIRED message initiated by the AP is unavailable in the CDT.

Notes:

The AP blindly hands the newly accessed UE over to a macro cell in one of the following cases:



In the case of uplink or downlink EIU congestion, the AP selects a user for blind handover according to the configuration under Device.Services.FAPService.1.X_0D1F7B_FeatureControl.EiuCtrl.EIUCongestCtrl MO. If the blind handover fails, the user still camps on the current cell and the RRC connection is not released.

When the CPU is overloaded, the AP selects the VP user in the current cell for blind handover. If the blind handover fails, the user still camps on the current cell and the RRC connection is not released.

The first user beyond the AP specification (that is, N+1 (N indicates the AP specification)) will be blindly handed over to the macro network according to the specific access mode (Open, Close, Group, or Hybrid). If the blind handover fails, the RRC connection is released.

In Hybrid mode, when the rate decreases due to insufficient cell resources or when the DCCC rate fails to be increased, an unauthorized user will be blindly handed over. If the blind handover fails, the user still camps on the current cell and the RRC connection is not released.

The following cases are supported only in the ePico version:

In the ePico version, when a 1F event report is received, the blind handover is triggered. If the blind handover fails, the user still camps on the current cell and the RRC connection is not released. The HAP does not support this feature.

After the power is primarily overloaded and the DCCC rate fails to be decreased, a user is selected according to the configuration in the CELLLDR command for blind handover. If the blind handover fails, the user still camps on the current cell and the RRC connection is not released. This feature is not supported by default.

In the ePico version, after an emergency call fails to be located, the blind handover is triggered for the user who makes the emergency call. If the blind handover fails, the user still camps on the current cell and the RRC connection is not released. This feature is not supported by default.



The RANAP_RELOCATION_REQUIRED message initiated by the AP is not traced on the Iu interface, and the cause is that no neighboring cell is available.


On the APM, view the parameters under Device.Services.FAPService.1.CellConfig.UMTS.RAN.FDDFAP.NeighborListInUse to check whether there are available neighboring cells.

Query the intra-frequency, inter-frequency, and inter-RAT neighboring cells, as shown in the following figure.



Solution

On the APM, configure neighboring 3G or 2G macro cells for the AP correctly.

Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is not traced on the Iu interface, and the cause is that the manually configured neighboring cells do not support blind handover.


If there are manually configured neighboring cells, check whether these neighboring cells support blind handover. On the APM, view the parameters under Device.Services.FAPService.1.CellConfig.UMTS.RAN.FDDFAP.NeighborList to check whether the configured neighboring cells support blind handover. When X_0D1F7B_BlindHoFlag is set to true, the blind handover is supported; when it is set to false, the blind handover is not supported.

Check whether the manually configured intra-frequency neighboring cells support blind handover, as shown in the following figure.



Check whether the manually configured inter-frequency neighboring cells support blind handover, as shown in the following figure.

Check whether the manually configured inter-RAT neighboring cells support blind handover, as shown in the following figure.

Solution

On the APM, modify the manually configured neighboring cells to support blind handover.

Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is not traced on the Iu interface, and the cause is that the manually configured neighboring 3G cells cannot be AP cells.


If the manually configured neighboring 3G cells support blind handover, check whether these neighboring 3G cells are AP cells. On the APM, view the parameters under Device.Services.FAPService.1.CellConfig.UMTS.RAN.FDDFAP.NeighborList to check



whether the configured neighboring cells are AP cells. AP cells do not support blind handover.

Check whether the manually configured intra-frequency neighboring cells are AP cells, as shown in the following figure.

Check whether the manually configured inter-frequency neighboring cells are AP cells, as shown in the following figure.

Solution

If no neighboring 3G macro cell is configured, configure at least one.

Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is not traced on the Iu interface, and the cause is that the handover switch is turned off.


If neighboring cells are correctly configured, check whether the handover algorithm switch is turned on. On the APM, view the parameters under Device.Services.FAPService.1.X_0D1F7B_FeatureControl.HandOver.RelocationToMacro. Check whether the CS handover switches are on for the CS service and whether the PS handover switches are on for the PS service, as shown in the following figure.



Solution

Configure the corresponding handover algorithm switches according to carrier requirements. If a handover algorithm switch is turned off, the corresponding blind handover is not supported.

Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is not traced on the Iu interface. For the handover to a neighboring 2G cell, the possible cause is that the UE capability or service does not support the handover.


If neighboring cells exist and support blind handover, check whether the UE supports 2G capabilities. If the UE supports 2G capabilities, check whether the service supports the handover to a neighboring 2G cell. For example, the VP service does not support the handover to a neighboring 2G cell.

Solution

If the UE does not support 2G capabilities, replace the current UE with a UE supporting 2G capabilities, configure a UE supporting 2G capabilities, or configure a neighboring 3G macro cell. If the service does not support the handover to a neighboring 2G cell, configure a correct neighboring 3G macro cell.

Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is not traced on the Iu interface. For the handover to an inter-frequency neighboring 3G cell, the possible cause is that the frequency is locked for the UE.




If neighboring 3G cells exist and support blind handover, check whether the frequency is locked for the UE.

Solution

If the frequency is locked for the UE, unlock the frequency.

Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is traced on the Iu interface. The blind handover, however, still fails.


The signal quality of the target cell is poor. Therefore, after a blind handover request is initiated, RB reconfiguration fails on the Uu interface. Use an engineering UE to check the signal quality of the target cell. If the signal quality is too poor, the AP cannot ensure the success rate of blind handover.

The following figure shows an RB reconfiguration failure message on the Uu interface.

Solution

Use an engineering UE to search the macro cell with the best signal quality surrounding the AP, and then run Device.Services.FAPService.1.X_0D1F7B_FeatureControl.HandOver.BlindHoPriority to adjust the blind handover policy; or improve the signal quality of the target neighboring cell.



Typical Case

None


The RANAP_RELOCATION_REQUIRED message initiated by the AP is traced on the Iu interface. The blind handover, however, still fails.


After a handover request is initiated, the CN returns a failure message. Locate the cause according to the failure message returned from the CN. Possible causes are that the target neighboring cell is incorrectly configured, the target neighboring cell does not support hand-in, and the resources of the target cell are congested.

The following figure shows blind handover failure messages on the Iu interface.

The following figure shows the failure message returned from the CN.



Solution

Check whether the configured neighboring cell exists or whether the neighboring cell parameters are correctly configured. If the neighboring cell parameters are incorrectly configured, configure them correctly. If the resources of neighboring macro cells are congested, release resources of the target neighboring cell, and then initiate blind handover to the target neighboring cell again. If the configured neighboring cells do not support hand-in, modify the configuration of neighboring macro cells or reconfigure the neighboring cells that support hand-in.

Typical Case

None




AP configuration file Mandatory

Uu, Iu, and CDT tracing information on the AP Mandatory

2.6 A UE Fails to Reselect the AP from the Macro Network

2.6.1 Problem DescriptionA UE camps on the macro network. After entering the coverage area of a Femto cell, the UE fails to reselect the AP.





The macro network cell is not configured with a Femto cell as a neighboring cell or as a virtual neighboring cell.


Enable Probe tracing and enable the UE to camp on the macro network. It is found that the SIB11 message is traced, as shown in the following figure.

Check the SIB11 message for intra-frequency and inter-frequency neighboring cells. For an intra-frequency neighboring cell, check whether the scrambling code of the AP cell exists in newIntraFreqCellList, as shown in the following figure.

For an inter-frequency neighboring cell, check whether the frequency and scrambling code used by the AP cell exist in newInterFreqCellList, as shown in the following figure.



Solution

If the SIB11 message does not carry the frequency and scrambling code of the corresponding AP cell, contact macro network engineers to configure them.

Typical Case

None


The CN is not configured with an equivalent PLMN. If the air interface PLMN used by the AP is different from the PLMN of the macro network, configure the two PLMNs as equivalent PLMNs on the MSC and SGSN.


Enable the test UE (U120E) to camp on the macro network manually, and enable Probe tracing. Find the RAU Accept and LAU Accept messages from the macro network on which the UE camps.

If the RAU Accept or LAU Accept message does not carry the equivalent-PLMNs IE, no equivalent PLMNs are configured.

Solution



Contact the CN personnel to configure the two PLMNs as equivalent PLMNs on the MSC and SGSN.

Typical Case

None


The macro network is configured with hierarchical cell structure (HCS) neighboring cells, and the priority of the Femto cell is low.


Enable the U120E to camp on the macro network, enable Probe tracing, and view the SIB11 message.

Check whether the SIB11 message carries the use-of-HCS IE, as shown in the following figure.

If hcs-not-used is displayed, the macro network is not configured with HCS neighboring cells. In this case, the cause can be ignored.

If hcs-used is displayed, the macro network is configured with HCS neighboring cells.

In this case, check the priority of the AP cell. It is recommended that field engineers set the priority of the AP cell to be higher than the priorities of other cells on the macro network.

The priorities of HCS neighboring cells range from 0 to 7 (0 indicates the lowest priority and 7 indicates the highest priority).



Solution

Coordinate macro network engineers to increase the priority of AP neighboring cells.

Typical Case

None



Probe tracing (The UE camps on the macro network.) Mandatory

UE model Mandatory

2.7 A UE Fails to Reselect the 2G Macro Network from the AP

2.7.1 Problem DescriptionThe UE camps on the AP. After entering the coverage area of the 2G macro network from the AP coverage area, the UE fails to reselect the 2G macro network.



The AP is not configured with automatic neighboring 2G macro network cells.


On the main page of the AP Manager, choose Configuration > Zone Configuration. On the displayed page, select the zone to be modified, and then click Active. Choose Device > Services > FAPService > i > REM > GSM in the left directory tree. In the right pane, query whether the AP is currently configured with the PLMN IDs of neighboring 2G cells through REMPLMNList. If not, see Solution in "Cause 1" in section 2.7.2"Cause Analysis and Solution" for troubleshooting.

Solution

Configure REMPLMNList (GSM band list) correctly, and then set ScanOnBoot and ScanPeriodically to true respectively. Then the AP is configured with neighboring 2G macro network cells automatically.

− Preconditions

Up to six neighboring 2G cells can be automatically searched. When the neighboring cell auto-configuration switch is set to TRUE and the neighboring 2G cell combination switch is set to ON, use the neighboring 2G cells configured manually and automatically; otherwise,



use the manually configured neighboring cells only. For the ePico, use the neighboring cells configured manually and automatically, and then turn on the combination switch of neighboring 2G cells.

− Procedure

On the main page of the AP Manager, choose Configuration > Zone Configuration. On the displayed page, select the zone to be modified, and then click Active. In the left directory tree, choose Device > Services > FAPService > i > REM > GSM. In the right pane, set REMPLMNList, as shown in the following figure.

On the main page of the AP Manager, choose Configuration > Single Configuration. On the displayed page, select the AP to be configured, and then click Configure.

In the left directory tree, choose Device > Services > FAPService > i > REM > GSM. In the right pane, set ScanOnBoot to true (default).

The following figure shows how to query the result of searching automatic neighboring 2G cells.



If neighboring 2G cells are configured but no automatic neighboring 2G cell is queried, the signals of the neighboring macro cells may be too weak.

Typical Case

None


The AP is not configured with manual neighboring 2G macro network cells.


Query manual neighboring 2G cells.

Set the method of querying manual neighboring 2G cells.

By configuring neighboring GSM cells, you can adjust the parameters for the neighboring GSM cells of the AP, for example, add, delete, or modify neighboring GSM cells, and shield or modify certain automatically searched neighboring GSM cells. Configuring neighboring GSM cells properly can improve the handover and reselection success rates.

− Procedure

Add neighboring GSM cells.

On the main page of the AP Manager, choose Configuration > Single Configuration. On the displayed page, select the ePico3801B whose configuration needs to be adjusted, and then click Configure.

In the left directory tree, choose Device > Services > FAPService > i > CellConfig > UMTS



> RAN > FDDFAP > NeighborList > InterRATCell > GSM, and then click Add to set various parameters according to the actual network situation, as shown in the following figure.

Click Apply. The prompt box is displayed, indicating that the configuration parameters are successfully added.

Modify neighboring GSM cells.


In the left directory tree, choose Device > Services > FAPService > i > CellConfig > UMTS > RAN > FDDFAP > NeighborList > NeighborList > InterRATCell > GSM. In the right pane, select the neighboring cell to be modified in Instance List, and then click Apply to modify various parameters according to the actual network situation.

Click Apply. The prompt box is displayed, indicating that the configuration parameters are successfully modified.

Delete neighboring GSM cells.


In the left directory tree, choose Device > Services > FAPService > i > CellConfig > UMTS > RAN > FDDFAP > NeighborList > NeighborList > InterRATCell > GSM. In the right pane, select the neighboring cell to be deleted in Instance List, and then click Delete.

In the displayed confirmation dialog box, click OK. The selected neighboring GSM cell is deleted.


When neighboring 2G and 3G macro cells coexist, 3G reselection measurement is preferred.


Check whether neighboring 2G and 3G macro cells coexist.

Solution

Delete neighboring 3G cells, and then test the reselection to neighboring 2G cells.



Typical Case

None



AP version number Mandatory

UE (terminal) model Mandatory

Uu interface tracing information about the AP Mandatory


AP configuration file Optional

2.8 A UE Fails to Reselect the 3G Macro Network from the AP

2.8.1 Problem DescriptionThe UE camps on the AP. After entering the coverage area of the 3G macro network from the AP coverage area, the UE fails to reselect the 3G macro network.



The AP is not configured with automatic neighboring macro network cells.


The following figure shows how to query automatic neighboring 3G cells. If no automatic neighboring 3G cells are queried, see Solution in "Cause 1" in section 2.8.2"Cause Analysis and Solution" for troubleshooting.

Solution



After configuring the frequency list of neighboring macro cells for the AP, search neighboring cells according to the macro network frequency list after the AP is powered on, and enable the function of automatically configure neighboring macro network cells, thereby implementing automatic network planning and optimization.

− Preconditions

UARFCNDLList is correctly configured, and the neighboring cell auto-configuration switch is turned on (the neighboring cell combination switch also requires your attention in the ePico version). When the neighboring cell auto-configuration switch is set to TRUE and the combination switch of neighboring 3G cells is set to ON, use the neighboring 3G cells configured manually and automatically; otherwise, use the manually configured neighboring cells only.

The following figure shows the setting of the neighboring cell combination switches on the ePico.

− Background information

When a frequency list of neighboring macro cells is configured for each AP in a zone, the AP automatically scans all the neighboring cells in the list.

After a frequency list of neighboring macro cells is configured, the automatic neighboring cell search is enabled in the next WCDMA radio environment measurement (REM) period or when the AP is powered on next time.

A frequency list of neighboring macro cells contains up to four valid frequencies. At most six neighboring macro network cells (including intra-frequency or inter-frequency neighboring cells) can be automatically searched, including at most two inter-frequency neighboring cells.

− Procedure

On the main page of the AP Manager, choose Configuration > Single Configuration. On the displayed page, select the AP to be configured, and then click Configure.

In the left directory tree, choose Device > Services > FAPService > i > REM > WCDMAFDD.

In the right pane, set ScanOnBoot to true, turn on the switch of automatically searching neighboring WCDMA macro network cells upon power-on (this switch is turned on by



default), and then set ScanPeriodically to true (default).

Set the REM startup policy when there are services on the AP through InServiceHandling, timeout time of performing REM through ScanTimeout, startup time of the periodic REM through PeriodicTime, and interval of performing periodic REM through PeriodicInterval. It is recommended to retain the default settings of InServiceHandling, ScanTimeout, and PeriodicInterval.

On the main page of the AP Manager, choose Configuration > Zone Configuration. On the displayed page, select the zone to be modified, and then click Active.

In the left directory tree, choose Device > Services > FAPService > i > REM > WCDMAFDD, and set UARFCNDLList in the right pane, as shown in the following figure.

Typical Case

None


The AP is not configured with manual neighboring 3G macro network cells.


The following figure shows how to query manual intra-frequency neighboring 3G cells. The method is also applicable for manual inter-frequency neighboring 3G cells.



If no neighboring cells are queried, see Solution in "Cause 2" in section 2.8.2"Cause Analysis and Solution" for troubleshooting.

Solution

The following describes how to add, delete, or modify intra-frequency neighboring cells. The methods mentioned are also applicable for manual inter-frequency neighboring cells.

By configuring intra-frequency neighboring cells, you can adjust the parameters for the intra-frequency neighboring cells of the AP, for example, add, delete, or modify intra-frequency neighboring cells, and shield or modify certain automatically searched intra-frequency neighboring cells. Configuring intra-frequency neighboring cells properly can improve the handover and reselection success rates.

− Procedure

Add intra-frequency neighboring cells.

On the main page of the AP Manager, choose Configuration > Single Configuration. On the displayed page, select the AP whose configuration needs to be adjusted, and then click Configure.

In the left directory tree, choose Device > Services > FAPService > i > CellConfig > UMTS > RAN > FDDFAP > NeighborList > IntraFreqCell, and then click Add to set various parameters according to the actual network situation, as shown in the following figure.

Click Apply. The prompt box is displayed, indicating that the configuration parameters are successfully added.

Modify intra-frequency neighboring cells.


In the left directory tree, choose Device > Services > FAPService > i > CellConfig > UMTS > RAN > FDDFAP > NeighborList > IntraFreqCell. In the right pane, select the neighboring cell to be modified in Instance List, and then click Apply to modify various parameters according to the actual network situation.

Click Apply. The prompt box is displayed, indicating that the configuration parameters are successfully modified.

Delete intra-frequency neighboring cells.




In the left directory tree, choose Device > Services > FAPService > i > CellConfig > UMTS > RAN > FDDFAP > NeighborList > IntraFreqCell. In the right pane, select the neighboring cell to be deleted in Instance List, and then click Delete.

In the displayed confirmation dialog box, click OK. The selected intra-frequency neighboring cell is deleted.

Typical Case

None


The AP network has a different PLMN from the macro network or other AP cells are available under the AP network. The cell with the same PLMN as the current cell is preferred unless the signal quality of the cell is very poor.


Check whether other AP cells are available under the AP network.

Solution

Set the PLMN of the macro network to the EPLMN of the AP on the CN.

Typical Case

None


If the AP uses the manual mode, the HCS feature is enabled on the AP, and the priority of the HCS cells is higher than that of macro network cells, it is difficult to reselect the macro network (if the signal quality of the AP network is not too poor).


If the HCS feature is enabled and the AP has a higher priority than the macro network, the AP cell is preferred when the signal quality of the AP is higher than the threshold.

Solution

− Replace the current UE with a UE that does not support the HCS feature.

− Enable the neighboring cell auto-configuration function.

− Disable the HCS feature of the AP, as shown in the following figure.



− Modify the HCS feature of the macro network (taking the manual inter-frequency neighboring cell as an example), as shown in the following figure.










2.9 A UE Fails to Perform Reselection Between APs

2.9.1 Problem DescriptionA UE fails to perform reselection between APs.



The AP is not configured with inter-AP neighboring cells. In ePico3801V200R12C00SPC100 and earlier versions, the inter-AP automatic neighboring cell configuration is not implemented.


Check whether there are inter-AP neighboring cells according to the method shown in the following figure. The RNC IDs of inter-AP neighboring cells must be the same.

Solution

Configure inter-AP neighboring cells manually or automatically. The following figure shows the procedure for manually configuring inter-AP neighboring cells. When configuring inter-AP neighboring cells manually, ensure that the value of RNCID is the same and ApCellInd is set to TRUE.



Typical Case

None


The target AP is configured with a user access policy.

If the user access policy of the target AP is Closed or Group but the IMSI of the UE is not added to the accessible UE list of the AP, the UE cannot camp on the target AP after initiating reselection.


Log in to the AHR and find the definition information about the target AP. Check whether User Access Policy is set to Closed or Group.



Solution

Add the IMSI of the UE to the accessible UE list of the target AP.

− Closed mode



− Group mode

After querying the target group, check whether the accessible UE list contains the IMSI of the UE, as shown in the following figure.




If the source AP uses manual inter-AP neighboring cells, enables the HCS feature, and has a higher HCS priority than the target AP, it is difficult for the UE to reselect the target AP.


The following figure shows how to configure HCS reselection of the source AP.

The following figure shows how to configure the HCS feature for manual inter-AP neighboring cells.










2.10 Failure to Redirect an Emergency Call to a Macro Cell

2.10.1 Problem DescriptionThe RRC_RRC_CONN_REJ signaling carrying redirectionInfo is not traced on the Uu interface of the AP.





The AP has no neighboring 2G or 3G cell.


The neighboring 2G and 3G cells of the AP can be neighboring cells searched automatically, neighboring cells configured manually, or neighboring cells searched automatically and neighboring cells configured manually, depending on the setting of NeighborListSelfConfigEnable under Device.Services.FAPService.1.FAPControl.UMTS.SelfConfig.

Check whether the AP has neighboring 2G or 3G cells, as shown in the following figure.

Solution

Configure automatic and manual neighboring 2G and 3G cells. For details, see "Adjusting the uBro Network" in the ePico3801B User Guide (V200R012_01).

Typical Case

None




EmergencyCallRedirectionSwitch is set to off.


Log in to the APM client, select Single Configuration, and then check whether EmergencyCallRedirectionSwitch is set to off, as shown in the following figure.

Solution

Set EmergencyCallRedirectionSwitch to on for the AP on the APM.

Typical Case

None





Fault diagnosis information about the AP Mandatory

Signaling traced on the Uu and Iu interfaces when an emergency call is made

Mandatory



3 Voice Quality Problems

3.1 Abnormal Uplink AMR Voice

3.1.1 Problem DescriptionA user makes a call in a Femto cell, and the called user cannot hear voices normally.



Many packets are lost on the transport network, thereby causing poor voice quality.


Enable the congestion control algorithm for the AP and AG.

Enable internal message tracing (MACC<-->NBM) of the AP.



Check whether there are many congestion indications in the traced messages.

Solution

Modify the DSCP value in the packets sent by the AP and AG to increase the packet priority.

Typical Case

StarHub modifies the DSCP value to improve voice quality.

Symptom:



The voice quality of StarHub’s existing network is poor.

Troubleshooting procedure:

Analyze the CDT tracing result. It is found that many packets are lost on the network.

Connect a PC to the live network and perform a ping test on the SGW. It is found that the packet loss rate is high and the delay variation is great.

Modify the DSCP value of the AP and AG. Then the voice quality is improved obviously. StarHub’s fixed network supports the DSCP.

Conclusion:

The poor QoS of the transport network affects the voice quality.


The dejittering algorithm parameter of the AG is set to an improper value.


In SGSN9810 V800R009C10 and later versions, the dejittering algorithm is optimized. The default value of the dejittering algorithm parameter is 1. You need to set this parameter to 3.

The command is LST UAFUPUBPARA.

Solution

Modify the dejittering parameters of the AP by running the following command:

SET UAFUPUBPARA:JBE=ON, JBDROPTH=3;



Typical Case

The dejittering parameters of VDF in Egypt are improperly set, thereby causing poor voice quality.

Symptom:

The voice quality is poor after VDF in Egypt updates the SPC301AG.


Compare the versions before and after the upgrade. It is found that only the dejittering algorithm of the AG is obviously modified.

Modify the dejittering parameters of AG. Then the voices return to normal.

Conclusion:

In AG SPC301, the default parameter of the dejittering algorithm is improperly set, thereby affecting voice quality.


The voice multiplexing function of the AG affects the voice quality.


Disable the voice multiplexing function of the AP, and then perform a test again. If the voice quality becomes normal after the voice multiplexing function is disabled, it can be determined that this problem is caused by the voice multiplexing function.



Solution

Disable the voice multiplexing algorithm of the AG for the moment and then enable it after upgrading the AG.

Typical Case

The voice quality of VDF in Greece is poor.

Symptom:

The voice quality of the existing network is poor.


Perform a test for a long time in the lab and restore voices from the data captured within the time range with poor voice quality. Great differences exist between the restored voices and the voice file received by the UE.

Analyze the AG statistics information. It is found that much data does not pass the dejittering module when the voice quality is poor.

Disable the voice multiplexing function and perform a test again. Then the voice quality becomes normal.

Conclusion:

When voice multiplexing and header compression are enabled, the dejittering module of the AG works abnormally, thereby affecting voice quality.


The voice multiplexing of the AG causes one-way audio.


The IP bearer is used between the AG and the CS domain of the CN.



Disable the voice multiplexing function of the AP. Then one-way audio no longer exists.

Solution

Disable the voice multiplexing algorithm of the AG for the moment, and then enable it after upgrading the AG to SGSN9810 V800R009C10 or a later version.

Typical Case

One-way audio exists in Telefonica in Spain.

Symptom:

One-way audio occurs during a voice call.


Build IP bearer environment in the lab and make the symptom recur.

Disable the voice multiplexing function. Then the call returns to normal.

Enable the voice multiplexing function and disable header compression. The voice becomes normal.

Enable the voice multiplexing function and header compression. One-way audio occurs.

Conclusion:

When voice multiplexing and header compression are enabled, the AG restores the RTP header incorrectly, thereby causing one-way audio.


The dejittering algorithm of the AG causes voice abnormalities.


One-way audio no longer occurs after the voice dejittering algorithm of the AG is disabled.

Solution

Disable the voice dejittering algorithm of the AG for the moment, and then enable it after upgrading the AG to SGSN9810 V800R009C10 or a later version.

Typical Case

One-way audio occurs after consecutive soft handovers.

Symptom:

After consecutive soft handovers, one-way audio occurs in the uplink.


Perform tests repeatedly, and find that one-way audio occurs after a handover and disappears after another handover.

Capture packets to restore voices. It is found that the uplink voice data is normal before arriving at the AG.

Disable the dejittering algorithm of the AG. Then the problem does not occur any longer.

Conclusion:



Consecutive soft handovers trigger the defects of the dejittering algorithm of the AG, thereby causing one-way audio.


The CN fault causes voice abnormalities.


Perform the same test on the macro network. The same problem occurs. The voice problems caused by the CN are regular. For example, echo or noise such as "da da" exists during a call.

Solution

Urge field CN engineers to rectify the fault.

Typical Case

A board of the MSC on TMO CN is faulty, thereby causing poor voice quality.

Symptom:

The AMR voice quality is poor during a call in the Femto cell.


Capture packets between the SGW and AG and restore voices through the captured packets. It is found that the voices are normal before the packets arrive at the AG.

Query the history alarms on the AG. It is found that a board of the peer MSC is faulty.

Reset the board. Then the fault is rectified.

Conclusion:

The board fault on the customer’s CN results in voice abnormalities.



Detailed fault symptom Mandatory



Internal tracing information (MACC<--->NBM) about the AP

Mandatory

Packets captured on the AG side Mandatory



4 Upgrade Problems

4.1 Failure to Synchronize Parameters Between the APM and the AP

4.1.1 Problem DescriptionParameter synchronization fails in R12.

Symptom:

The AP is reset repeatedly. The following figure shows the running logs before the reset.

Character information:

0101-080542:[ CfgData Operate ][ Warning ][Config File Apply Info The

Parameter Follow After(Password) Syntax Error.]

0101-080544:[ CfgData Upgrade ][ ERROR ][Config data apply fail by file

download]

0101-080545:[ Board Operate ][ info ][User Reset Board, By Reason Apply

Config File Fail.]

The preceding information shows that the board is reset because of failure to apply the configuration file. The specific cause may vary with the actual situation.



Certain parameters do not comply with the XML syntax.


View log records to locate the cause for file configuration failure.

For example, the failure cause in the preceding log is as follows:

0101-080542:[ CfgData Operate ][ Warning ][Config File Apply Info The

Parameter Follow After(Password) Syntax Error.]

The preceding information indicates that a syntax error exists in the parameter following Password and the possible cause is that the integer type is beyond the value range. For



example, the value of UETxPwrThresholdEvent6b ranges from -50 to 30 according to the syntax, but this parameter is actually set to 40. As a result, an error occurs.

<element name="UETxPwrThresholdEvent6b">

<simpleType>

<restriction base="integer">

<minInclusive value="-50" />

<maxInclusive value="30" />

</restriction>

</simpleType>

</element>

The string is not in the enumerated values.

For NonCSGUEAccessDecision, for example, the value defined in the syntax is Local Query FAP-GW By Core, but the user sets this parameter to LOcal, thereby causing this type of errors.

<element name="NonCSGUEAccessDecision">

<simpleType>

<restriction base="string">

<enumeration value="Local" />

<enumeration value="Query FAP-GW" />

<enumeration value="By Core" />

</restriction>

</simpleType>

</element>

Based on the preceding examples:

Check the configuration file UAPCfg.xml in the software package.

<Password>admin</Password>

<PeriodicInformEnable>true</PeriodicInformEnable>

<PeriodicInformInterval>30</PeriodicInformInterval>

It is found that Password is followed by PeriodicInformEnable. Then check the file delivered by the APM. It is found that PeriodicInformEnable is set to TRUE, which is different from the setting in the UAPCfg.xml file. This problem occurs at the earlier stage of development and does not occur now.


The string delivered by the APM exceeds the configured length.


The log records the failure cause:

0101-080542:[ CfgData Operate ][ Warning ][Config File Apply Info Para Length

too large (PLMNID),valid maxlen:6.]

The preceding information indicates that the string exceeds the configured length. For example, the maximum length of the PLMN in the XML file is 6, but the configured PLMN is 1234567. As a result, the PLMN fails to be configured.




Multiple instances configured for the APM are incorrectly operated.


View the log. The log contains the following information:

0101-080542:[ CfgData Operate ][ Warning ][Config File Apply Info Add Moc

Fail, Attach Max Number (IntraFreqCell)]

In this instance (IntraFreqCell), the maximum value of IntraFreqCell is 5. If the value delivered by the APM exceeds 5, thereby causing an error.

0101-080542:[ CfgData Operate ][ Warning ][Config File Apply Info Create

parameter unikey absent (IntraFreqCell)]

For the IntraFreqCell instance, RNCID and CID are its unikeys. When the APM adds, configures, and deletes an instance, these two parameters must be carried; otherwise, the AP cannot find the corresponding instance.

0101-080542:[ CfgData Operate ][ Warning ][Config File Apply Info update

parameter unikey not match (IntraFreqCell)]

For the IntraFreqCell instance, RNCID and CID are its unikeys. When the APM modifies an instance, the AP fails to find a matching instance internally.

4.1.3 SolutionSynchronize parameters between the AP and the APM. An error may occur when the version and parameters delivered by the AP fail to meet the northbound constraint or when bugs exist on the APM.

Parameter synchronization may be triggered in one of the following cases:

The XML file on the AP is corrupt.

The interaction between the APM and the AP times out.

During device replacement, the parameters of the version to be replaced are delivered.

The user delivers parameters on the page of the APM.



Exported AP logs Mandatory

Exported TR069 log from the APM Mandatory



4.2 The AP Fails to Be Upgraded Through the APM

4.2.1 Problem DescriptionThe software of the AP fails to be upgraded through the APM.



The APM fails to deliver the Download request message within 30s when the transmission QoS of the public network is poor, many packets are lost on the network, or the network delay is great.


The failure cause for the upgrade task is "Download request overtime." Search in the apmgr-tr069.log file on the APM for the following messages:

Solution

In this case, no human intervention is required. The APM automatically triggers re-downloading. In general, the upgrade will be finally successful.

Typical Case

The VMS office in Vietnam fails to be upgraded. During the ping operation, the delay is great and the packet loss rate is about 40%. Upgrade the VMS office for multiple times and upgrade only several APs each time. Finally, the upgrade is successful.


When the AP and FTP server download the software package, the AP is reset or the transmission is interrupted (for example, the network cable is loose or the network quality is very poor).


The failure cause for the upgrade task is "Transfer fail and retransfer." Search in the apmgr-tr069.log file on the APM for the following messages:

Solution

In this case, no human intervention is required. The APM automatically triggers re-downloading. In general, the upgrade will be finally successful.



Typical Case

None


Cause 1 or 2 occurs for consecutive five times.


The failure cause for the upgrade task is "Transfer fail and retransfer out of maximum." Check whether the apmgr-tr069.log file on the APM contains the preceding timeout information, fault code 9801, or fault code 9802.

Solution

The maximum number of failures is reached. Therefore, the APM does not perform automatic retransfer any longer and manual upgrade is required. Check the network because each upgrade fails.

Typical Case

None


The AP is being upgraded, and therefore the new upgrade task fails.


The failure cause for the upgrade task is "Request denied." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9001. In addition, search in the upgrade task (by APIndex) for determining whether the AP is being upgraded.

Solution

Perform new upgrade only after the current upgrade is complete.

Typical Case

None


The AP is performing an uploading task or synchronizing parameters, thereby failing to create an upgrade task.


The failure cause for the upgrade task is "Resource exceeded." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9004. Check whether there are uploading tasks or there are performance files being uploaded at the integral point on the APM.

Solution

Perform upgrade only after the uploading task is complete.



Typical Case

None


The software package is not downloaded within 30 minutes.


The failure cause for the upgrade task is "Download failure." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9010.

Solution

This is a bug in earlier versions. This bug is solved in versions later than ePico3801V200R010SPC100 and UAP2105V300R011C00SPC120. If a user uses the seamless upgrade, the emergency upgrade is recommended to speed up the upgrade. If the software package still fails to be downloaded within 30 minutes in the emergency upgrade, ask the user to perform upgrade again when the network quality becomes better, or upgrade the AP to a later version.

Typical Case

None


The transmission QoS of the public network is poor, or the FTP file server is incorrectly set or is abnormal.


The failure cause for the upgrade task is "Unable to contact file server." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9015 or 9016. If the message exists, connecting the AP, logging in to the FTP server, or running the FTP command fails.

Solution

Check network quality. If the failure cause is Unable to contact file server for the upgrade each time, check whether the IP address of the FTP server on the APM and the FTP server are abnormal.

Typical Case

None


When the software package is downloaded, the data received within five minutes is less than 10% of the software package.


The failure cause for the upgrade task is "Unable to complete download." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9017. If the message exists,



the AP determines that the network quality is very poor and asks the APM not to re-deliver the upgrade task.

Solution

This is a bug in earlier AP versions. In ePico3801V200R010SPC100 and UAP2105V300R011C00SPC170, the following modification is made: if the network quality is very poor, error code 9802 is reported to the APM for triggering the APM to perform upgrade again.

Typical Case

None


After the AP is upgraded and reset, the version is rolled back because one of the following faults occurs:

− The software package is damaged, thereby failing to decompress the Bin file.

− The VM module fails to initialize the FID/PID.


The failure cause for the upgrade task is "File corrupted." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9018. You can also export the SysImportRunInfo_0.txt file of the AP and search in the file for [Ver Roll Bak] to determine the rollback cause. The file exists in UAP2105 V300R011C00SPC170 and ePico3801V200R011C00SPC010.

Solution

This symptom rarely occurs. You can power on and power off the AP before performing upgrade again.

Typical Case

None


The HAP and ePico software packages support mutual upgrade.


The failure cause for the upgrade task is "File authentication failure." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9019. In addition, you can check whether the AP type under Single Configuration on the APM matches the type of the software package to be upgraded.

Solution

Select the software package with the same type as the AP type for upgrade.

Typical Case

None




After the software package is downloaded, checking the UAP.ini file in the software package fails.


The failure cause for the upgrade task is "File authentication failure." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9019. If the same error is prompted on the APM, the problem may result from cause 10 or cause 11.

Solution

The probability that an error occurs in decompressing software is small. You can perform upgrade again through the APM to solve this error.

Typical Case

None


The delayed activation of the software version fails.


The failure cause for the upgrade task is "Failed to active delay-active software." Search in the apmgr-tr069.log file on the APM for a message with its faultcode being 9803.

Solution

This is a small-probability event. You can perform upgrade again through the APM to solve the problem.

Typical Case

None



apm-tr069.log file

/opt/APManager/server/apmanager/log/apmgr-tr069.log or

/opt/APManager/server/apmanager/logbak/ apmgr- tr069.log.xxxx-xx-xx.gz

Mandatory

AP running log Mandatory

APIndex and APEI Mandatory

File server configuration on the APM Optional

vsftpd.log file (/var/log/vsftpd.log) Optional

Serial port information (contact R&D engineers for the serial port command)

Optional



5 Data Transmission Problems

5.1 Unstable Data Transmission in the HSDPA Service

5.1.1 Problem DescriptionThe UE under the AP initiates the HSDPA service. The rate is unstable, for example, jitter occurs, the rate decreases suddenly, or the rate decreases to 0.

Figure a.1 Jitter

Figure a.2 Rate that decreases to 0



Figure a.3 Rate that decreases suddenly



The air interface quality in the area where the UE resides is poor. The signal coverage of the AP may be poor or interference may exist.


If it is suspected that this problem is caused by air interface, you need to choose Realtime Performance Monitoring > Connection Performance Monitoring > EcNo&RSCP (as in the following figure) on the LMT to check whether the RSCP and EC/NO are normal when the UE initiates the service.

Figure a.1 Signal noise ratio (SNR) and RSCP of the cell

Solution

Modify MaxFAPTxPowerInUse and PCPICHPowerInUse under Device.Services.FAPService.{i}.CellConfig.UMTS.RAN.FDDFAP.RF to increase the transmit power, or move the UE or AP.

Typical Case

None




The transmission QoS of the public network is poor, for example, many packets are lost on the network or the network jitter is great.


If it is suspected that this problem is caused by the transmission QoS, you can perform a ping test first to check whether the QoS of the transport network between the AP and SeGW meets the requirement. The following table describes the QoS requirements of various services for the transport network.

Table 1.1 QoS requirements of all types of services

Solution

None

Typical Case

None


The CPU is overloaded. After the CPU usage reaches 85%, the RRM is triggered to decrease the user rate. After the CPU usage reaches 95%, a half of PS service packets are discarded.


If it is suspected that the CPU is overloaded, enable CPU usage tracing on the LMT, as shown in the following figure. If the CPU usage periodically increases and then decreases after the CPU usage reaches about 95%, the CPU is overloaded.



Figure a.2 CPU usage detection

Solution

Decrease the number of services or traffic under the AP to lower the CPU usage.

Typical Case

None


Packet loss occurs on the AG or CN.


When using the UE under the AP to make a voice call, capture packets on the AG or CN to check whether packet loss occurs on the AG or CN.

Solution

If unstable data transmission is caused by packet loss on the AG or CN, ask AG or CN engineers for fault location.

Typical Case

None





Traced cell SNR and RSCP Mandatory

Packets captured on the UE side Mandatory

Packets captured on the AG side Mandatory

Packets captured on the AP side Optional

Before information collection, you are advised to exclude the faults of the terminal and FTP download source by conducting a comparison test on a macro network.



5.2 Low Data Transmission Rate in the HSDPA Service

5.2.1 Problem DescriptionThe UE initiates the HSDPA service under the AP. The rate is low but stable.

Figure a.1 Low data transmission rate



The subscription rate of the UE is low.


Check the rate applied for the UE through the directly transferred messages on the Uu interface.



Solution

Re-define the SIM card on the HLR and change the subscription rate to 7.2 Mbit/s.

Typical Case

None




The HSDPA7.2M license of the HAP is not enabled, and therefore the AP rate does not exceed 3.6 Mbit/s.


When the license is not enabled, the obvious feature is that the rate is low and stable. You can check whether the AP license is enabled on the APM.

Solution

Enable the license on the AHR.



Typical Case

None


The bandwidth of the AG or CN is limited, thereby causing a low AP rate.


Contact AG or CN engineers for checking the bandwidth setting of the AG or CN.

Solution

Contact AG or CN engineers for modifying the bandwidth setting of the AG or CN.

Typical Case

**********************************************************************

The HSDPA multi-thread download rate of Spain’s Telefonica fails to reach the theoretically maximum value.

In Telefonica’s lab, the HSDPA download rate does not exceed 6 Mbit/s. Check the configured PCR on the AG by running the following command:



ADD TRAFFIC: IDX=19, SC=UBR, PCR=15000, CDVT=500000;

Convert the PCR into Mbit/s, that is, PCR = 15000 ATM cells/sec = 15000 cells/sec x 48 Bytes/cell *x 8 bit/Byte = 5.76 Mbit/s. This indicates that the AG restricts the Iu-PS bandwidth. Modify the PCR to 20000 and the maximum supported bandwidth to 7.68 Mbit/s. In addition, check the ATM PCR configured on the SGSN and modify it to a reasonable value. Then the problem is solved.

***********************************************************************


The AG route is incorrectly set. As a result, packets are lost between the AG and the SGW, thereby causing a low rate.


Contact AG or CN engineers for checking the setting of the AG route.

Solution

Contact AG or CN engineers for modifying the setting of the AG route.

Typical Case

**********************************************************************

The HSDPA multi-thread download rate of Chile's Movistar fails to reach the theoretically maximum value.

In Movistar’s lab, the HSDPA download rate does not exceed 4.8 Mbit/s. Upon the check, it is found that the SNs of the GTPU packets from the AG to the SGW are discontinuous. AG engineers find that the route from the AG to the SGW is incorrectly configured. Instead, the route from the AG to the IP address of the AHR is configured. As a result, the data packets on the service plane are forwarded to the SGW through the AHR, thereby causing packet loss and affecting the peak rate.

***********************************************************************


The AG MTU is set to an improper value, thereby causing a low single-thread download date.


Capture packets at the entrance of the AP and check whether fragmentation occurs.



Figure a.1 Fragmentation

Solution

Upgrade the AP to UAP2105R11C01 or ePico3801R11C01 to solve the outer fragmentation problem, and change the AG MTU to 1500 to avoid outer fragmentation.

Typical Case

**********************************************************************

Inner fragmentation affects service experience.

Change the AG MTU to a value smaller than 1430 to ensure that the encrypted packets arriving at the SeGW from the AG are still smaller than 1500 bytes. The AG fragments the packets from the PS CN, and therefore the AG performance is affected. As a result, the AG discards packets, thereby affecting service experience, for example, slow Internet access, failure to open Web pages, and low single-thread download rate.

***********************************************************************

**********************************************************************

Outer fragmentation causes Internet access failure to users.

Change the AG MTU to 1500 to ensure that packets are not fragmented by the AG for minimizing the impacts on the AG (the AG still fragments too long UDP packets). The SeGW fragments a packet and combines an ESP packet and an IP packet for transmission on the public network. Certain network devices do not support such fragment reassembling and discard fragment packets, and therefore users fail to access the Internet. ***********************************************************************




The transmission bandwidth is limited.


Directly connect a PC to the Internet and test the actual transmission bandwidth through the FTP-based multi-thread download or professional rate test website. If the transmission bandwidth is limited, the HSDPA data transmission rate will fail to reach the theoretically maximum value.

Solution

If the bandwidth is insufficient, coordinate customer’s engineers to ensure sufficient bandwidth.

Typical Case

None




CDT of the AP (turn on the L1/L2 statistics switch) Mandatory

Traced cell SNR and RSCP Mandatory

Packets captured on the UE side Mandatory

AG/AP configuration file Mandatory

Packets captured on the AG side Optional



5.3 Failure to Set Up the HSUPA Service

5.3.1 Problem DescriptionThe upload is not based on the UPA channel, thereby causing a low upload rate.





The HSUPA cell is not activated.


Log in to the APM and check the radio parameters of the AP.

Figure a.1 Checking whether the HSUPA cell is activated

If the status of the HSUPA cell is DEACTIVE, the UPA cell is not activated, and therefore the uplink UPA service is not supported.

Solution

Activate the HSUPA cell on the APM. That is, set X_0D1F7B_HsupaEnable to true.

Typical Case

None


Check whether the UE supports the HSUPA function.


Observe UE capabilities from the RRC_CONNECT_REQ message initiated by the UE. If the UE does not support the UPA, the HSUPA service fails to be set up.



Figure a.2 UE capability reporting

As shown in the preceding figure, the ueCapabilityIndication IE indicates UE capabilities. If the IE contains "edch," the UE supports the HSUPA function.

Solution

Use a UE that supports the HSUPA function for testing.

Typical Case

None


The rate assigned by the CN is lower than the rate threshold for setting up the HSUPA service.


Different services have different E-DCH bearer thresholds. A service can be carried on the HSUPA only when the rate assigned by the CN exceeds the threshold. For the AP, the E-DCH bearer threshold is 256 kbit/s for uplink stream services, 64 kbit/s for uplink session services, and 608 kbit/s for uplink BE services.

To confirm the rate assigned by the CN, check the RANAP_RAB_ASSIGNMENT_REQUSET message on the Iu interface. You can obtain the service type, MBR, and uplink rate (1.4 Mbit/s) assigned by the CN.



Figure a.3 Service rate assigned by the CN

Solution

If the rate assigned by the CN is lower than the E-DCH bearer threshold of the AP, first check whether the subscription data of the SIM card on the HLR is properly configured. If the upload rate in the subscription data is higher than the E-DCH bearer threshold of the AP, check whether the AT command is used to restrict the uplink rate of the UE during dialup.

Typical Case

None





Uplink RTWP Mandatory

Number of users served by a dedicated channel Mandatory

Uplink CE resources Mandatory







5.4 Unstable Data Transmission in the HSUPA Service

5.4.1 Problem DescriptionThe data transmission rate in the HSUPA service fluctuates greatly.

Figure a.1 Unstable upload rate in the HSUPA service



The air interface quality is poor.


On the LMT, log in to the AP and observe the uplink RTWP.



In general, the RTWP is about -90 dBm in the case of no load and ranges from -850 dBm to -800 dBm in a service. If the RTWP is higher than -800 dBm, the uplink rate is affected.

Solution

− Change the position of the AP, and then observe whether the uplink RTWP is normal.

− Modify the frequency and scrambling code of the AP, and then observe the uplink RTWP.

− Disable HSUPA scheduling, and then observe the uplink rate.

Typical Case

*****************************************************************

The RTWP is normal in the case of no load and is overloaded after a service is performed.

The RTWP of the AP is normal in the case of no load. After the UE initiates a service, however, the RTWP increases abnormally until it is overloaded, and the service rate fluctuates violently. Adjust the position of the UE. Then the RTWP returns to normal and the service rate is stable. This case usually occurs when the power control of the UE is abnormal due to the unreasonable distance between the UE and the AP or unreasonable environment.

*****************************************************************


Packet loss occurs on the transport network.




Press Ctrl+Shift+F12, and then type lmtadmin to enable internal tracing, as shown in the following figure.

Enable the two-way tracing between the L2_MACC and the NBM.

Observe whether the uplink congestion indication (ULCONGESTION_IND) exists.

Solution

Contact customer’s engineers for checking network problems.

Typical Case

None














5.5 Low Data Transmission Rate in the HSUPA Service

5.5.1 Problem DescriptionThe data transmission rate is low but stable in the HSUPA service.

Figure a.1 Low upload rate in the HSUPA service





The AT command is used to limit the rate.


Check the advanced options in the modem driver of the data card to see whether the rate is limited by running the AT command.

Solution

Run the AT command to disable rate limitation.

Typical Case

None


The power of the UE is limited. Uplink path loss occurs due to environment. As a result, the UE uses the maximum transmit power in sending data, causing the failure to increase the upload rate.


Enable tracing on the LMT.

Figure a.1 Tracing the transmit power of the UE

The configured maximum transmit power of the UE on the AP is: pilot transmit power + 5 dBm. As shown in the preceding figure, the unit in the tracing result is dBm. Check whether the measured value is equal to the maximum transmit power of the UE.



Solution

If the transmit power of the UE is close to the maximum transmit power, move the UE to a proper position according to the field environment (ensure that the RSCP exceeds -90 dBm).

Typical Case

None


The rate assigned by the CN is lower than the theoretically maximum rate of the HSUPA service.


To confirm the rate assigned by the CN, check the RANAP_RAB_ASSIGNMENT_REQUSET message on the Iu interface. You can obtain the service type, MBR, and uplink rate (1.4 Mbit/s) assigned by the CN.

Figure a.2 Service rate assigned by the CN

Solution

If the rate assigned by the CN is lower than the E-DCH bearer threshold of the AP, first check whether the subscription data of the SIM card on the HLR is properly configured. If the upload rate in the subscription data is higher than the E-DCH bearer threshold of the AP, check whether the AT command is used to restrict the uplink rate of the UE during dialup.

Typical Case

None














6 Problems Related to Automatic Power

Adjustment

6.1 Call-Based Automatic Pilot Adjustment of the AP

6.1.1 Problem DescriptionThe UE calls the automatic pilot adjustment number, but the AP does not adjust the pilot power.



The power auto-configuration switches are not turned on.




Check whether the power auto-configuration switches are turned on. Log in to the APM, access the AP configuration page, and then check whether the status of the power auto-configuration switches (that is, the values of MaxFAPTxPowerSelfConfigEnable, PCPICHPowerSelfConfigEnable, and MaxULTxPowerSelfConfigEnable) under Device.Services.FAPService.{i}.FAPControl.UMTS.SelfConfig. If the value is true, the corresponding switch is turned on; if the value is false, the switch is turned off.

Solution

Turn on the power auto-configuration switches.

That is, set MaxFAPTxPowerSelfConfigEnable, PCPICHPowerSelfConfigEnable, and MaxULTxPowerSelfConfigEnable to true respectively.

Typical Case

None




The call-based automatic pilot switch is off.


Check whether the call-based automatic pilot switch is on. Log in to the APM, access the AP configuration page, and then check whether the automatic pilot switch is on or off under Device.Services.FAPService.{i}.X_0D1F7B_FeatureControl.PowerSelfConfig.

Solution

Set BaseOnCallSwitch to on.

Typical Case

None


The call-based automatic pilot call number is not set.


Check whether the automatic pilot call number is set. Log in to the APM, access the AP configuration page, and then check whether the call number is the same as the number displayed in the following figure under Device.Services.FAPService.{i}.X_0D1F7B_FeatureControl.PowerSelfConfig.BaseOnCall.



Solution

Correctly set the automatic pilot call number to ensure that the call number is the same as the configured number.

Typical Case

None


The UE calls the pilot adjustment number. After the call is released, other services still exist in the cell.


None

Solution

On the LMT, choose Realtime Performance Monitoring > Cell performance monitoring and ensure that all the values under 1-1 to 1-6 columns are 0, as shown in the following figure.



Typical Case

None


The automatic pilot adjustment number is called, but the call duration is shorter than the configured measurement duration.


None

Solution

Log in to the APM, access the AP configuration page, and then ensure that the call duration is longer than the time enclosed by a red box (configurable, 15s by default) under Device.Services.FAPService.{i}.X_0D1F7B_FeatureControl.PowerSelfConfig.BaseOnCall, as shown in the following figure.

Typical Case

None



CDT of the AP Mandatory


Uu interface tracing information about the AP Optional



6.2 Statistics-Based Automatic Pilot Adjustment of the AP

6.2.1 Problem DescriptionThe AP does not support statistics-based automatic pilot adjustment.



The power auto-configuration switches are not turned on.


Check whether the power auto-configuration switches are turned on. Log in to the APM, access the AP configuration page, and then check whether the status of the power auto-configuration switches (that is, the values of MaxFAPTxPowerSelfConfigEnable, PCPICHPowerSelfConfigEnable, and MaxULTxPowerSelfConfigEnable) under Device.Services.FAPService.{i}.FAPControl.UMTS.SelfConfig. If the value is true, the corresponding switch is turned on; if the value is false, the switch is turned off.

Solution

Turn on the power auto-configuration switches.

That is, set MaxFAPTxPowerSelfConfigEnable, PCPICHPowerSelfConfigEnable, and MaxULTxPowerSelfConfigEnable to true respectively.



Typical Case

None


The statistics-based automatic pilot switch is off.


Check whether the statistics-based automatic pilot switch is on. Log in to the APM, access the AP configuration page, and then check whether the automatic pilot switch is on or off under Device.Services.FAPService.{i}.X_0D1F7B_FeatureControl.PowerSelfConfig.

Solution

Set BaseOnStatSwitch to on.

Typical Case



None


Within the statistics-based adjustment cycle, the call-based automatic pilot switch is on and the call-based power adjustment is performed.


Check whether the call-based automatic pilot switch is on. Log in to the APM, access the AP configuration page, and then check the settings under Device.Services.FAPService.{i}.X_0D1F7B_FeatureControl.PowerSelfConfig.

Make sure that the CS calls the call-based automatic pilot adjustment number during the test on statistics-based automatic pilot adjustment.

Solution

If the call-based automatic pilot switch is on and the CS calls the call-based automatic pilot adjustment number, set BaseOnCallSwitch to off or do not dial the call-based automatic pilot adjustment number.

Typical Case

None


The statistics duration is insufficient when the service is released.


Check the cycle of the statistics-based automatic pilot adjustment. Log in to the APM, access the AP configuration page, and then check the settings under Device.Services.FAPService.{i}.X_0D1F7B_FeatureControl.PowerSelfConfig.BaseOnStat.



Solution

The statistics duration must be longer than the adjustment cycle (value of AdjustCycle) shown in the preceding figure. The adjustment cycle is configurable but must not be shorter than one hour.

Typical Case

None



CDT of the AP Mandatory


Uu interface tracing information about the AP Optional

AP running log Optional



7 Transmission Faults

7.1 Typical Methods of Locating Transmission and Power-on Faults in R12

Great changes are made to the transmission state machine in R12 and codes are basically rewritten. Therefore, this section describes how to locate the fault that the power-on time of the AP is occasionally too long to provide the basic methods of locating transmission and power-on faults in R12. The fault is not complex and is just for your reference.

7.1.1 Problem DescriptionIn R12ePico3801v200R012ENGC100B900, the power-on time of the AP is occasionally too long. It sometimes takes eight to nine minutes but sometimes three to four minutes to power on the AP. The test results show that the probability of this fault is about 25%.

7.1.2 Cause Analysis and Solution Location and Analysis

The fault recurs. The common procedure for locating power-on faults in R12 is as follows:

a. Diagnose and locate the fault.

The diagnosis method is as follows:

Fault diagnosis is to display the current transmission status and fault in real time.



Therefore, the diagnosis result sometimes displays that the AP is running. You can attempt to perform fault diagnosis repeatedly. If the fault process is started, the fault can be diagnosed through one attempt. When the serial port cannot be used, fault diagnosis is preferred to narrow the location scope.

The diagnosis result for this fault is "Registering with Serving HMS Timeout", indicating that the TR069 connection between the AP and the SHMS times out.

b. Use the serial port commands for location.

− Run TCM_Show to view the switching of the transmission state machine.

Run TCM_Show on the serial port to view the switching of the transmission state machine. The command is the key command for locating power-on faults.

-> TCM_Show

value = 0 = 0x0

->

TIME CNT STATE EVENT

-------------- --- -------------------- --------------------

12-10 16:59:52 1 DISCOVERING SHMS_INFO_UPDATE

12-10 16:59:52 1 DISCOVERING NULL

12-10 16:59:52 1 DISCOVER_WAIT_HMS_IP INIT_HMS_IP_SUCCESS

12-10 16:59:52 1 DISCOVER_WAIT_HMS_IP NULL

12-10 16:59:52 1 DISCOVER_NCELL_SEARCHING NULL

12-10 16:59:52 1 INIT_TUNNEL_BUILT NULL

12-10 16:59:52 1 INIT_TUNNEL_WAIT_CONFIG NULL

12-10 16:59:52 1 INIT_TUNNEL_WAIT_DNS INIT_SEGW_DNS_OK

12-10 16:59:52 1 INIT_TUNNEL_WAIT_DNS NULL

12-10 16:59:52 1 INIT_TUNNEL_BUILDING NULL

12-10 16:59:53 1 HMS_REGISTING TIMEOUT

12-10 16:56:50 1 HMS_REGISTING NULL

12-10 16:56:50 1 HMS_WAITTING_DNS SERV_HMS_DNS_OK

12-10 16:56:50 1 HMS_WAITTING_DNS NULL

12-10 16:56:50 1 NCELL_SEARCHING NULL

12-10 16:56:50 1 SERV_TUNNEL_BUILT NULL

12-10 16:56:50 1 SERV_TUNNEL_WAIT_CONNECT SIG_TUNNEL_UP

12-10 16:56:45 1 SERV_TUNNEL_WAIT_CONNECT NULL

12-10 16:56:44 1 SERV_TUNNEL_WAIT_CONFIG NULL

12-10 16:56:44 1 SERV_TUNNEL_WAIT_DNS SERV_SEGW_DNS_OK

12-10 16:56:44 1 SERV_TUNNEL_WAIT_DNS NULL

12-10 16:56:44 1 SERV_TUNNEL_BUILDING NULL

12-10 16:56:44 1 WAIT_DISCOVER_RESULT DISCOVER_WAIT_SUCCESS

12-10 16:56:44 1 WAIT_DISCOVER_RESULT NET_NODE_INFO_UPDATE

12-10 16:56:43 1 WAIT_DISCOVER_RESULT GATEWAY_INFO_UPDATE

12-10 16:56:43 1 WAIT_DISCOVER_RESULT TUNNEL_PARA_CHANGED

12-10 16:56:42 1 WAIT_DISCOVER_RESULT NULL

12-10 16:56:42 1 DISCOVERING DISCOVER_INFORM_SUCCESS

12-10 16:56:40 1 DISCOVERING SHMS_INFO_UPDATE

12-10 16:56:40 1 DISCOVERING NULL

12-10 16:56:40 1 DISCOVER_WAIT_HMS_IP INIT_HMS_IP_SUCCESS

12-10 16:56:40 1 DISCOVER_WAIT_HMS_IP NULL

12-10 16:56:40 1 DISCOVER_NCELL_SEARCHING NULL

12-10 16:56:40 1 INIT_TUNNEL_BUILT NULL

12-10 16:56:40 1 INIT_TUNNEL_WAIT_CONFIG NULL

12-10 16:56:40 1 INIT_TUNNEL_WAIT_DNS INIT_SEGW_DNS_OK

12-10 16:56:40 1 INIT_TUNNEL_WAIT_DNS NULL

12-10 16:56:40 1 INIT_TUNNEL_BUILDING NULL

12-10 16:56:40 1 HMS_REGISTING TIMEOUT



12-10 16:53:31 1 HMS_REGISTING NULL

12-10 16:53:31 1 HMS_WAITTING_DNS SERV_HMS_DNS_OK

12-10 16:53:31 1 HMS_WAITTING_DNS NULL

12-10 16:53:31 1 NCELL_SEARCHING NULL

12-10 16:53:31 1 SERV_TUNNEL_BUILT NULL

12-10 16:53:31 1 SERV_TUNNEL_WAIT_CONNECT SIG_TUNNEL_UP

12-10 16:53:24 1 SERV_TUNNEL_WAIT_CONNECT NULL

12-10 16:53:24 1 SERV_TUNNEL_WAIT_CONFIG NULL

12-10 16:53:24 1 SERV_TUNNEL_WAIT_DNS SERV_SEGW_DNS_OK

12-10 16:53:24 1 SERV_TUNNEL_WAIT_DNS SCTP_LINK_DOWN

12-10 16:53:24 1 SERV_TUNNEL_WAIT_DNS DISCOVER_WAIT_SUCCESS

12-10 16:53:24 1 SERV_TUNNEL_WAIT_DNS NET_NODE_INFO_UPDATE

12-10 16:53:24 1 SERV_TUNNEL_WAIT_DNS NULL

12-10 16:53:24 1 SERV_TUNNEL_BUILDING NULL

12-10 16:53:24 1 BASE_INFO_GOTTEN NULL

12-10 16:53:24 1 RUN TUNNEL_PARA_CHANGED

12-10 16:48:57 1 RUN NULL

12-10 16:48:57 1 HNBGW_REGISTING HNBGW_RSP_OK

12-10 16:48:57 1 HNBGW_REGISTING NULL

12-10 16:48:57 1 SCTP_BUILT NULL

12-10 16:48:57 1 SCTP_BUILDING SCTP_LINK_UP

12-10 16:48:51 2 SCTP_BUILDING TIMEOUT

12-10 16:48:46 1 SCTP_BUILDING NULL

12-10 16:48:46 1 HMS_REGISTED NULL

12-10 16:48:46 1 HMS_WAIT_ADMIN_STATE ADMIN_STATE_TRUE

The method of checking the state machine is as follows:

The preceding information displays the latest status switching tracks in the current transmission. You need to view them by time from up to down. Where, TIME indicates the time of triggering status switching by the event in the current status; CNT indicates the times of being in the current status; STATE indicates the current status; EVENT indicates the event that triggers status transition; NULL under EVENT indicates that the state machine performs status switching actively and no trigger event is required.

The preceding switching tracks of the state machine show that two TIMEOUT events occur in the HMS_REGISTING state. After timeout, the discovery process is triggered again. The timeout time is three minutes. Therefore, two timeout events take six minutes, thereby increasing the power-on time of the AP. The result is consistent with the fault diagnosis result. Next, check whether the IP address of the SHMS is correct.

The basic idea of locating power-on faults is to run TCM_Show to display the switching of the state machine during the transmission. You can obtain the trigger information about field problems according to the displayed trigger events and switching tracks of the state machine. In addition, locate the fault further according to the configuration and log information about the current AP and related NEs or captured packets.

− Run TCM_ShowFile to view the current information about the AP.

Run TCM_ShowFile on the serial port to view the current information about the AP.

-> TCM_ShowFile

value = 0 = 0x0

->

**************************************************************

Hnbid : 460150000001920 IMSI

number



Usim Type (0:SIM, 1:USIM, 2:Unkown, 3:None): 1 Card

type

blAlreadyDiscovery (0:False, 1:True):1 Whether

to start the discovery process

blAlreadyRegister (0:False, 1:True):1 Whether

to start the registration process

ucMacroCoverage:1 Whether to forcibly scan

neighboring macro cells

ulInitHmsSucType (0:INNER_DNS_TYPE, 1:TR069_TYPE):0

SIM INIT_SGW URL : INIT SGW information

saved in the SIM card

SIM INIT_HMS URL : INIT HMS information

saved in the SIM card

Inner_DNS or INIT_HMS IP NUM:1

Inner_DNS or INIT_HMS IPAddr:0xb9163d51

INIT_HMS IP INDEX:0 Index for the inner DNS to resolve the IP address

of the INIT HMS

USING INIT_HMS URL : URL of the INIT HMS

that is being used

Sctp Src Port: 2907 Port number of the SCTP link

on the AP

Sctp Dst Port : 2907 Port number

of the SCTP link on the AG

Admin State (0:FALSE, 1:TRUE) : Administration status

TCM_WITHOUT_TUNNEL (0:with, 1:without) : 0 Whether

to skip the tunnel

TCM_WITHOUT_SIM (0:with, 1:without) : 0 Whether

to skip the SIM card

TCM_WITHOUT_NEIGBOR (0:with, 1:without) : 0 Whether to

skip neighboring cell search

TCM_WITHOUT_DISCOVERY(0:with, 1:without) : 0 Whether

to skip the discovery process

TCM_WITHOUT_HMSAUTH (0:with, 1:without) : 0 Whether

to skip the registration process

Inner_DNS or INIT_HMS IPAddr indicates the IP address of the INIT HMS that is currently used. The result of the TCM_ShowFile command does not contain the IP address of the SHMS (the IP address needs to be provided subsequently). On the AHR, however, you can know that the IP address of the SHMS is 185.22.61.81. The IP address of the SHMS is not displayed after you run TCM_ShowFile. Therefore, this part just describes how to obtain the AP information, irrelevant to fault location.

− Run TSP_Ping to test link status.

It is suspected that the registration may fail due to poor network quality. Run TSP_Ping to test whether the link between the AP and the SHMS is normal. Different from the TSP_Ping command in R11, the TSP_Ping command in R12 is as follows:

TSP_Ping "destination IP", "inner IP address of the tunnel"

The inner IP address of the tunnel is optional and is unnecessary if the tunnel is not involved. The test results show that the ping operation from the inner IP address of the tunnel is successful, that is, the link between the AP and the SHMS is normal.

c. Locate the fault according to the printed information on the serial port.

Next, analyze the printed information on the serial port. It is found that a key error is printed: [TCM_FillHmsRegReq]err: Get Om Service tunnel address failed!. The printed information indicates that the AP does not obtain the inner IP address of the



maintenance tunnel of the OM. Log in to the AHR and find that the domain group of the AP is configured with two logic tunnels. The code shows that the AP first determines whether the IP address of the maintenance tunnel of the OM is obtained in the TCM_STATE_HMS_REGISTING state. If the maintenance tunnel fails to be set up, the AP directly returns and no longer sends messages to the OM to notify the OM of registering with the SHMS. As a result, the registration with the SHMS times out. After the timeout duration (three minutes), the discovery process is initiated again. In the case of two logic tunnels, the second maintenance tunnel of the OM is set up later than the primary tunnel. The second maintenance tunnel of the OM can be set up only after the primary tunnel is successfully set up. As a result, the time sequence problem exists. For example, the maintenance tunnel of the OM may have been set up when the transmission state machine enters the TCM_STATE_HMS_REGISTING state. In this case, a message may be sent to the OM immediately for the registration with the SHMS, which is a normal process. If the maintenance tunnel of the OM is not set up, timeout occurs, and therefore the discovery process is initiated again. As a result, the power-on time of the AP is too long. The result of the TCM_Show command shows that the maintenance tunnel of the OM is not set up when the transmission state machine enters the TCM_STATE_HMS_REGISTING state for the second time, thereby causing timeout again. The maintenance tunnel of the OM is successfully set up only when the transmission state machine enters the TCM_STATE_HMS_REGISTING state for the third time.

Up to now, in the case of two logic tunnels, the cause for the too long power-on time of the AP is that the time sequence is uncertain when the second maintenance tunnel of the OM is successfully set up. When only a single physical tunnel is available, this fault does not occur.

Solution

To register with the SHMS, The AP queries whether the maintenance address of the OM is obtained. If the maintenance address is not obtained, the AP starts a 5s timer. When the timer expires, the AP queries whether the maintenance address is successfully obtained and sends a message to the OM for starting the registration process only when the maintenance address is successfully obtained. That is, by performing query repeatedly based on the 5s timer instead of starting the discovery process after the three-minute timer expires, the AP can know the successful setup of the maintenance tunnel of the OM in time, thereby effectively shortening the power-on time.



8 HGW Faults



8.1 QoS Issues

8.1.1 Fault Description

UEs camping on the AP cell experience the issue of low-quality speech or video services.

When a UE implements CS services in the AP cell, the PC connected to the AP experiences the issue of low-

quality online videos.

8.1.2 Required Information

Iu-interface and Uu-interface message tracing result of the AP. Layer-2 Call Detail Trace (CDT) result.

Layer-2 MACC-NBM internal message tracing result

Ping delay from the AP Manager or SeGW to the AP

Blinking status of the 3G Link LED

8.1.3 Fault LocatingI. Fault Locating

Step1:

Observe the 3G Link LED. If the LED is green, it indicates that the network conditions are good and there is no traffic congestion. In this case, locate the fault by referring to the relevant instructions of the dual-port AP or the ePico. If the LED is yellow, there is traffic congestion. Proceed to step 2.

Step2:

Check the internal message tracing of layer-2 MACC-NBM (uplink congestion message type: 0x2d and downlink congestion message type: 0x2f). If the congestion message persists, it indicates that the network conditions are poor. In this case, check the ping delay from the AP Manager or SeGW to the AP. If the ping delay is larger than 100 ms and the packet loss rate is larger than 3%, rectify the network fault.

Step3:

When the Internet speed slows down for LAN users or Wi-Fi users, check for traffic congestion. Use the Telnet to log in to the home gateway (HGW). Check the port bandwidth in use (relevant command: cat var/linkrate). If the uplink bandwidth is limited to 64 kbit/s, appropriately raise the value of PC Uplink guarantee bit rate on the WebUI. See the following figure.



8.2 Issues Related to Wi-Fi Distributed System


Local Area Network (LAN) users fail to access the Internet.


Network structure

Configurations of Wi-Fi Distributed System (WDS) on the HGW console

Wi-Fi configurations on the HGW console

8.2.3 Fault LocatingI. Background

Mobile network

↓ Wi-Fi channel

UAP2855#2 → …… →UAP2855#1(192.168.1.1, dhcp transparent transmission)

(192.168.1.2, dhcp server) ↓ftp service

a: Wi-Fi data card

b: lan interface

The following figure shows an example:

II. Fault Locating

Step1:

Check the configurations of channel, encryption mode, and password of UAP2855#1 and UAP2855#2. SSID can be different between UAP2855#1 and UAP2855#2, but the preceding three parameters must be identical between them.

Step2:

Check whether UAP2855#1 is operating in Bridge mode. To provide Internet services for the connected PCs, UAP2855#1 has to operate in Repeater or Lazy mode.

Step3:

Choose Advanced > WLAN > WLAN WDS and then check whether the MAC Address parameter of



UAP2855#1 and UAP2855#2 is correctly set. The MAC address of UAP2855 can be obtained in the status column of the HGW console.

The maintenance IP address of UAP2855#1 must be different from that of UAP2855#2. Their DHCP servers cannot be enabled at the same time.

8.3 Diagnosing Network Congestion Through the Port Mirror Function


The 3G Link LED is blinking yellow.


Packet capturing result over the WAN port

Packet capturing result over the UAP port (Lan5 port)


Step1:

Log in to the HGW through a serial port or by using Telnet. The default user name and password for login are admin. Type the following command:

ATP>sh

>ethcmd eth0 mirror enable srcPort destPort (turn on the switch of the port mirror function)

Step2:

Capture packets over the destPort port. Focus on the ESP packets. Save the result and deliver it to the R&D personnel.

Step3:

Disable the port mirror function after data analysis, because this function affects the performance of data forwarding.

>ethcmd eth0 mirror disable

=====================================================

Detailed command explanation

The port mirror function is used to mirror data from a source port to a destination port, so that users can capture the data at the destination port for data analysis.

srcPort: Source port ranging from 0 to 5. Port 0 indicates the WAN port and Port 5 indicates the UAP port. Port 1 to Port 4 indicate four LAN ports.

dstPort: Destination port ranging from 1 to 4. They indicate four LAN ports.



=====================================================

8.4 Diagnosing Network Congestion Through Characteristic Packet Capturing


The 3G Link LED is blinking yellow.


Statistic result of characteristic packet capturing

8.4.3 Fault Locating

I. Fault Locating

Step1:

Log in to the HGW through a serial port or by using Telnet. The default user name and password for login are admin. Type the following command:

ATP>sh

> ethcmd eth0.x capture srcip IP

> ethcmd eth0.x capture dstip IP

To clear the statistic result, type the following command:

> ethcmd eth0.x capture cls or ethcmd eth0 capture cls

Step2:

To view the statistic result, type the following command:

> cat /proc/uap/pktcount

Step3:

Disable the characteristic packet capturing function after data analysis, because this function affects the performance of data forwarding.

>ethcmd eth0.x capture del or ethcmd eth0 capture del

=====================================================

Detailed command explanation

In characteristic packet capturing, all the received or transmitted packets on a port are filtered by the source IP address or destination IP address. Generally, packets are captured synchronously on the WAN port and LAN port, so that users can determine whether packet loss occurs inside the HGW.

IP: IP address of a packet

eth0.x: x ranging from 1 to 6. 1 indicates the WAN port and 6 indicates the UAP port. 2 to 5 indicate four LAN ports (LAN1 to LAN4).



cls: clear the statistics. If eth0.x is specified, only the statistics of the specified port is cleared. If eth0 is specified, the statistics of all ports are cleared.

del: If eth0.x is specified, only the statistic function of the specified port is disabled. If eth0 is specified, the statistic function of all ports is disabled.

Note: In character filtering, the source port IP address, destination port IP address, and direction (reception or transmission) are all independent filtering criteria.

=====================================================

8.5 Checking the System Breakdown Issue Through Logs


The HGW breaks down and then is reset automatically.


System breakdown logs


Step1:

Log in to the HGW through a serial port. Type the following command:

ATP>

> equipcmd lastword show

The information about stacks and important registers at the time of system breakdown is displayed. Save the information and deliver it to the R&D personnel.

======================================================

Note that a software upgrade will clear the system breakdown logs.

======================================================


Date post:	26-Nov-2023
Category:	Documents
Upload:	independent
View:	0 times
Download:	0 times

AP R12 Troubleshooting Guide

Documents