Analise de Problemas de Handover em WCDMA

Registro de Revisão Não Imprimir Esta
Página
Versão do Versão do Curso
Código de Curso WCDMA RF
Produto ISSUE
OWO300080 WCDMA RNO Versão 2,00
Programador/Modifi
Tempo Aprovador Nova/actualização
cador
Anjinfeng 2014-6-5 Jinyu Atualizar
Deng Chnenggang 2017-3 Suntan Atualizar
Marcio Tadeo 2019-01 Translate Portuguese
Copyright © 2017 Huawei Technologies Co., Ltd. All rights reserved. Page0
Análise de
Problemas de
Handover
(WCDMA)
www.huawei.com
Copyright © 2017 Huawei Technologies Co., Ltd. All rights reserved.

Conteúdo
1. Conceitos Básicos da Otimização Problemas de Handover
2. Análise de Problemas no Soft Handover
3. Análise de Problemas no Hard Handover
4. Análise de Problemas no Inter-RAT Handover
Fluxo de Otimização de Problemas de
Handover Network Information Collection and
Optimization Target Definition
Performance Statistic Collection
DT and Signaling Análise
Parameters Adjustment
Adjustment validation
N
Achieve Target ？
Y
End
Referência de desempenho de handover
Método Valor de
Index Serviço
Estatistico Referência
SHO success rate CS&PS DT&Stat. 99%
Voice DT&Stat. 90%
VP DT&Stat. 85%
Intra-f HHO success rate PS UL64K/DL 64K DT&Stat. 85%
PS UL64K/DL 144K DT&Stat. 80%
Voice DT&Stat. 92%
VP DT&Stat. 90%
Inter-f HHO success rate PS UL64K/DL 64K DT&Stat. 90%
Voice handover out DT&Stat. 95%
Inter-RAN HHO success rate
PS handover out DT&Stat. 92%
SHO ratio N/A DT 35%
SHO cost N/A Stat. 40%
Conteúdo
Conteúdo
2.1 Fluxo de Otimização de SHO DT
2.2 Fluxo de Otimização de Estatísticas de Desempenho em

SHO
2.3 Análise de Problemas em SHO
2.4 Casos de Problemas em SHO
Fluxo de Otimização de SHO DT
(Cont.)
1. Inserindo Dados de Análise
 Executar o DT. Coletar dados no DT, rastreamento de
sinalização relacionada, RNC CHR e scripts RNC MML
2. Obtendo quando e onde o problema ocorre

 Durante o teste, a queda de chamada causada por SHO
pode ocorrer ou o SHO pode falhar, portanto, registre a
localização e a hora da ocorrência do problema. Isso
prepara para maior localização e análise
(Cont.)
3. Célula Vizinhada Ausente
 Durante a otimização inicial, a queda de chamada é
geralmente devido à falta de células vizinhas. Para células
vizinhas intra-frequência, use os seguintes métodos para
confirmar a célula vizinha ausente
(Cont.)
4. Poluição Piloto
 A poluição piloto é definida como abaixo :
 Pilotos fortes e excessivos existem em um ponto, mas ninguém é
forte o suficiente para ser dominante
 “Piloto forte” é definido pelo RSCP. E se CPICH_ RSCP ThRSCP_ Absolute ,

esse piloto é um piloto forte
 "Excessivo" é definido pelo número do piloto. Se, CPICH_ Number ThN

os pilotos em um ponto são excessivos
 “Ninguém é forte o suficiente para ser dominante” significa

(CPICH _ RSCP1st  CPICH _ RSCP(ThN 1) th )  ThRSCP _ Re lative
(Cont.)
5. Configuração Incorreta dos Parâmetros do Algoritmo
SHO
 Handover Atrasado
 De acordo com o fluxo de sinalização, o UE reporta o relatório
de medição 1a ou 1c de células vizinhas antes da eliminação
de chamadas. Depois disso, a RNC recebe o evento e envia a
mensagem de atualização do conjunto ativo, que o UE não
recebe
 Ping-pong handover
 O melhor servidor muda frequentemente ou não existe célula-
piloto primária
(Cont.)
6. Equipamentos anormais
 Verifique o console de alarme quanto a alarmes anormais.
Enquanto isso, analise a mensagem rastreada, localize o
problema do SHO verificando a mensagem de falha. Para obter
ajuda, entre em contato com os engenheiros locais de
atendimento ao cliente para confirmar equipamentos anormais
7. Repetindo o teste de unidade e localizando problemas

 Se o problema não for causado por causas anteriores, execute
o DT novamente e colete os dados. Suplementar dados da
análise de problemas
(Cont.)
8. Ajuste e Implementação
 Para problemas de handover causados pela poluição do piloto: a principal
solução é ajustar a antena e o sistema de alimentação
 Para queda de chamada causada por handover atrasado: ajuste as antenas e o

sistema de alimentação ou modifique os parâmetros de algoritmos de handover
 Para efeito de agulha (needle) ou efeito de virar a esquina (turning corner): A

principal solução é modificar os parâmetros de algoritmos de handover
 Para queda de chamada causada pelo ping-pong handover: ajuste a antena e o

sistema de alimentação ou modifique os parâmetros de algoritmos de handover
 Para equipamentos anormais: cooperar com engenheiros de atendimento ao

cliente
Conteúdo
2.2 Fluxo de Otimização de Estatísticas de Desempenho de

SHO
2.3 Análise do Problemas de SHO
2.4 Casos de Problemas de SHO
Fluxo de Otimização de Estatísticas de
Desempenho do SHO
Índices de falha de SHO
Causas da Falha Análise
O UE pensa que o conteúdo da atualização do conjunto ativo para a RNC

Configuração não
adicionar/excluir links não suporta SHO. Este cenário raramente existe em
suportada
redes comerciais.
O UE responde que o SHO (ou softer handover) para a RNC

Reconfiguração de
adicionar/excluir links é incompatível com outros processos subsequentes.
sincronização não
A RNC garante o processamento serial no processamento de fluxo. Esta
suportada
causa é devida ao UE problemático.
O UE pensa que o conteúdo da atualização do conjunto ativo para a RNC

