Diagnostico de Queda de Chamadas LTE (KPI) ISSUE 1.00

Diagnóstico de Queda
de Chamadas LTE
(KPI)
www.huawei.com
Copyright © 2016 Huawei Technologies Co., Ltd. All rights reserved.

Objetivo
 Após concluir este curso, você será capaz de:
 Entender o procedimento de liberação do E-RAB
 Reconhecer o problema de queda de chamada
 Localizar e analisar a causa da queda da chamada
 Realizar a implementação para resolver o problema de queda

de chamada
Copyright © 2016 Huawei Technologies Co., Ltd. All rights reserved. Página 2
Conteúdo
1. Visão geral da queda de chamadas
2. Análise do problema típico de queda de chamada
Conteúdo
1. Visão Geral da Queda de Chamadas
1.1 Procedimento de Liberação de E-RAB
1.2 Definição de Queda de Chamada e Estatísticas KPI
1.3 Problema típico de queda de chamada e procedimento de análise
Portadora em LTE
 Uma portadora EPS é usada para transmitir todos os fluxos
de serviço associados à mesma política de QoS entre um
UE e um P-GW
E-RAB Release
 Portadora EPS = E - RAB + S5 (portadora S8)
 O estabelecimento, modificação e liberação de E-RAB são

desencadeados pelo procedimento EPS de estabelecer,
modificar e liberar
 A liberação da portadora Default E-RAB é desencadeada pelo
procedimento de detach
 A portadora dedicada é acionada pelo procedimento de

liberação da portadora dedicada
Conceito Básico de Detach
 O procedimento Detach permite que:
 O UE informe a rede que não deseja mais acessar o EPS
 A rede informe o UE que não tem mais acesso ao EPS
 O procedimento de detach pode ser iniciado pelo UE, MME

e HSS. Pode ser explícito ou implícito.
 Detach explícito
 Detach implícito
Procedimento de Detach (Executado
pelo UE)
eNodeB MME S-GW P-GW

UE
1. Pedido de detach
Liberar
2. Excluir pedido de sessão
portadora
3. Apagar a resposta da sessão default
4. Excluir pedido de sessão
5. Apagar a resposta da sessão
6. Detach
7. Liberação de conexão de sinalização
Só existe quando o detach é causado
pelo desligamento de energia
Procedimento de Offline Detach
(Executado pelo UE)
 " Detach Request " tem um comprimento 8 bits no campo " Detach
type", o campo tem um indicador "Switch off" (1bit)
 1:Switch off, significa "UE delisgado", como mostrado na figura abaixo
 0: Detach normal, não desligado, veja as próximas duas páginas
Procedimento Detach Iniciado pelo
UE no modo Idle
 Se o UE iniciar o detach no modo idle, o UE deve primeiro
completar a conexão RA e RRC para a handover NAS
UE eNodeB EPC
Preamble
RAR Diferenças entre o modo
RRC_CONN_REQ Idle e o modo conectado
RRC_CONN_SETUP
RRC_CONN_SETUP_CMP
S1AP_INITIAL_UE_MSG
(Detach Request)
S1AP_DL_NAS_TRANS
RRC_DL_INFO_TRANSF (Detach Accept)
(Detach Accept)
UE Context Release Command
RRC Connection Release
UE Context Release Complete
Procedimento Detach Iniciado pelo UE
no Modo Conectado
UE eNodeB EPC
RRC_UL_INFO_TRANSF Diferenças entre o

S1AP_UL_NAS_TRANS modo Idle e o modo
(Detach Request) conectado
(Detach Request)
S1AP_DL_NAS_TRANS
RRC_DL_INFO_TRANSF (Detach Accept)
(Detach Accept)
UE Context Release Command
RRC Connection Release
UE Context Release Complete
Procedimento de Liberação da
portadora Dedicada
 Procedimento de liberação da portadora E-RAB dedicada é
mostrado abaixo:
UE eNodeB MME UGW
UL Information Transfer
Uplink Nas Transport
Delete Bearer Command
Delete Bearer Request
RRC Connection Reconfiguration E-RAB Release Command
（Deactivate EPS bearer (Deactivate EPS bearer
context request） context request)
RRC Connection
Reconfiguration Complete E-RAB Release Response
UL Information Transfer
(Deactivate EPS bearer Uplink Nas Transport
context accept) (Deactivate EPS bearer Delete Bearer Response
context accept)
Conteúdo
1.3 Problema típico de queda de chamada e procedimento de análise
Queda de Chamada na Rede LTE
 A liberação anormal de E-RAB é definida como caída
 O Processo de liberação de E-RAB inclui dois cenários:
Princípio de Cálculo de Queda de
Chamada
 De acordo com a causa da mensagem transportada pelo E-
RAB, a eNodeB pode julgar que é liberação normal ou não
Estado de
Mensagem Razão Estatísticas
transmissão
Valor A* --
Liberação normal
Sem L.E-RAB.NormRel
E-RAB Release
transmissão
Indication Outros
Liberação anormal
Transmissão
L.E-RAB.AbnormRel
Valor B* --
Liberação normal
UE Context Sem L.E-RAB.NormRel
Release transmissão
Request Outros
Liberação anormal
Transmissão
L.E-RAB.AbnormRel
Contadores de Queda de Chamada
LTE
 A estação base LTE suporta as estatísticas das razões de
liberação de E-RAB para o sub-valor e sub QCI
Índice Descrições
Número de liberações anormais causadas por
L.E-RAB.AbnormRel.Radio
problemas na camada de rádio
L.E-RAB.AbnormRel.TNL
problemas na camada de transmissão
L.E-RAB.AbnormRel.Cong
problemas de congestionamento de rádio
L.E-RAB.AbnormRel.HOFailure
falha de handover
Número de liberações anormais causadas pelo
L.E-RAB.AbnormRel.MME
core da rede
KPI de taxa de queda de chamada
LTE
 Taxa de queda de chamada LTE:
 Taxa de Chamada = (L.E-RAB.AbnormRel / (L.E-
RAB.AbnormRel + L.E-RAB.NormRel)) × 100%
 L.E-RAB.AbnormRel: Número total de liberações anormais
de RAB em uma célula
 L.E-RAB.NormRel: Número total de liberações normais de

RAB em uma célula
 O KPI é usado para avaliar a taxa de queda de todas as

operações, incluindo serviços VoIP, portadora de rádio e
portadora S1, e qualquer liberação anormal da portadora
resulta em queda de chamada
Como obter KPI de taxa de queda de
chamada em LTE
 Consulta de Resultados de Performance - Configuração do Objeto
chamada em LTE (Cont.)
 Consulta de Resultados de Performance - Configurações
de KPI
 Consulta de Resultados de Performance - Configurações
de KPI
 Consulta de Resultados de Performance - Resultados de saída
Conteúdo
1.3 Problema típico de queda de chamada e procedimento de

análise
Queda de Chamadas no LTE
 A queda de chamada típica na rede LTE:
 Liberação anormal causada por problemas na camada de
rádio
 Liberação anormal causada por problemas na camanda de

transporte
 Liberação anormal causada por problemas de

congestionamento na rede de rádio
 Liberação anormal causada por problemas de handover
 Liberação anormal causada por problemas na core da rede
Distribuição da Chamada
Problemas de
handover S-eNodeB MME
1.Qualidade de rádio S1-c
2.Configuração NCell
3. Configuração de UU
Parâmetro de Handover UE X2
4.Overlapping
S11
UE UU S1-c S1-U
T-eNodeB
S1-U
UGW
Problemas de Recurso de rádio Transmissão Rede principal

Rádio
1.Cobertura Ruim 1. Número limitado de 1.Falha de Transmissão 1.Congestionamento dos

2.Problema de interferência utilizadores 2.Congestionamento de recursos do core da rede
3. Falha de interação de 2.Congestionamento de Recursos de Transporte 2.Configuração da rede
sinalização recursos Core
4.Falha de sincronização
5.Falha no
restabelecimento
Processo de tratamento da queda de
chamada

Conteúdo
2.1 Queda de chamada causada por problema de camada de rádio
2.2 Queda de Chamada Causada por Problema da Camada de

Transporte de Rádio
2.3 Queda de Chamada Causada por Congestionamento na Rede de

Rádio
2.4 Queda de Chamadas Causada por Problema de Handover de Rádio
2.5 Queda de Chamadas Causada por Problema na Rede Core de