Configuração
para adicionar/excluir links é inválido. Este cenário raramente existe em
inválida
redes comerciais.
A RNC não recebe resposta ao comando "active set update" para

Sem resposta do adicionar/excluir links. Esta é uma das principais causas de falha de SHO
UE (ou softer handover). Ocorre em áreas com cobertura fraca e pequena área
de handover. A Otimização de RF deve ser realizada nas áreas.
Conteúdo

SHO
Análise de Problemas em SHO
 Alta porcentagem de soft handover
 Percentual de SHO deve ser mantido entre 30% ~ 40%
 As razões para a alta porcentagem de handover podem ser :
 Problemas de cobertura ~ overshoot
 Parâmetros impróprios
– Threshold para 1A, 1B
– CIO
 Método de planejamento inadequado

– Alto tráfego na área de soft handover
(Cont.)
 No Soft handover a taxa de sucesso é baixa:
 Se a taxa de sucesso de soft handover for menor que 98%,
pode ser definido que a taxa de sucesso da soft handover é
baixa
 As razões podem ser :

 Problema de cobertura
 Poluição Piloto
 Parâmetro impróprio
– 1A, 1B, 1C, 1D
– Time to trigger
– CIO
(Cont.)
 Queda de chamada no soft handover
 Problema de RF
 Problema de cobertura
 Poluição Piloto
 Célula vizinha ausente

 Parâmetros impróprios
 Limite para 1A e 1B
 “time-to-trigger”
 CIO
(Cont.)
 Desequilíbrio na cobertura de uplink e downlink
 A interferência externa e a poluição do piloto podem influenciar a
cobertura do uplink e do downlink planejados
Uplink
coverage
A B
Downlink
coverage
 A decisão de Soft handover é baseada na qualidade do canal CPICH

de downlink. Neste caso, a queda de chamada pode acontecer
porque o uplink está fora de sincronização
Conteúdo

SHO
Caso 1 SHO
 Descrição
 Dados de DT – Trace de sinalização
Queda de Após a queda da

chamada chamada, começa a
ler as informações do
sistema
Caso 1 SHO (Cont.)
 Análise de dados
 Verificar as informações da célula do conjunto ativo do UE e as
informações da célula do scanner nos pontos de queda da chamada.
vindo do UE Vindo do scanner
Nenhuma
célula SC
170 !! Por
quê?
Caso 1 SHO (Cont.)
Verifique o conjunto de
monitores para o
embaralhamento medido
pelo scanner
SC 170 não está no monitor

definido, então a causa
provavelmente é a falta de
célula vizinha
 Célula vizinha ausente
 Handover atrasado
Caso 1 SHO (Cont.)
 Verifique as últimas measurement control
Pesquise pela mais recente intra-

frequência measurement control
Ponto de
queda de
chamada
Caso 1 SHO (Cont.)
O ID de medição é 1. É Intra-
frequência measurement control
O primary scramble da
célula é 6
Verifique a lista da célula vizinha

intra-frequência no controle de
medição
Caso 1 SHO (Cont.)
 Solução
 Adicionar células vizinhas na lista de células vizinhas
Caso 1 SHO (Cont.)
 Se somente o UE grava informações durante o teste, sem
informações do scanner, confirme que a queda da chamada deve-se
à ausência da célula vizinha usando o seguinte método:
Após a queda da chamada, o UE
lê a informação do sistema
Verifique a célula onde o UE

acampa após a seleção e
reseleção de células
O UE acampa na célula do SC 170, que é inconsistente

com o piloto primário antes da queda de chamada, então a
queda de chamada é provavelmente devido a falta de
célula vizinha
Caso 2 SHO
 Descrição
 A figura a seguir mostra o ponto de poluição do piloto perto de Yuxing Rd.
 Célula SC270 é para cobrir a área de poluição do piloto
Aqui está a área de

poluição do piloto.
Esta área deve ser
coberta pelo código de
embaralhamento 270.
270
Caso 2 SHO (Cont.)
 A figura a seguir mostra a melhor célula de serviço perto de Yuxing Rd
A melhor célula
muda
freqüentemente
nessa área.
Caso 2 SHO (Cont.)
 A figura a seguir mostra a segunda melhor célula de serviço perto da Yuxing Rd
A segunda melhor
célula muda
freqüentemente
nessa área.
Caso 2 SHO (Cont.)
 Analisando a distribuição do sinal de células próximas ao ponto de poluição piloto
 A figura a seguir mostra a terceira melhor célula de serviço perto da Yuxing Rd
Caso 2 SHO (Cont.)
 A figura a seguir mostra a quarta melhor célula de serviço perto da Yuxing Rd
Caso 2 SHO (Cont.)
 Composição da poluição do piloto perto de Yuxing Rd
 Embora a célula SC270 esteja planejada para cobrir a área, a melhor célula de
serviço é a que está listada na tabela.
Melhor Célula de Serviço SC

1st Melhor Célula de Serviço SC220
2nd Melhor Célula de Serviço SC270
3rd Melhor Célula de Serviço SC260
4th Melhor Célula de Serviço SC200
Caso 2 SHO (Cont.)
 Analisando a distribuição de RSSI e RSCP perto do ponto de poluição piloto
 Como mostrado na figura à esquerda, o RSSI da área de poluição do piloto não é

grande, cerca de -100dBm a -90dBm
 Como mostrado na figura à direita, o RSCP da Melhor Célula de Serviço está entre
-105dBm a -100dBm
 A poluição piloto da área é causada por falta de piloto forte
Caso 2 SHO (Cont.)
 A figura a seguir mostra o RSCP da célula SC270 perto da Yuxing Rd
 A figura mostra RSCP da distribuição RSCP da célula SC270. Os sinais da

célula SC270 são fracos na área de poluição do piloto
Caso 2 SHO (Cont.)
 Solução
 Ajuste o azimute da célula SC270 de 150 ° a 130 ° e a inclinação
para baixo de 5 ° a 3 °. Isso aumenta a cobertura das células
SC270
 Confirme
 Após análise dos dados da DT, a área é dominada por SC 270. E a
poluição do piloto desaparece
Área de queda
Caso 3 SHO de chamada
 Descrição
 Várias