Rádio
Queda de chamada causada por
problema de camada de rádio
 O fenômeno da queda de chamada que está relacionado ao rádio:
 Estatísticas do KPI
 A razão de queda de chamada é L.E-RAB.AbnormRel.Radio
 Processo de sinalização
 Durante o handover, o UE iniciou RRC re-establishment, mas foi

rejeitado.
Queda de chamada causada por
problema de camada de rádio (Cont.)
 Razões típicas de queda de chamadas causadas pelo rádio:
 Razão 1: Má qualidade do canal
 Razão 2: Falha de interação de sinalização
 Razão 3: Falha de sincronização
 Razão 4: Falha de restabelecimento
1ª Razão: Qualidade Ruim do Canal
 Qualidade Ruim do canal:
 Má qualidade do canal de rádio pode causar falha do UE para
demodular dados e sinalização, e o UE vai tentar a retransmissão de
dados até o máximo de tempo.
 Análise do Problema:
 Teste DT para avaliar a qualidade do canal
– Se RSRP<-110dBm, a cobertura de downlink é fraca .
– Se SINR<-3dB, a qualidade do canal de downlink é menor do que o limiar

demodulação necessário, o que afeta a demodulação de dados de downlink.
– Se a potência de transmissão de uplink for superior a 20dBm, a cobertura de

uplink é fraca.
– Se o IBLER superior / inferior >20%, a qualidade do uplink / downlink é pobre.
– Se o uplink RSSI > -100dBm, pode ter interferência de uplink .
1ª Razão: Qualidade Ruim do Canal
 Qualidade Ruim do canal:
 Solução:
 Se o downlink RSRP é pobre ou a energia de transmissão de
uplink é sempre alta, a rede precisa de otimização de RF para
fortalecer a cobertura.
 Se o downlink SINR é pobre ou uplink RSSI é alto, a rede precisa

verificar IM3 (a terceira Intermodulação) otimização, sobreposição
de cobertura e interferência.
Sugestão
1. Problema de interferência do downlink: Se o esquema de RF
for limitado, a rede pode ativar a funcionalidade ICIC;
2. A cobertura do uplink é fraca: Se o esquema de RF for
limitado, a rede pode ativar a funcionalidade Bounding TTI.
Razão 2: Falha do procedimento de
sinalização
 Falha do procedimento de sinalização
 Devido à qualidade do link de rádio, capacidade de terminal,
configuração do temporizador ou outras questões.
 Se a sinalização UU falhar quando ocorrer queda de chamada
 Verifique o IBLER para confirmar a existência de problemas de

qualidade do canal
 Se a capacidade do terminal é suportada pela configuração

relacionada
 Se o temporizador de resposta da interface UU foi definido de

forma razoável.
2ª Razão: Falha do procedimento de
sinalização (Cont.)
 Falha do procedimento de sinalização
 Solução:
 Se houver problemas de qualidade do canal de interface Uu,
execute a otimização de RF
 Se a capacidade do UE não suportar a função configurada,

atualize a configuração dos parâmetros de UE ou eNodeB
 Recomenda-se configurar o UuMessageWaitingTimer para 35

s.
3ª Razão: Falha de Re-Sincronização
 Falha de re-sincronização
 Se o UE conter novos dados para enviar quando estiver fora
de sincronização, o UE enviará uma mensagem de acesso
aleatório para realizar a sincronização de uplink.
 Análise do Problema:
 Extrair os Dados CHR e verificar a mensagem de detalhe de
liberação anormal, a causa é falha de re-sincronização.
Causa da falha de sincronização

UEM_UECNT_REL_UE_RESYNC_TIMEROUT_REL_CA
USE
UEM_UECNT_REL_UE_RLC_UNRESTORE_IND
3ª Razão: Falha de Re-Sincronização
(Cont.)
 Falha de re-sincronização
 Solução
 Otimizar a Cobertura de downlink e interferência
– Garantir demodulação PDCCH e RAR dos Ues.
– Otimizar a Cobertura de uplink e interferência.
– Garantir a recepção do preâmbulo e da MSG3 no lado da eNodeB.
4ª Razão: Falha de Estabelecimento
 Falha de restabelecimento
 Quando a rede tem falha de link de rádio, falha de procedimento de
sinalização Uu, falha de handover ou outra falha, o UE irá iniciar o
procedimento de re-establishment RRC para restaurar a conexão
RRC.Índice Descrição do índice
L.RRC.ReestFail.Disc.FlowCtrl Número de queda da mensagem de pedido RRC re-establishment
do fluxo de controle
L.RRC.ReEst.ReconfFail.Rej O número de rejeições para desencadear o RRC re-establishment
por falha de reconfiguração
L.RRC.ReEst.HoFail.Rej O número de rejeições para desencadear o RRC re-establishment
devido à falha de handover
L.RRC.ReEstFail.ResFail O número de rejeições para desencadear o RRC re-establishment
com falha atribuída ao recurso
L.RRC.ReestFail.NoReply O número de rejeições para desencadear RRC re-establishment
sem resposta do UE
L.RRC.ReEstFail.Rej O número de rejeições de RRC re-establishment
L.RRC.ReEstFail.NoCntx O número de rejeições para desencadear o RRC re-establishment
sem contexto na célula
L.RRC.ReEstFail.NoCntx.PreP O número de rejeições para desencadear RRC re-establishment
rocFail com falha de pré-processamento que nenhum contexto
4ª Razão: Falha de Restabelecimento
(Cont.)
 A queda de chamada causada pela falha de RRC re-
establishment pode ser confirmada a partir da análise estatística
do evento DT e KPI:
– Restabelecimento RRC do evento recusado aconteceu associado com
o processo de queda anormal DT
– Os tempos de falha de restabelecimento das estatísticas KPI são

semelhantes aos tempos de queda.
4ª Razão: Falha de Estabelecimento
(Cont.)
 Solução do problema
 Executar otimização de RF
– Para melhorar a cobertura contínua, reduzir a interferência, e evitar a
falha do link de rádio
 Realizar a otimização do parâmetro de handover

– Evitar a falha de handover para desencadear o restabelecimento do
processo
Conteúdo


Rádio

Rádio
Queda de Chamada Causada por Problema
da Camada de Transporte de Rádio
 Fenômeno:
 Problema de TNL pode ser avaliado através de estatísticas de
tráfego ou sinalização S1
 Estatísticas KPI
 Rastreamento de sinalização DT
Queda de Chamada Causada por Problema
da Camada de Transporte de Rádio
 Razões prováveis:
 Razão1: O recurso de transmissão não está disponível
 Razão 2: O recurso de transmissão tem congestionamento
Razão1: O recurso de transmissão
não está disponível
 O recurso de transmissão não está disponível
 O recurso de transmissão não pode ser usado, o que causa a função
da rede de transmissão e o desempenho ficarem anormais, bem
como a interrupção do serviço.
 Confirmação do Problema:
 Queda de chamada DT: analise se a razão da liberação E-RAB está
relacionada ao recurso de transmissão.
 Análise de KPI: verifique se a principal razão da queda de chamada é TNL.
 Verifique se há alarme relacionado com a transmissão
 Portas relacionadas com Check transport e configuração IP
 Executar o teste de desempenho de transmissão, verificar se existe

problemas de transmissão flash off.
Razão1: O recurso de transmissão
não está disponível (Cont.)
 O recurso de transmissão não está disponível
 Solução do Problema:
 Tratar alarmes de transmissão de acordo com a sugestão de
referência.
 Verificar a configuração da porta de transmissão e do endereço IP
 Localize a transmissão intermitente, substitua a placa de falha ou

os componentes.
Caso 1: Falha de IPPATH Causa
Aumento de Queda de Chamada
 Caso do Fenômeno
 No País S, um site possui várias quedas de chamada
repentinamente. Verificando a partir de relatórios de KPI, a
principal razão de queda é "rádio".
(Cont.)
 Análise do Problema
 Verifique o estado da célula e dos alarmes do site, está normal.
 Tanto a qualidade do sinal de downlink e uplink estão bem

depois de analisar o log de DT.
 Rastreie a sinalização do lado UE, o UE foi liberado durante o

teste, em seguida, acesse o UE novamente, não há nenhum
problema óbvio acontecendo.
(Cont.)
 O engenheiro verificou os dados da CHR e descobriu que 53,21% da liberação

anormal é "UEM_UECNT_REL_SAE_BEARER_REL_NUM_MAX4“
 A mensagem de registo de depuração da eNodeB mostra:
(Cont.)
 Solução do Problema
 Após a verificação da rede de rádio, sinalização e impressão