chamadas
falharam
durante a
otimização de
RF
 O lugar de
queda de
chamada é a
esquina
Caso 3 SHO (Cont.)
 De acordo com a figura seguinte, os sinais do scramble do conjunto
ativo 104 e 168 diminuíram para -17 dB antes da esquina. Mas a
célula SC208 é muito boa, cerca de -8 dB
Caso 3 SHO (Cont.)
 O trace de sinalização da RNC mostra que o UE reporta o evento 1A para o SC
208. Então, a RNC envia a atualização do conjunto ativo. Mas o UE não pode
recebê-lo
Caso 3 SHO (Cont.)
 Este é um caso típico de efeito de esquina, e a solução pode ser:
 Ajustar o parâmetro do evento 1A
 Diminuir o tempo para acionar
 Aumentar o limite
 Efeito colateral
 Adjust CIO
 Aumentar CIO da melhor célula
 Efeito colateral
 Otimização de RF
 Ajuste a antena para evitar a flutuação do sinal
Caso 3 de SHO (Cont.)
 Conclusão
 A partir do DT, o fenômeno típico para o efeito de esquina pode ser
mostrado como nesta figura
 O sinal da célula de origem diminui acentuadamente enquanto a célula

alvo aumenta acentuadamente. Portanto, a queda de chamada
acontece porque o UE não pode receber atualização do conjunto ativo
Caso 4 de SHO
 Efeito Needlepoint
 O fenômeno do efeito needlepoint
 Do procedimento de sinalização, um evento 1B acontece, então um evento
1A acontece
 Esta figura mostra o caractere de flutuação do sinal do efeito agulha
(needlepoint)
Needle point-signal variance
Caso 4 SHO(Cont.)
 Efeito Needlepoint e efeito esquina (corner)
 Efeito Needlepoint pode não causar queda de chamadas
 O efeito Needlepoint dura apenas um tempo muito curto, e essa duração
pode não ser suficiente para acionar o handover.
 Causa deterioração de QoS
 Efeito esquina causa queda de chamada

 Sinal de célula de origem não pode se recuperar
Caso 4 SHO (Cont.)
 O efeito de needlepoint causa queda de chamada nas seguintes
situações:
 Se needlepoint não puder satisfazer o handover
 Queda de chamada pode não acontecer, mas o QoS se deteriora, como alta BLER
 Alta BLER causa reset do TRB e, em seguida, queda de chamada
 Se needlepoint puder satisfazer o handover

 O sinal da célula de origem se deteriora, e o UE não pode receber a atualização do
conjunto ativo, então ocorre queda de chamada
 Segundao handover no needlepoint pode causar queda de chamada
Caso 4 SHO (Cont.)
 Solução
 Otimização de RF
 Evite que o sinal da célula de origem se deteriore
Caso 5 SHO
 Descrição
 Após a divisão das células, a taxa de queda de chamada aumentou
Caso 5 SHO (Cont.)
 Análise
 Verifique o alarme
 Verifique o registro de modificação de parâmetros
 Verificar sinalização
 Com base no Nastar, analise a célula vizinha
Caso 5 SHO (Cont.)
 Baseado na análise de célula vizinha, esta questão pode ser
causada por falta de células vizinhas
 Então o engenheiro verifica a configuração da célula vizinha, a

célula vizinha foi configurada, mas havia mais de 40 vizinhas
configuradas, a RAN14 suporta a configuração de até 63
vizinhas. Mas o 3GPP permite apenas 31 vizinhos na mensagem
de controle de medição. Portanto, alguns dos vizinhos
configurados não foram enviados para o UE
Caso 5 SHO (Cont.)
 Solução
 Adicione as prioridades dos vizinhos para garantir que os
vizinhos importantes possam ser enviados sempre
 Atividade o recurso "Addition of Detected Set Cells to the

Active Set", para que a célula vizinha não seja enviada pelo
controle de medição mas possa ser detectada pelo UE e
também possa ser adicionada no conjunto ativo
Caso 5 SHO (Cont.)
 Verificação
 Após o ajuste, a questão é resolvida
Conteúdo
Conteúdo
3.1 Fluxo de Otimização no HHO DT
3.2 Fluxo de Otimização de Estatísticas de Desempenho no HHO
3.3 Análise de Problemas em HHO
3.4 Casos de Problemas em HHO
Fluxo de Otimização no HHO DT
(Cont.)
 Problemas em HHO geralmente se referem ao atraso de
handover e handover Ping-pong:
 Para Delayed HHO, as seguintes soluções podem ser
adotadas
 Aumentar o limiar para iniciar o modo de compressão
 Aumentar o CIO de duas células inter-frequência
 Diminuir o limiar de disparo de handover de frequencia alvo da
cobertura inter-frequências
 Para resolver Ping-pong HHO, o método poderia ser

 Aumento da hysteresis HHO e atraso no tempo de
desencadeamento
(Cont.)
 A otimização de HHO intra-frequência é semelhante à da
inter-frequência:
 Diminuir a hysteresis e atrasar o tempo de desencadeamento
do evento 1D de acordo com o ambiente de rádio local para
garantir o handover em tempo.
Conteúdo
3.2 Fluxo de Otimização de Estatísticas de Desempenho no

HHO
Principais índices de falha HHO
Causas de falha Análise
Falha de preparação de HHO
Falha na configuração do link

Analisar falha na configuração de RL.
de rádio
Outras causas Analise o problema com base nos logs do CHR.
NodeB interna/entre NodeBs/entre falha de RNCs HHO
O UE pensa que não pode suportar o comando para o HHO de saída,

Configuração não-suportada
porque é incompatível com o HHO.
Falha do canal físico A causa é provavelmente uma cobertura fraca e uma forte interferência.
Reconfiguração da O UE alimenta HHO e é incompatível com outros processos

sincronização não-suportada consequentes devido a problemas de compatibilidade do UE.
Atualizar célula A atualização de células ocorre no HHO de saída.
O UE pensa que o comando para o HHO de saída é inválido. Este é um

Configuração inválida
problema de compatibilidade do UE.
Outras causas Analise o problema com base nos logs do CHR.
Conteúdo
Análise de Problemas em HHO
 Falha no modo de compressão
 Handover Inter-frequencia e handover inter-RAT
 Sem relatório de medição (2D) a partir do UE