interna, confirmamos que o problema é a falha de transmissão.
 Transfira esta questão para o engenheiro de transmissão. E

confirme se este problema é causado pelo laser
 Resultado da Verificação
 Após a substituição da interface laser component , S1 está
normal, a taxa de queda volta ao normal.
Caso 2: Erro de Configuração do
MTU
 Fenômeno do problema
 Um fornecedor comercial descobriu que uma taxa de queda de
chamada celular é muito alta, perto de 25%, um impacto sério
sobre a percepção do usuário
 De acordo com as estatísticas de queda de chamada, ocorrem
101 vezes a liberação anormal, L.E-RAB. AbnormRel.TNL na
camada de transmissão é maior que 100 e apenas 1 para L.E-
RAB.AbnormRel.Radio. Então podemos excluir interferência
de rádio e cobertura fraca
Caso 2: Erro de Configuração da
MTU (Cont.)
 Através da análise de log descobrimos que a queda anormal é
causada pelo valor do
UEM_UECNT_REL_ERAB_REL_TRAN_UNUSABLE_CAUSE
durante este período, ou seja, os recursos de transmissão
GTP-U não podem ser usados, o que causa a liberação
anormal
MTU (Cont.)
 Verificando a configuração do S1 e o alarme, sem problemas
de configuração e alarme
 Através do teste do pacote Ping entre servidor e UE, pode ser

confirmado que existe um problema com a transmissão
 Através do teste do pacote Ping do PING do cliente Server

para os usuários, o pacote maior que 1424 não é alcançável,
mas se for menor que o valor do pacote PING pode ser
alcançado, então entendemos que a configuração da rede de
transmissão MTU é excepcional
MTU (Cont.)
 Verificação do Problema
 O engenheiro de rede Core verifica a configuração do dispositivo de
transmissão e descobre que uma configuração do comutador é
excepcional: MTU no lado da eNB (down) é 1500 Bytes, MTU na core
da rede (uplink) é 9000 Bytes
 Tratamento de problemas
 Modificar a configuração excepcional do comutador MTU, o uplink e o
downlink são definidos para 9000 Bytes para MTU
 Verificação do regime
 O Limiar MTU é modificado, o fenômeno do fenômeno anormal
desapareceu, a taxa de queda de chamada é estavelmente 0,02%
Conteúdo

2.3 Queda de Chamada Causada por Congestionamento na Rede

de Rádio

Rádio
Queda de Chamada causada por
Congestionamento na Rede de Rádio
 Fenômeno de queda provocada pelo congestionamento da
rede de rádio
 O número de usuários em uma célula é limitado e o
congestionamento de recursos de rádio, que causou uma queda
de chamada, pode ser identificado por estatísticas de KPI
Congestionamento na Rede de Rádio
(Cont.)
 A principal razão do congestionamento da rede de rádio
causar queda de chamada:
 Razão 1: O número de utilizadores é limitado
 Razão 2: Congestionamento dos recursos de rádio
 Nota: No início, este problema é pequeno, com o

crescimento de usuários e do negócio, este se tornará o
principal problema
1ª Razão: O Número de Utilizadores é
Limitado
 Número limitado de utilizadores
 Muitos usuários levam à atribuição de recursos limitados, os
recursos de agendamento são insuficientes, a experiência do
usuário é diminuída
 Reconhecimento do Problema
 Análise das causas da queda de KPI
– Escolha a Célula TOP N na qual a razão de queda de chamada é o
congestionamento de rede de rádio
 Monitorar o número máximo de usuários na célula TOP

– Se o número máximo de usuários freqüentemente tende ao limite LIC,
a razão é o número de usuários que são limitados
1ª Razão: O Número de Utilizadores é
Limitado (Cont.)
 Número limitado de utilizadores
 Solução
 Expansão da capacidade LIC/balanceamento de carga / dividir
usuários / expansão da capacidade da rede
2ª Razão: Recurso de Rádio Limitado
 Recurso de rádio limitado
 A limitação dos recursos do canal de controle e do canal de tráfego
pode fazer a queda de chamada de um UE
 Estatísticas da causa da queda do KPI
– Escolha a Célula TOP N na qual a queda de chamada é ocasionada pelo
congestionamento de rede de rádio
 O número de utilizador LIC não é limitado, a taxa de utilização de PRB