– Limiar inadequado para o modo de compressão
 Sem reconfiguração do canal físico completo (Modo de

Compressão)
– Método do modo de compressão inadequado: SF/2 e agendamento
de camada superior
 Modo de compressão Ping-pong

– Parâmetros inadequados
– A diferença entre 2D e 2F é muito pequena
(Cont.)
 Nenhuma Reconfiguração do Canal Físico (Indicação HHO)
 Hard handover Inter-frequencia e hard handover inter-RAT
 Sem reconfiguração do canal físico (handover) ou Handover de
UTRAN para GSM
– Parâmetro impróprio
~ 2B, 2C
~ 3A, 3C
(Cont.)
 Nenhuma Reconfiguração do Canal Físico (Indicação HHO)
 O Hard handover Intra-frequencia é ativado pelo evento 1D
 Se o UE reporta evento 1D
– Verificar a “Comutação do algoritmo de hard handover intra-frequencia"
– Falha no link de configuração da interface Iur ou Iub
 Se não há relatório de evento 1D do UE

– Verificar lista de células vizinhas
– Parâmetro de evento 1D impróprio
– Verificar o SC na fonte RNC e RNC de destino
(Cont.)
 Falha ao receber a Reconfiguração do Canal Físico
 Parâmetros inadequados
 Limiar, hysteresis ou tempo-para-disparo (time-to-trigger)
 Aumentar a "potência máxima de transmissão de downlink"
 Falha ao receber a Reconfiguração do Canal Físico

Completo
 Melhorar a cobertura de uplink
 Diminuir a interferência do uplink
 Aumentar a "potência máxima de transmissão de uplink", se
possível
(Cont.)
 Handover Ping Pong
 Parâmetros de handover inadequados
 Aumentar o limiar de decisão de handover, mas precisa
considerar o efeito colateral
 Ajustar o ambiente de transmissão para diminuir a flutuação do

sinal
(Cont.)
 Outros problemas
 Capacidade do UE
 Por exemplo, alguns UEs não podem suportar hard handover
intra-frequencia
 Compatibilidade do equipamento
 Especialmente quando o hard handover precisa da corporação
entre diferentes elementos de rede de diferentes manufaturas
 Problema de transmissão
Conteúdo
Caso 1
 Descrição
 Quando o UE se move para uma célula inter-frequência, ele
falha no handover
 Acampa na célula inter-frequência após a desconexão
 Análise
 Analisando o procedimento de sinalização, isso aconteceu no
modo de compressão
 O UE não ativou o modo de compressão
 Verificar Measurement report
 O indicador de evento 2D e evento 2F é Ec/Io

Caso 1 (Cont.)
 O piloto Ec/Io depende de:
 Força de CPICH RSCP
 Interferência em Downlink
 A relação entre Ec/Io pode ser representada como figura a seguir:
RSCP
Ec/N0
Caso 1 (Cont.)
 Solução
 Alterar indicadores de relatórios de evento 2D e 2F para RSCP
 Confirmar
 Após o ajuste, o UE inicia o modo de compressão com sucesso
 Conclusão
 No centro da cobertura da portadora, os indicadores de relatórios de evento
2D e 2F são Ec/Io
 Na extremidade de cobertura da portadora, os indicadores de relatórios de
evento 2D e 2F são RSCP
Caso 2
 Descrição:
 A taxa de sucesso de handover inter-frequência da rede T 3G
(IFHO) foi menor do que a meta de 95%, precisa de
otimização para atingir o objetivo
 Como estratégia de camadas da rede T, o IFHO será acionado

por cobertura e carga (ação LDR)
Caso 2 (Cont.)
 Análise
 Tome um RNC PCHR para analisar a principal questão das
falhas de IFHO, podemos ver que a falha principal foi causada
por handover acionado por 1F(46,36%) e handover acionado
por má qualidade com base na cobertura (40,40%)
Caso 2 (Cont.)
 Análise
 Para o IFHO baseado em cobertura, o limiar de evento 2D usa a

configuração inter-sistema (3G-> 2G)
 Então verifique a configuração dos parâmetros atuais como

abaixo:
 InterRATCSThd2DRSCP/EcNo: -100/-20
 InterRATHThd2DRSCP/EcNo: -110/-22
 Uma vez que a estratégia de rede T era para evitar o handover

inter-sistemas e manter mais tráfego em 3G, então a configuração
atual do parâmetro foi agressiva para a IFHO, mas tem que manter
Caso 2 (Cont.)
 Para o evento 1F desencadeado por blind handover inter-
frequência, decompõe-se para o nível das células como abaixo,
nós podemos ver que não havia nenhuma TOP cell.
Caso 2 (Cont.)
 A partir do ponto de usuário, não houve nenhum usuário
principal que contribuisse com grandes falhas:
Caso 2 (Cont.)
 Verifique o Ec/No dos usuários, o Ec/No está ruim
(principalmente abaixo de -16dB):
Caso 2 (Cont.)
 Análise
 Para relatar o evento 1F, a melhor célula RSCP deve ser
melhor do que BlindHORSCP1FThreshold que estava
atualmente configurado em -115dBm, assim fica fácil relatar
evento 1F devido à estratégia de camadas para usar o limiar
inter-RAT 2D (muito inferior ao limiar Inter-Freq 2D)
 Uma vez que não é possível modificar o limiar 2D, para reduzir
ou evitar o handover cego, é necessário ajustar o parâmetro
BlindHORSCP1FThreshold a um valor mais alto
Parâmetros de Handover Inter-frequência
 BlindHORSCP1FThreshold
 Nome do parâmetro: Event 1F Blind Handover Trigger
Condition
 Valor recomendado: -115, nomeadamente -115dBm
Caso 2 (Cont.)
 Solução
 Modificar o parâmetro de evento 1F BlindHORSCP1FThreshold
de -115dBm para -70dBm para reduzir o handover cego. Depois
de implementado na rede, a taxa de sucesso da IFHO melhorou
de 93,46% para 95,11% (média diária) e alcançou o objetivo.
Caso 2 (Cont.)
 Conclusão
 No limite de cobertura, o handover inter-frequencia acontece
por causa da cobertura ruim e ocorre o handover de
emergência que é acionado por um evento 1F
 Mais blind handover foi desencadeado, o que trouxe baixa
taxa de sucesso de IFHO, devido à estratégia de camadas de
rede
 Melhorar o limiar para limitar a quantidade de IFHO, a fim de
reduzir falhas
Caso 3
 Descrição
 No País X projeto Y, existem muitas falhas de handover inter-
frequência quando o UE se move para uma praça S
 IBS foi implantado na praça S e também definimos relação

inter-frequência entre célula Macro e célula IBS
 A direção de HO definida é da célula macro(CI=46413) para a

célula IBS(CI=59802)
Célula de origem Célula vizinha
IC=46413,UARFCN=10173,PSC=296
Ci=59802,Uarfcn=10838,PSC=482
Caso 3 (Cont.)
 Análise
 Verifique o tracing de sinalização, não podemos encontrar a
célula IBS(CI=59803) no relatório de medição
Caso 3 (Cont.)
 CI=59802, UARFCN=10838,PSC=482 não pode ser
encontrado, mas UARFCN=10838,PSC=482, uma célula de
macro site continua aparecendo
Caso 3 (Cont.)
 A célula do site macro, UARFCN = 10838, PSC = 482, tem
uma cobertura ruim na praça, o que leva a falha de handover e
queda de chamada
 Por que a célula do IBS não pode ser encontrada no relatório

mesmo que os vizinhos já estejam configurados?
 Verifique a configuração vizinha da célula de origem como

mostra a tabela abaixo:
Célula de PSC
481 482 483 484 493
origem UTARFCN
10788 10381
46413, PSC =
10813 59811 59812 59813 59814 59833
296
10838 59801 59802 59803 59804 59823
Caso 3 (Cont.)
 Como mostra na tabela, 3 frequências vizinhas foram
configuradas para a célula de origem
 Verifique novamente a mensagem de controle de medição

inter- frequência
Caso 3 (Cont.)
 Como mostrado a seguinte: UARFCN 10788 e 10813 estão na mensagem
de controle de medição, mas UARFCN 10838 não está
Caso 3 (Cont.)
 Como a descrição do LMT, o número de frequências de
células vizinhas não excede dois
Caso 3 (Cont.)
 O número de células vizinhas da célula de origem,
CI=46413,UARFCN=10173,PSC=296, é configurado como 3,
quando a RNC envia as células vizinhas na mensagem de
controle de medição os UARFCNs 10788 e 10813 são
escolhidos aleatoriamente
 Célula IBS, CI=59802, UARFCN=10838,PSC=482 não podem

entrar na mensagem de controle de medição, porque o
handover para esta célula não pode acontecer
Caso 3 (Cont.)
 Soluções
 Excluir a relação de vizinhas entre a célula de origem e
cell10381, fazer com que o número de frequências de células
vizinhas não exceda dois
Caso 3 (Cont.)
 Conclusão
 Um UE pode medir no máximo duas frequências diferentes
que não a frequência de serviço simultaneamente.
Recomenda-se que o número de frequências de células
vizinhas em SIB11 não exceda dois. Ou seja, as células
vizinhas inter-frequência de uma célula não excedem dois
Conteúdo
1. Conceitos básicos de optimização Handover Problem
2. Análise Soft Handover Problem
Conteúdo
4.1 Fluxo de Otimização de Handover DT
4.2 Fluxo de Otimização de Estatísticas de Desempenho do

Handover Inter-RAT
4.3 Análise de Problemas de Handover inter-RAT
Fluxo de Otimização de Handover
DT
DT (Cont.)
 Handover Inter-RAT falha devido a dados de configuração
incompletos, por isso preste atenção à seguinte
configuração de dados:
 A configuração do vizinho GSM está completa na RNC
 Adicionar informações de célula da área de localização perto

de MSC 2G para a lista de células da área de localização de
MSC 3G
 Adicionar dados de células vizinhas WCDMA no GSM BSS
Fluxo de Otimização de Inter-RAT
Handover (Cont.)
 De acordo com as estratégias de handover unilateral de
inter-RAT handover, se a configuração dos dados estiver
completa, os problemas de inter-RAT handover devem-se
ao handover atrasado:
 Uma solução freqüentemente utilizada é aumentar o CIO,
aumentando o limiar para iniciar e parar o modo de
compressão, aumentando o limiar para handover ao GSM.
DT (Cont.)
 As causas para queda de chamada devido a handover inter-RAT 3G-2G
são como abaixo:
 Depois que a rede 2G modifica seus dados de configuração, ela não informa a
rede 3G de modificação, de modo que os dados configurados em duas redes
são inconsistentes
 A falta da célula vizinha causa queda de chamada
 Os sinais flutuam frequentemente, então a queda de chamada ocorre
 Problemas com o aparelho causam queda de chamada. Por exemplo, o UE

falha no handover de volta ou para reportar a medição inter-RAT
 Excessivas células inter-RAT são configuradas (resolva otimizando o número

de células vizinhas)
Conteúdo

Handover Inter-RAT
Principais índices de falha de Inter-RAT HHO
Falha na preparação de handover inter-RAT de nível RNC
Expiração da espera do O CN não responde ao comando correspondente para o pedido de preparação de handover, porque
comando de relocalização de a configuração do parâmetro CN ou a conexão do link correspondente é problemática. Para resolver
SRNS este problema, analisar as causas de acordo com o rastreio de sinalização CN e BSS.
Cancelamento de relocalização
Após a RNC solicitar a preparação de handover, ela recebe o comando de liberação do CN.
SRNS
Expiração da relocalização de Corresponde a configuração incorreta de CN, então você deve analisar as causas de acordo com o
SRNS rastreamento de sinalização do CN e BSS.
Falha na relocalização de SRNS Corresponde a configuração incorreta de CN ou BSS sem suporte, então você deve analisar as
no alvo CN/RNC/sistema causas de acordo com o rastreamento de sinalização CN e BSS.
Corresponde a configuração incorreta de parâmetros MSC sem informação como LAC da célula alvo,
Alvo desconhecido RNC então você deve verificar a configuração do parâmetro. Ocorre facilmente após o ajuste das redes
2G.
Corresponde a configuração incorreta de parâmetros MSC ou recursos BSC indisponíveis, então