continua a ser demasiado elevada
 Solução
 Expansão da capacidade da rede/balanceamento de carga / expansão da
capacidade da rede (final)
Conteúdo


Rádio
2.4 Queda de Chamadas Causada por Problema de Handover de

Rádio

Rádio
Atraso no Handover leva a queda de
chamada
 Handover atrasado leva ao fenômeno de queda de
chamada
UE envia
restabelecimento para
célula sem recurso
Queda de
Tráfego
Atraso de Handover leva à queda de
chamada – Análise
 Causa comum de atraso de handoever:
 Razão 1: Os parâmetros de handover não estão corretos
 Razão 2: Configuração da célula vizinha / incompatibilidade
 Razão 3: Má qualidade do canal de rádio
S-eNodeB
UU
UE X2
UE UU
T-eNodeB
Razão 1: Parâmetros de Handover
inadequados
 O parâmetro de handover não é adequado
 O limiar utilizado para desencadear a medição de handover é
muito baixo, o deslocamento e o limiar para desencadear a
handover não são adequados
 Resolução de problemas
 Verifique se o parâmetro handover está definido em grande
diferença com os requisitos básicos
 Verifique se há uma perda de relatório de medição / instruções

de handover
 Verifique se o UE faz o restabelecimento da célula de origem

após a falha de handover
não razoáveis (Cont.)
 O parâmetro de handover não é razoável
 Solução do Problema
 Otimizar a opção do parâmetro de handover não razoável
 Se a razão para perda de sinalização ou restabelecimento de uma célula

que não seja de origem seja atraso de handover, ajuste os parâmetros de
handover, meça a medição e acione o handover no tempo
1. Se a medição for difícil de disparar, aumente o limiar de A2 de

2-5dB, reduzindo o mesmo intervalo do limiar em A1;
2. 2. Para handover tardio para uma célula / banda específica,
aumente o valor específico de Ocn / banda adjacente Ofn 2-
4dB;
3. Para handover tardio para todas as células / bandas, reduza o
deslocamento da célula de origem OCS / “bias” de frequência
de serviço Ofs / limiar de handover 2-5dB.
2ª Razão: Configuração ausente /
errada da célula vizinha
 Configuração ausente/errada da Célula Vizinha
 A configuração incorreta ou ausente da célula vizinha irá
causar queda de chamada
 Resolução do Problema
 Verifique se falta a configuração do NCL
 Verificar se falta a configuração do NRT
 Verifique se a configuração do NCL está errada (ID/Cell

ID/PCI/TAC PLMN/eNodeB)
 Verifique se a configuração do ID do NRT está errada (ID/Cell

PLMN/eNodeB)
2ª Razão: Configuração ausente /
errada da célula vizinha(Cont.)
 Configuração ausente /
ADD/MOD EUTRANEXTERNALCELL
errada da célula vizinha
ADD/MOD
 Solução do Problema EUTRANINTRAFREQNCELL
 Adicionar célula externa ADD/MOD

EUTRANINTERFREQNCELL
 Adicionar a relação de
célula adjacente ausente ADD/MOD CDMA20001XRTTEXTCELL
 Reparar com parâmetros
ADD/MOD CDMA20001XRTTNCELL
de células externas
ADD/MOD CDMA2000HRPDEXTCELL
 Correção da relação com a
célula adjacente ADD/MOD CDMA2000HRPDNCELL
inadequada
3ª Razão: Baixa qualidade do canal
de rádio
 O relatório de medição não é bem sucedido ou as
instruções de handover não podem ser corretamente
demoduladas
 Resolução do problema
 A eNodeB não recebeu a medida do UE reportada.
 A estação base emitida sob a instrução de comutador UE não

recebeu a mensagem de handover da eNodeB.
 Monitore a interferência RSRP/SINR/PHR/MCS/IBLER/modo 3

para confirmar se é uma cobertura fraca ou interferência
de rádio (Cont.)
 Má qualidade do canal de rádio
 Implementação da otimização de RF, para resolver o problema
de cobertura de uplink e downlink
– A otimização de cobertura de Downlink pode usar inclinação da
antena, ajuste de energia, diversidade de transmissão e outros
métodos
– A otimização de cobertura de Uplink pode usar a diversidade de

recepção ou Bounding TTI Technology
 Ajustar o limiar de medição de handover