Recurso indisponível
você deve analisar as causas de acordo com o rastreamento de sinalização CN e BSS.
Outras causas Analisar as causas de acordo com o rastreio de sinalização CN e BSS.
Principais índices de falha de Inter-RAT
HHO (Cont.)
Falha na preparação de handover inter-RAT de nível da célula
Expiração da relocalização de A configuração do parâmetro CN ou a conexão do link correspondente é problemática,

SRNS pelo que deve analisar as causas de acordo com o rastreio de sinalização CN e BSS.
Falha de relocalização de SRNS no Corresponde a configuração incorreta de CN ou BSS não suportada, então você deve
alvo CN/RNC/sistema analisar as causas de acordo com o rastreamento de sinalização CN e BSS.
Relocalização SRNS sem suporte A BSC não suporta alguns parâmetros de pedido de inter-RAT handover, então você
no alvo CN/RNC/sistema deve analisar as causas de acordo com o rastreamento de sinalização CN e BSS.
Outras causas Analisar as causas de acordo com o rastreio de sinalização CN e BSS.
Falha de handover de saída inter-RAT em nível de RNC / CELL
O UE não suporta o comando handover na rede, de modo que o UE é incompatível

Configuração Sem suporte
com o comando handover.
Falha do canal físico Os sinais 2G são fracos ou a interferência é forte, então o UE não se conecta à rede.
Analise o problem de acordo com os logs CHR e rastreamento de sinalização

Outras causas
CN/BSS.
Conteúdo

Handover Inter-RAT
Análise de Problema de Handover
Inter-RAT
 O conteúdo da Análise de Problema de Handover Inter-RAT
é semelhante ao da análise de problema de handover inter-f
 Devido ao handover inter-RAT envolver a cooperação de

equipamentos multi-rede, assim engenheiros no local
também precisam analisar as mensagens de sinalização CN
e GBSS para localizar problemas
Caso 1
 No operador X, a taxa de sucesso de handover IRAT
estava a diminuir lentamente
Caso 1 (Cont.)
 Análise
 Existem 6 RNCs na rede, todas elas têm o mesmo problema,
não deve ser causado por qualquer modificação de parâmetro
 Verificar a distribuição dos usuários
Caso 1 (Cont.)
 A partir do resultado, acreditamos que a distribuição dos UEs mostra
que mais usuários estão localizados na área de fronteira e seu
desempenho de handover não é tão bom quanto os usuários do
centro
 Verifique a sinalização, o sinal GSM é 15 (Hex), que é -90dbm, que

não é muito bom, mas pode satisfazer o handover (limiar de handover
em GSM é -95dbm)
 Mas ao executar o handover, o

sinal GSM já não é assim tão
bom, então o handover falha no
final
Caso 1 (Cont.)
 Com base na coleta de informações, sabemos que a rede está
fazendo o assinante mudar de 850M para 2100M, porque a
licença para 850m expirou
 Cobertura UMTS pior do que antes
Caso 1 (Cont.)
 Solução
 Modificar parâmetros relacionados, ativar o handover do UE
para GSM muito mais cedo, tais como parâmetros 2B,3A
 Ajustar o temporizador T309, quando existe falha de handover,

o UE pode voltar para UMTS após o temporizador expirar
 Ajustar o temporizador de penalidade para evitar o frequente

handover para o 2G
Caso 2
 A rede da operadora X tem GSM1800 e UMTS 2100, eles
não têm GSM 900, a fim de proporcionar uma melhor
cobertura para a voz, especialmente para os usuários
internos, eles querem ativar a função de handover 2G->3G.
Depois de ativar o handover 2G->3G, a taxa de queda de
chamada 3G aumentou
Caso 2 (Cont.)
 Análise
 Com base nos contadores de queda de chamada, vimos que a
maioria das quedas de chamadas são causadas por RF
Caso 2 (Cont.)
 Uma vez que o problema aparece depois de ativar a função
2G->3G, nós verificamos o contador relacionado com
handover
Caso 2 (Cont.)
 Com base na análise de sinalização, sabemos que o problema
é o handover ping-pong
Caso 2 (Cont.)
 No momento do handover, o sinal 3G não era muito bom,
principalmente abaixo de -100dBm, mas o Ec/No era bom,
cerca de -6dB
 Como o Ec/No no 3G estava bom, o handover de 2G -->3G foi

desencadeado, mas o 3G RSCP estava ruim, em seguida, a
medição (modo de compressão) foi ativada novamente, e o UE
voltou para o 2G
Caso 2 (Cont.)
 Solução
 Modificar a quantidade de medição de handover 2G->3G para
RSCP
 Definir InterRATPingPongTimer para um valor adequado
 Definir o InterRATPingPongHyst para evitar handover

pingpong
Caso 3
 No País L Projeto W, após a realização do swap o CS-IRAT
passou para 95,9%, o que é menos do que antes do swap -
96,2%. Uma semana após o swap o CS-IRAT diminuiu para
95,38%
Caso 3 (Cont.)
 Análise
 A razão principal da taxa de sucesso do CS IRAT HO diminuir
a partir de 18 de abril é que algumas células adicionaram
relações vizinhas de 2G, o que resultou em mais tentativas de
CS IRAT HO e a principal razão de falha do CS IRAT HO é a
falha do canal físico. Isso significa que a interface aérea do 2G
é ruim. Quando a quantidade de tentativa de CS IRAT HO
aumentou, a taxa de sucesso do CS IRAT diminuiu
Caso 3 (Cont.)
 A quantidade de tentativas do CS IRAT HO aumentou e a
taxa de sucesso do CS IRAT HO diminuiu em 18 de abril
Caso 3 (Cont.)
 A principal razão de falha é a falha do canal físico, o
percentual é de 83%
Caso 3 (Cont.)
 Compare RNC MML, para algumas células, se adicionou
relações de vizinhas U2G em 18 de abril, o que levou a
mais tentativas CS IRAT HO, tomar a célula 52898 como
um exemplo
 Compare o RNC MML, para algumas células, adicionou

relações U2G vizinho em 18 de abril, isto leva a mais
tentativas CS IRAT HO, tomar a célula 52898 como um
exemplo
Caso 3 (Cont.)
 Soluções
 Como a principal razão para a falha é devido a má cobertura,
foi sugerido modificar HYSTFOR2D e HYSTFOR2F de "0"
para "4", desta forma torna-se mais difícil de entrar em modo
de compressão diminuindo as tentativas do CS IRAT HO
 Também pode modificar o TARGETRATCSTHD,

TARGETRATR99PSTHD e TARGETRATHTHD para "26",
"18" e "18", respectivamente, para garantir que o HO é
realizado em boas condições de rádio
Caso 3 (Cont.)
 HystFor2D
 Nome do parâmetro: hysteresis 2D
 Valor recomendado: 4, ou seja, 2dB
 HystFor2F
 Nome do parâmetro: hysteresis 2F
 Valor recomendado: 4, ou seja, 2dB
Caso 3 (Cont.)
 Valores recomendados do TARGETRATCSTHD,
TARGETRATR99PSTHD e TARGETRATHTHD:
Parâmetro Valor Recomendado
TargetRatCsThd 16, ou seja, -95dBm
TargetRatR99PsThd 16, ou seja, -95dBm
TargetRatHThd 16, ou seja, -95dBm
Caso 3 (Cont.)
 Conclusão
 Após a modificação do parâmetro, o CS IRAT HO SR
começou a melhorar, e o número de tentativas diminuiu
Caso 4
 No país X, projeto Y, houve alta taxa de falha de handover
3G/2G entre um par de células
Caso 4 (Cont.)
 Análise
 Para estas 2 Células, os TPs foram checados para verificar
onde está a cobertura principal dessas células e verificar se há
overshooting ou não
Caso 4 (Cont.)
 01357268_LM_Colobarrutia:
Caso 4 (Cont.)
 Ao verificar a topologia da área e os TPs, descobrimos que
estas duas células estavam localizadas perto de um grande
lago onde o sinal pode ultrapassar uma distância muito
grande e difícil de controlar.
Caso 4 (Cont.)
 Verificou a principal razão para as falhas de Handover da Célula:
 A principal razão para falha de handover das células foi devido a
IRATHO.FailOutCS.PhyChFail
Caso 4 (Cont.)
 Soluções:
 Como era difícil controlar o problema de overshooting, uma
vez que esses dois sites estavam localizados perto do lago,
tentar modificar os parâmetros relacionados para reduzir os
tempos de falha de handover
 Diminuir o valor do parâmetro InterRatPhyChFailNum para

reduzir o número de falhas sucessivas de handover inter-RAT
 Aumentar o valor do parâmetro PenaltyTimeForPhyChFail

para reduzir o número de falhas de handover inter-RAT
aumentando o tempo de penalidade após uma falha
Caso 4 (Cont.)
 InterRatPhyChFailNum
 Nome do parâmetro: Inter-RAT HO Physical Channel Failure
THD
 Valor recomendado: 3
 PenaltyTimeForPhyChFail
 Nome do parâmetro: Inter-RAT HO Physical Channel Failure
Penalty Timer
 Valor recomendado: 30
Caso 4 (Cont.)
 Conclusão
 A taxa de falha de handover diminuiu de 19,93% para 8,88%
 Esta ação pode melhorar IRAT Handover, mas também pode

aumentar as quedas de chamada
 É muito importante verificar a taxa de queda de chamada após

esta ação para se certificar de que não há nenhum impacto
sobre isso
Caso 5
 No país X e Projeto Y, o CS IRAT HOSR é muito baixo,
cerca de 77%
Caso 5 (Cont.)
 Análise
 Verificamos a razão do fracasso e foi encontrado que a
principal razão é a relocation fail due to Unknown RNC
Caso 5 (Cont.)
 A partir do trace de sinalização também foi encontrado que há
muitas falhas de relocalização devido ao Unknown Target RNC
Caso 5 (Cont.)
 A partir do log de trace, verificamos a informação de destino
2G LAC (726) onde a relocalização falhou ao abrir a
mensagem RANAP_RELOCATION_REQUIRED
Caso 5 (Cont.)
 Verificamos o procedimento de Handover IRAT abaixo, podemos
ver que depois de enviar a mensagem "RELOCATION
REQUIRED" para o MSC 3G, nós deveríamos ter a mensagem de
Relocation Command em feedback
 Como o 3G está recebendo a chamada de origem, então não há

nenhum problema que a célula esteja corretamente definida em
MSC 3G. Depois que o MSC 3G enviar a mensagem de
relocalização necessária para MSC 2G, a falha de preparação
está ocorrendo com a causa "Unknown RNC"; o que realmente
significa que não pode identificar a entidade 2G (LAC)
Caso 5 (Cont.)
 Para verificar se o 2G LAC (726) é definido como vizinho ou
não na RNC de serviço, podemos verificar o nome da MSC de
serviço a partir do CFGMML
Caso 5 (Cont.)
 A partir do arquivo MML do MSC, podemos verificar se o LAC
de destino (726) é definido no MSC de serviço como um LAC
local ou LAC vizinho ou não
 Ao verificar a tabela abaixo podemos descobrir que LAC 726

não é definido como vizinho
Caso 5 (Cont.)
 Solução
 Adicionar o LAC 726 como um LAC vizinho
 CS_IRAT HOSR foi melhorado de 77% para 97% e Falha

devido a Unknown.RNC reduziu de 48000 para 0
Caso 5 (Cont.)
 Conclusão
 Tenha muito cuidado ao configurar e fornecer definição de
célula vizinha, RNC e até mesmo o nível MSC. Porque sem a
definição adequada do vizinho, nenhum Handover pode ser
bem sucedido. Ele também irá afetar diretamente a
experiência do usuário
Caso 6
 Um operador no País B queixa-se de que o seu nível de
rede IRAT HOSR KPI é sempre inferior a 90%, o que é uma
base de referência
Caso 6 (Cont.)
 Análise
 1. Verifique se o alarme de 2G e 3G é normal
 2. Verifique se a relação de vizinhança entre 3G e 2G e na