de rádio (Cont.)
 Má qualidade do canal de rádio
 Limpar ou otimizar interferência de downlink
– A interferência da mesma rede de frequência pode ser controlada
ajustando a antena para baixo ângulo de inclinação e ângulo azimute,
e também pode introduzir a função ICIC para alcançar a
coordenação da interferência
Handover Ping-pong
 Queda de chamada causada pelo handover ping-pong
 Durante o handover ping-pong, há um grande número de

processos de reconfiguração RRC
 O UE não pode responder rapidamente a um grande número de

re-configuração RRC, a estação base vai usar a causa
Radio.UuNoReply para liberar o UE
Queda de Chamada causada pelo
Handover Ping-pong
 Razões para handover ping-pong:
 1ª Razão: Parâmetros de handover não razoáveis:
Cell1
 2ª Razão: Cobertura de Overlapping

UU
UE
UE
UU
UU
Cell3
Célula 2
não razoáveis
 Parâmetros de handover não razoáveis:
 O limiar de handover e o offset não são configurações
razoáveis
 A histerese do tempo de relatório de handover é definida

muito pequena
Condições comuns de tomada de decisões

A3:Mn + Ofn + Ocn - Hys > MS + Ofs + Ocs + Off
A4:Mn + Ofn + Ocn - Hys > Thresh1
B1:Mn + Ofn - Hys > Thresh2
 Resolução do problema
 Se aparecer handover ping-pong no teste de DT e o coeficiente de
cobertura sobreposta é inferior a 3, pode ser parâmetros de handover
não razoáveis ou histerese do tempo
 Utilizar o U2000 para verificar os parâmetros de handover relevantes,

comparando com o valor de base
 A fim de garantir a validade dos resultados de medição, o tempo para
Trigger Time é definido para 640ms
 Ping Pong HO ocorre na célula de origem e células vizinhas, aumentando

o valor de bias Ocs 2-4dB
 Ping Pong HO ocorre entre a célula de origem e a célula específica,

reduzir o valor de OCN específico da célula 2-4dB
– Modificação de OCS (com base no aumento da demanda)
MOD CELL
– Modificação do OCN (com base no aumento da demanda)
MOD EUTRANINTERFREQNCELL ; MOD EUTRANINTRAFREQNCELL
2ª Razão: Sobreposição de Cobertura
(Overlapping)
 Cobertura seriamente sobreposta
 Sobreposição grave causará handover ping-pong
 Correção do problema
 De acordo com os dados de DT para calcular o coeficiente de
cobertura sobreposta, se o coeficiente de cobertura sobreposição
é superior a 3 e tem ping-pong handover, então é por causa da
sobreposição
 Através da otimização de RF, fortalecer a posição dominante da
célula de serviço principal para resolver o problema de cobertura
sobreposta.
Conteúdo


Rádio

Rádio
Fenômeno de Chamada Causada
pela Rede Core
 Falhas de interação de sinalização NAS e sinalização S1 na interface do
core da rede , sobrecarga do core da rede, configuração do parâmetro de
core da rede e outros problemas podem levar o UE cair
 Queda de chamada causada pelos problemas do core da rede
 No processamento da análise estatística de KPI, o valor de queda é L.E-

RAB.AbnormRel.MME
Número total de liberações anormais causadas por

MME
Página 75
Análise da queda de chamada
causada pelo core da rede
 Os problemas comuns do core da rede causaram queda de
chamada
 Razão 1: Congestionamento do core da rede
 Razão 2: Configuração do core da rede
Razão 1: Congestionamento do core
da rede
 Congestionamento do core da rede
 O congestionamento do core da rede, tal como a sobrecarga
da placa única MME
 Confirmar se o MME é o problema da linha principal através das
estatísticas de KPI
 Verificar se a carga do lado do MME / SGW / PGW tem a mesma

tendência com a razão da quantidade de queda de chamada
MME
 Engenheiro de core deve ajudar a verificar se existe uma

mensagem de indicação de sobrecarga
1ª Razão : Congestionamento do core
da rede (Cont.)
 Congestionamento do core da rede
 O lado da estação base abre a seleção MME com base na carga
 Placa de expansão MME/SGW/PGW
2ª Razão: Configuração do Core da
Rede
 Configuração do core da rede
 A configuração do parâmetro da interação de sinalização no
core da rede não é razoável, como o temporizador T3
 Confirmar se o MME é o problema principal através das
estatísticas de KPI
 Verificar se a estatística de carga do lado do MME/SGW/PGW é

inferior ao limiar de sobrecarga
 Analisar a sinalização de interação da interface S1, verificando

se a falha de interação da interface S1 existe
2ª Razão: Configuração do Core da
Rede
 Configuração do core da rede
 Cooperar com os engenheiros do core da rede para otimizar os
parâmetros de interface, temporizador, etc
Obrigado
www.huawei.com

Diagnostico de Queda de Chamadas LTE (KPI) ISSUE 1.00

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

Diagnostico de Queda de Chamadas LTE (KPI) ISSUE 1.00

Enviado por

Direitos autorais:

Formatos disponíveis

Diagnóstico de Queda

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

 Reconhecer o problema de queda de chamada

 Localizar e analisar a causa da queda da chamada

 Realizar a implementação para resolver o problema de queda

2. Análise do problema típico de queda de chamada

1.2 Definição de Queda de Chamada e Estatísticas KPI

1.3 Problema típico de queda de chamada e procedimento de análise

2. Análise do problema típico de queda de chamada

 O estabelecimento, modificação e liberação de E-RAB são

 A portadora dedicada é acionada pelo procedimento de

 A rede informe o UE que não tem mais acesso ao EPS

 O procedimento de detach pode ser iniciado pelo UE, MME

eNodeB MME S-GW P-GW

5. Apagar a resposta da sessão

 0: Detach normal, não desligado, veja as próximas duas páginas

RRC Connection Release

UE Context Release Complete

RRC_UL_INFO_TRANSF Diferenças entre o

RRC Connection Release

UE Context Release Complete

1.2 Definição de Queda de Chamada e Estatísticas KPI

1.3 Problema típico de queda de chamada e procedimento de análise

2. Análise do problema típico de queda de chamada

 O Processo de liberação de E-RAB inclui dois cenários:

 L.E-RAB.NormRel: Número total de liberações normais de

 O KPI é usado para avaliar a taxa de queda de todas as

1.2 Definição de Queda de Chamada e Estatísticas KPI

1.3 Problema típico de queda de chamada e procedimento de

2. Análise do problema típico de queda de chamada

 Liberação anormal causada por problemas na camanda de

 Liberação anormal causada por problemas de

 Liberação anormal causada por problemas de handover

 Liberação anormal causada por problemas na core da rede

Problemas de Recurso de rádio Transmissão Rede principal

1.Cobertura Ruim 1. Número limitado de 1.Falha de Transmissão 1.Congestionamento dos

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

2. Análise do problema típico de queda de chamada

2.1 Queda de chamada causada por problema de camada de rádio

2.2 Queda de Chamada Causada por Problema da Camada de

2.3 Queda de Chamada Causada por Congestionamento na Rede de

2.4 Queda de Chamadas Causada por Problema de Handover de Rádio

2.5 Queda de Chamadas Causada por Problema na Rede Core de

 A razão de queda de chamada é L.E-RAB.AbnormRel.Radio

 Durante o handover, o UE iniciou RRC re-establishment, mas foi

 Razão 2: Falha de interação de sinalização

 Razão 3: Falha de sincronização

 Razão 4: Falha de restabelecimento

– Se SINR<-3dB, a qualidade do canal de downlink é menor do que o limiar

– Se a potência de transmissão de uplink for superior a 20dBm, a cobertura de

– Se o IBLER superior / inferior >20%, a qualidade do uplink / downlink é pobre.

– Se o uplink RSSI > -100dBm, pode ter interferência de uplink .

 Se o downlink SINR é pobre ou uplink RSSI é alto, a rede precisa

 Verifique o IBLER para confirmar a existência de problemas de

 Se a capacidade do terminal é suportada pela configuração

 Se o temporizador de resposta da interface UU foi definido de

 Se a capacidade do UE não suportar a função configurada,

 Recomenda-se configurar o UuMessageWaitingTimer para 35

Causa da falha de sincronização

– Otimizar a Cobertura de uplink e interferência.

– Garantir a recepção do preâmbulo e da MSG3 no lado da eNodeB.

– Os tempos de falha de restabelecimento das estatísticas KPI são

 Realizar a otimização do parâmetro de handover

2. Análise do problema típico de queda de chamada