maioria definida corretamente
 3. Também a definição externa entre estes dois RAT deve ser

definida corretamente
 4. Blind HO na célula de co-cobertura deve estar ativado
 5. Verificar a inconsistência de parâmetros entre a inter

operação GUL
Caso 6 (Cont.)
 A partir do exemplo abaixo, encontramos o parâmetro de
nível RNC COEXISTMEASTHDCHOICE não definido
corretamente
Caso 6 (Cont.)
 O detalhe da configuração é a seguinte:
 SET UHOCOMM:
CoexistMeasThdChoice=COEXIST_MEAS_THD_CHOICE_INTER
FREQ
 UCELLHOCOMM: InterFreqRATSwitch=SIMINTERFREQRAT
 SET Uinterfreqhocov:INTERFREQCSTHD2DECN0=-24,
Interfreqcsthd2fecn0=-12, Hhoecnomin=-16,
INTERFREQCSTHD2DRSCP=-105,
INTERFREQCSTHD2FRSCP=-102
 SET Uinterrathocov:Interratcsthd2decn0=-10,
Interratcsthd2fecn0=-8, INTERRATCSTHD2DRSCP=-90,
Interratcsthd2frscp=-87
Caso 6 (Cont.)
 InterFreqRATSwitch
 Nome do parâmetro: Inter-freq and Inter-RAT coexist switch
Valor recomendado: SIMINTERFREQRAT
 CoexistMeasThdChoice
 Nome do parâmetro: InterFreq and InterRat coexist measure
threshold choice
 Valor recomendado:
COEXIST_MEAS_THD_CHOICE_INTERFREQ
Caso 6 (Cont.)
 Devido ao nível de RNC
CoexistMeasThdChoice=COEXIST_MEAS_THD_CHOICE_INTE
RFREQ,
O UE dispara CS IRAT e handover inter frequência com base no

limiar de disparo de Inter frequência 2D/2F que é muito elevado
(2D Ec/IO=- 24 e 2D RSCP=- 105) e número muito baixo de HO
baseado em cobertura acontece
Caso 6 (Cont.)
 Solução
 Alterar o nível de RNC CoexistMeasThdChoice de
Interfrequency para InterRAT e nível de célula
InterFreqRATSwitch de SIMINTERFREQRAT para INTERRAT
Caso 6 (Cont.)
 Conclusão
 Melhora de mais de 2% de CS IRAT HOSR e Inter Frequency
HOSR
Obrigado
www.huawei.com

Analise de Problemas de Handover em WCDMA

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise de Problemas de Handover em WCDMA

Enviado por

Direitos autorais:

Formatos disponíveis

Registro de Revisão Não Imprimir Esta

OWO300080 WCDMA RNO Versão 2,00

Anjinfeng 2014-6-5 Jinyu Atualizar

Deng Chnenggang 2017-3 Suntan Atualizar

Marcio Tadeo 2019-01 Translate Portuguese

Copyright © 2017 Huawei Technologies Co., Ltd. All rights reserved.

2. Análise de Problemas no Soft Handover

3. Análise de Problemas no Hard Handover

4. Análise de Problemas no Inter-RAT Handover

Performance Statistic Collection

DT and Signaling Análise

2. Análise de Problemas no Soft Handover

3. Análise de Problemas no Hard Handover

4. Análise de Problemas no Inter-RAT Handover

2.2 Fluxo de Otimização de Estatísticas de Desempenho em

2.3 Análise de Problemas em SHO

2.4 Casos de Problemas em SHO

2. Obtendo quando e onde o problema ocorre

 “Piloto forte” é definido pelo RSCP. E se CPICH_ RSCP ThRSCP_ Absolute ,

 "Excessivo" é definido pelo número do piloto. Se, CPICH_ Number ThN

 “Ninguém é forte o suficiente para ser dominante” significa

7. Repetindo o teste de unidade e localizando problemas

 Para queda de chamada causada por handover atrasado: ajuste as antenas e o

 Para efeito de agulha (needle) ou efeito de virar a esquina (turning corner): A

 Para queda de chamada causada pelo ping-pong handover: ajuste a antena e o

 Para equipamentos anormais: cooperar com engenheiros de atendimento ao

2.2 Fluxo de Otimização de Estatísticas de Desempenho de

2.3 Análise do Problemas de SHO

2.4 Casos de Problemas de SHO

O UE pensa que o conteúdo da atualização do conjunto ativo para a RNC

O UE responde que o SHO (ou softer handover) para a RNC

O UE pensa que o conteúdo da atualização do conjunto ativo para a RNC

A RNC não recebe resposta ao comando "active set update" para

2.2 Fluxo de Otimização de Estatísticas de Desempenho em

2.3 Análise de Problemas em SHO

2.4 Casos de Problemas em SHO

 Método de planejamento inadequado

 As razões podem ser :

 Célula vizinha ausente

 A decisão de Soft handover é baseada na qualidade do canal CPICH

2.2 Fluxo de Otimização de Estatísticas de Desempenho em

2.3 Análise de Problemas em SHO

2.4 Casos de Problemas em SHO

Queda de Após a queda da

SC 170 não está no monitor

 Célula vizinha ausente

Pesquise pela mais recente intra-

Verifique a lista da célula vizinha

Verifique a célula onde o UE

O UE acampa na célula do SC 170, que é inconsistente

 Célula SC270 é para cobrir a área de poluição do piloto

Aqui está a área de

 A figura a seguir mostra a terceira melhor célula de serviço perto da Yuxing Rd

Melhor Célula de Serviço SC

 Como mostrado na figura à esquerda, o RSSI da área de poluição do piloto não é

 A poluição piloto da área é causada por falta de piloto forte

 A figura mostra RSCP da distribuição RSCP da célula SC270. Os sinais da

 O sinal da célula de origem diminui acentuadamente enquanto a célula

Needle point-signal variance

 Causa deterioração de QoS

 Efeito esquina causa queda de chamada

 Alta BLER causa reset do TRB e, em seguida, queda de chamada

 Se needlepoint puder satisfazer o handover

 Segundao handover no needlepoint pode causar queda de chamada