18 wcdma análise de problemas de handover

HUAWEI TECHNOLOGIES CO., LTD. All rights reserved

www.huawei.com

Internal

Análise de Problemas de Handover no WCDMA

ISSUE 1.2

PDF created with pdfFactory Pro trial version www.pdffactory.com

http://www.huawei.com

http://www.pdffactory.com


l Handover soft, hard, e inter-RAT

l Falha no handover é um fator importante que influencia na performance de rede. Por exemplo:

[ Pode resultar em queda de chamada

[ Freqüentes handovers desperdiçam recursos

[ Soft handover consome capacidade de downlink




l Após completar este curso, você teráconhecimentos sobre:

[Fluxo de análise de problemas de handover

[Problemas típicos de handover




CapCapíítulo 1 Fluxo de Otimizatulo 1 Fluxo de Otimizaçção de ão de HandoverHandover baseado em DTbaseado em DT

CapCapíítulo 2 Fluxo Otimizatulo 2 Fluxo Otimizaçção de ão de HandoverHandover por Estatpor Estatíísticas de Trsticas de Trááfegofego

CapCapíítulo 3 Antulo 3 Anáálise de Problemas de lise de Problemas de HandoverHandover

CapCapíítulo 4 Casos de Problemas de tulo 4 Casos de Problemas de HandoverHandover




Problemas de Handover baseados no fluxo de otimização de DT

l DT (drive test) é importante para avaliação e otimização de rede e o

seu resultado somado aos KPIs podem refletir na performance da rede

l DT global pode localizar problemas como, ausência de vizinhas,

sobreposição, pilot pollution…

l As próximas seções descrevem o fluxo de otimização de DT para SHO,

HHO, e Inter-RAT HO




l Benchmark de performance de Handover

35%DTN/ASHO ratio

92%DT&Stat.PS handover out

95%DT&Stat.Voice handover outInter-RAT handover success rate

85%DT&Stat.PS UL64K/DL 384K



90%DT&Stat.VP

92%DT&Stat.Voice

Inter-frequency HHO success rate




85%DT&Stat.VP

90%DT&Stat.Voice

Intra-frequency HHO success rate

99%DT&Stat.CS&PSSHO success rate

Reference valueStatistics methodServiceIndex

Problemas de Handover baseados no fluxo de otimização de DT




Fluxo de otimização de SHO baseado em DT

l 1.Dados de análise

[Dados do DT, relacionados

com o signaling tracing, scripts RNC CHR, e dados de configuração do RNC

l2. Quando e Onde o problema ocorre

[No drive test, gravar o local, momento, e outras informações relacionadas ao problema de SHO,




l 3. Ausência de células vizinhas

[ No início, normalmente a maioria das quedas de chamadas são causadas devido à definição inadequada da lista de vizinhas

No

Get best Ec/Io from UE in AS

Compare with best Ec/Io

from Scanner

Other Análiseflow

Yes

Check the best cell SCfrom AS is in

Measure control?

Other Análiseflow

Yes

Missing Neighbor cells

No

l Método 1

[ O Ec/Io registrado pelo UE é ruim

[ O Ec/Io registrado pelo scanner ébom

[ A melhor célula encontrada pelo scanner não está na lista de vizinhas





l Método 2

[ Após queda de chamada, o UE faz uma conexão com a rede imediatamente em outra célula.

[ Se o SC da nova célula é diferente da anterior à queda da chamada, uma célula ausente na lista de vizinhas pode ser uma razão.

− Verificar o controle de medida da célula fonte para confirmar este problema

− Verificar o SC no detected set do UE antes da queda da chamada





4. Pilot pollution

l Definição: Pilotos excessivamente fortes existem em um dado ponto, mas nenhum é suficientemente forte para ser considerado como dominante

− “Piloto forte” é definido por RSCP.

− “Excessivo” é definido pelo número de pilotos.

− “Nenhum deles é suficientemente forte para ser um dominante”

AbsoluteRSCPThRSCPCPICH __ >

NThNumberCPICH >_

lativeRSCPthThst ThRSCPCPICHRSCPCPICHN Re_)1(1 )__( <− +





l 4. Pilot pollution

l Em função da descrições prévias, Pilot pollution existe se todas as seguintes condições forem cumpridas:

− O número de pilotos satisfazendo é maior que

− Ajuste , , e , os padrões de julgamento para poluição de piloto são:

▪ O número de pilotos satisfazendo é maior que 3.

▪

AbsoluteRSCPThRSCPCPICH __ >

lativeRSCPthThst ThRSCPCPICHRSCPCPICHN Re_)1(1 )__( <− +

dBmTh AbsoluteRSCP 95_ −= 3=NTh dBTh lativeRSCP 5Re_ =

dBRSCPCPICHRSCPCPICH thst 5)__( 41 <−

dBmRSCPCPICH 95_ −>





l 5. Configuração Imprópria de Parâmetros de Algoritmo de SHO

[ Handover atrasado

− De acordo com o fluxo de sinalização, o UE falha em receber o “activeset update” devido à seguinte causas:

▪ Após o UE reportar a mensagem de medidas, o Ec/Io da célula servidora cai rapidamente.

▪ Quando a RNC envia um “active set update”, o UE já desligou o transmissor devido à falta de sincronismo. O UE não pode receber o “active set update”





[ Ping-pong de handover

− duas formas:

− A melhor servidora muda frequentemente.

▪ Duas ou mais células alternam sendo a melhor servidora. O RSCP da melhor servidora é bom, mas o período de cada célula a ser a melhor servidora é curto

− Sem célula dominante

▪ Todos os RSCP das células são quase os mesmos e suficientemente bons, mas os Ec/Io das células são ruins





l 6. Refazendo DT e localizando problemas

[ Se o problema não é devido às causas anteriores, faça o DT novamente e colete os dados para prover maiores informações





l Ajuste e Implementação

[ Para pilot pllution, podem ser adotados os seguintes métodos:

− Ajustar os parâmetros de engenharia de antena para conseguir umacélula dominante ou eliminar problemas de handover causados por poluição de piloto

− Ajustar os parâmetros de engenharia de outras antenas. Assim, os sinais delas se tornam mais fracos

− Fazer com que um novo site cubra essa área, se as condições permitirem.

− Se a interferência é de dois setores do mesmo NodeB, combinar duas células em uma





l Ajuste e Implementação

[Para handover atrasado, o seguinte método pode ser adotado

− Ajustar as antenas para expandir a área de handover

− Configurar os parâmetros de handover do evento 1A

− Aumente o CIO para permitir que o handover ocorra antecipadamente

[Para Ping-pong de handover, o seguinte método pode ser adotado

− Ajuste a antena para formar a melhor servidora

− Ajuste o parâmetro de evento 1B para fazer com que a exclusão de célula do active set seja mais difícil. Por exemplo, aumente o limiar de evento 1B, ou o 1B hysteresis, ou o 1B delay trigger time





l 1. Dados de análise

[ Dados de DT ,

[ Trace de sinalização relacionado

l 2. Local e hora da queda de chamada

Fluxo de otimização de HHO baseado em DT




l 3.Checar lista de células vizinhas

[ Este fluxo de otimização de HHO é similar ao de SHO

l 4. Problemas de HHO normalmente se referem a atraso ou ping-pong de handover

[ Para Delayed HHO, as seguintes soluções podems ser adotadas

− Aumentar o limiar do compression mode inicial

− Aumentar o CIO de duas células inter-frequency

− Diminuir o limiar de disparo de handover da cobertura inter-frequency

[ Para resolver o Ping-pong HHO:

− Aumentar o HHO hysteresis e delay trigger time





l 5. No intraintra--frequencyfrequency HHOHHO, a otimização é similar à do inter-frequency HHO.Solução :

[ Diminuir a hysteresis e delay trigger time do evento 1D para garantir que o handover possa ser executado a tempo





l 1. Dados de análise

[Dados de DT

[Trace de sinalização relacionado, etc.

l Instante e localização da queda de chamada

Fluxo de otimização de inter-RAT Handover baseado em DT




l Fluxo de análise de problemas de Inter-RAT handover

[ Checando configuração de dados, especialmente os seguintes:

− Informação de célula GSM na RNC.

− Informações de célula GSM e LA na MSC

− Célula WCDMA e informação de LA no BSS





l Se os dados de configuração estão completos, os problemas de inter-RAT são devidos principalmente ao atraso no handover. As seguintes soluções podem ser adotadas:

[ Aumentar o CIO

[ Aumentar o limiar para inicio e término do compression mode

[ Aumentar o limiar para fazer o handover para o GSM





Resolução de problemas de Handover baseado em medições estatísticas

l As estatísticas de tráfego são uns dos mais importantes dados para avaliar a performance da rede

l Os dados de estatísticas de tráfego de handover incluem dados orientados àRNC que refletem a performance da rede como um todo, e dados orientados a célula

l O fluxo de análise para SHO, HHO, inter-RAT handover e HSDPA handover é similar, mas os indicadores de estatísticas de tráfego são diferentes




l Fixar o benchmark de performance de handover

40%Stat.N/ASHO cost

92%DT&Stat.PS handover out

95%DT&Stat.Voice handover outInter-RAT handover success rate




90%DT&Stat.VP

92%DT&Stat.Voice

Inter-frequency HHO success rate




85%DT&Stat.VP

90%DT&Stat.Voice

Intra-frequency HHO success rate

99%DT&Stat.CS&PSSHO success rate

Reference valueStatistics methodServiceIndex

Resolução de problemas de Handover baseado em medições estatísticas




Fluxo de Otimização de SHO baseado em estatísticas de tráfego

l A taxa de sucesso de SHO é definida abaixo:

SHO SHO successsuccess rate = SHO rate = SHO successfulsuccessful times/SHO times/SHO requestrequest timestimes

l Verificar a taxa de sucesso de SHO da rede inteira na hora de maior movimento.

l Ordenar os instantes de falha de SHO na célula através do TOP N e localize as células com TOP N instantes de falha

l Checar as causas específicas dos problemas de SHO

l Faça o DT para encontrar as causas específicas em cada célula




l As estatísticas de HHO incluem as taxas de sucesso de HHO originados e terminados :

[[OutgoingOutgoing HHO HHO SuccessSuccess Rate = Rate = OutgoingOutgoing HHO HHO SuccessSuccess Times / Times / OutgoingOutgoing HHO TimesHHO Times

[[ IncomingIncoming HHO HHO SuccessSuccess Rate = Rate = IncomingIncoming HHO HHO SuccessSuccess Times / Times / IncomingIncoming HHO TimesHHO Times

Fluxo de Otimização de HHO baseado em estatísticas de tráfego




l A taxa de sucesso de Inter-RAT handover inclui a taxa de sucesso para voz e OS

[[ VoiceVoice InterInter--RAT RAT OutgoingOutgoing Handover Handover SuccessSuccess Rate = Rate = VoiceVoice InterInter--RAT RAT OutgoingOutgoing Handover Handover SuccessSuccess Times / Times / VoiceVoice InterInter--RAT RAT OutgoingOutgoing Handover Handover TrialTrial TimesTimes

[[ PS InterPS Inter--RAT RAT OutgoingOutgoing Handover Handover SuccessSuccess Rate = PS InterRate = PS Inter--RAT RAT OutgoingOutgoingHandover Handover SuccessSuccess Times / PS InterTimes / PS Inter--RAT RAT OutgoingOutgoing Handover Handover TrialTrial TimesTimes

[[ PS InterPS Inter--RAT RAT TerminatingTerminating Handover Handover SuccessSuccess Rate = PS InterRate = PS Inter--RAT RAT TerminatingTerminating Handover Handover SuccessSuccess Times / PS InterTimes / PS Inter--RAT RAT TerminatingTerminating Handover Handover TrialTrial TimesTimes

Fluxo de Otimização de HHO baseado em estatísticas de tráfego





3.1 An3.1 Anáálise de Problemas de SHOlise de Problemas de SHO

3.2 An3.2 Anáálise de Problemas de HHOlise de Problemas de HHO




Análise de Problemas de SHO

l Taxa de sucesso de SHO baixa

[ Se a taxa for menor que 98%, significa que está baixa

[As razões podem ser:

− Problemas de cobertura

− Pilot pllution

− Parâmetros impróprios

▪ 1A, 1B, 1C, 1D

▪ Time to trigger

▪ CIO





l Alta porcentagem de SHO

[ A porcentagem deve ser mantida entre 30 e 40%

[ As razões podem ser:

− Problemas de cobertura – overshoot

− Parâmetros impróprios

▪ Limiares 1A e 1B

▪ CIO

− Método de planejamento inadequado

▪ Alto tráfego na área de SHO





l Queda de chamada no SHO

[ Problema de RF

− Problema de cobertura

− Pilot pollution

[ Lista de vizinhas incompleta

[ Parâmetros Impróprios

− Limiares 1A e 1B

− Time to trigger

− CIO





l Desbalanceamento de cobertura entre uplink e downlink

[ Interferência externa e pilot pollution podem influenciar na cobertura de uplink e downlink

[ A decisão de Soft handover é baseada na qualidade do canal de downlink CPICH. Neste caso, pode ocorrer queda de chamada por causa da falta de sincronismo de uplink

A B

Uplink coverage

Downlinkcoverage




CapCapíítulotulo 3 3 AnAnááliselise de de ProblemasProblemas de de HandoverHandover

3.1 3.1 AnAnááliselise de de ProblemasProblemas de SHOde SHO

3.2 3.2 AnAnááliselise de de ProblemasProblemas de HHOde HHO




Análise de Problemas de HHOl Falha no modo comprimido

[ Inter-frequency handover e inter-RAT handover

[ Sem reporte de medida (2D)reporte de medida (2D) do UE

− Limiares inadequados para o modo comprimido

▪ 2D

▪ 2F

[ Sem PhysicalPhysical channelchannel reconfigurationreconfiguration complete (complete (CompressCompress modemode))

− Método domodo comprimido inadequado

▪ SF/2

▪ Puncionamento

▪ Agendamento em camadas superiores

▪ Nem todos os UEs podem suportar estes 3 modos comprimidos, mas todos devem suportar obrigatoriamente o primeiro




Análise de Problemas de HHOl Falha no modo comprimido

[ Inter-frequency handover e inter-RAT handover

[ Ping-pong compress mode

− Parâmetros inadequados

− A diferença entre 2D e 2F é muito pequena




Análise de Problemas de HHO

l Sem PhysicalPhysical ChannelChannel ReconfigurationReconfiguration (HHO (HHO IndicationIndication))

[ Inter-frequency hard handover e inter-RAT hard handover

− Sem PhysicalPhysical channelchannel reconfigurationreconfiguration (handover)(handover) ou Handover Handover fromfrom UTRAN to GSMUTRAN to GSM

▪ Parâmetros inadequados

» 2B, 2C» 3A, 3C





l Sem PhysicalPhysical ChannelChannel ReconfigurationReconfiguration (HHO (HHO IndicationIndication))

[ Intra-frequency hard handover é disparado pelo evento 1D

− Se o UE reporta evento 1D

▪ Verificar a habilitação do algoritmo “intra-frequency hardhandover”

▪ Falha de estabelecimento de link das interfaces Iur ou Iub

− Se não há reporte de evento 1D do UE

▪ Verificar a lista de vizinhas

▪ Parâmetros de evento 1D inadequados

▪ Verificar a SC nas RNCs fonte e destino





l Falha no recebimento de PhysicalPhysical ChannelChannel ReconfigurationReconfiguration

[ Parâmetros inadequados

− limiares, hysteresis ou time-to-trigger

[ Aumentar a potência de transmissão de downlink máxima

l Falha em receber PhysicalPhysical ChannelChannel ReconfigurationReconfiguration CompleteComplete

[ Aumentar a cobertura do link

[ Diminuir a interferência do link

[ Aumentar a potência de transmissão no uplink máxima, se possível





l Handover ping-pong

[ Parâmetros de handover inadequados

− Aumentar o limiar de decisão de handover, considerando os efeitos colaterais

− Ajustar o sistema para o ambiente de transmissão para diminuir flutuações do sinal





l Outros Problemas

[ Capacidade do UE

− Por exemplo, alguns UE podem não suportar intra-frequency hardhandover

[ Compatibilidade de Equipmentos.

− Especialmente quando o HHO precisa de cooperação entre diferentes elementos de rede de diferentes fabricantes

[ Problemas de Transmissão




CapCapíítulo 4 Casos de problema de tulo 4 Casos de problema de handoverhandover

4.1 An4.1 Anáálise de casos de SHOlise de casos de SHO

4.2 An4.2 Anáálise de casos de HHOlise de casos de HHO




SHO caso 1l Descrição

[Dados de DT data – trace de sinalização

Queda de chamada Após a queda na chanada,

inicia a leitura das informações do sistema




SHO caso 1

l Análise de Dados

[ Verificar a informação de célula do conjunto ativo do UE e informação de célula do scanner nos pontos de queda de chamada.

Do scanner Do UE

No SC 170 cell!!

Why?




SHO caso 1

l Análise de dados

[Verificando o conjunto de monitoração

[Lista de vizinhas inadequada

[handover atrasado

Check monitor set for the scramble measured

by scanner

SC 170 is not in monitor set, so the cause is probably missing neighbor cell




SHO caso 1l Análise de dados

[Verificar o último measurementmeasurement controlcontrol

Search for the latest intra-frequency measurement control

Call drop point




SHO caso 1

Measurement ID is 1. It is Intra-frequency measurement control

Check the list of intra-frequency neighbor cell in measurement

control and no SC 170

The primary scramble of the cell is 6




SHO caso 1

l Solução

[ Adicionar células vizinhas na lista de vizinhas




SHO caso 1

l Se somente o UE gravou a informação durante o teste, sem informação de scanner, confirme que aquela queda de chamada é devida a lista de vizinhas inadequada, usando o seguinte método:

Check the cell where UE camps on after cell

selection and reselection

The UE camps on the cell of SC 170, which is inconsistent with the primary pilot before call drop, so

the call drop is probably due to missing neighbor cell

After call drop, UE read system information




SHO caso 2

l Descrição

[ A figura mostra que há pilot pollution perto de Yuxing Rd.

[ A célula SC270 deveria atender à area com pilot pollution




SHO caso 2

l Análise de dados

[ A figura mostra a Best Service Cell próxima a Yuxing Rd




SHO caso 2

l Análise de dados

[ A figura mostra a 2ª Best Service Cell próxima a Yuxing Rd




SHO caso 2

l Análise de dados

[ Analisando a distribuição de sinal de células próximas ao ponto de pilot pollution





SHO caso 2

l Análise de dados





SHO caso 2lAnálise de dados

[Composição de poluição de piloto próximo a Yuxing Rd

[ Apesar da célula SC270 ter sido planejada para cobrir a área, a BestService Cell está listada na tabela

SC2004th best Service Cell

SC2003rd best Service Cell

SC2702nd best Service Cell

SC2201st best Service Cell

SCBest Service Cell




SHO caso 2

l Analisando as distribuições de RSSI e RSCP próximas ao ponto de pilotpollution

l Como mostrado à esquerda da figura, o RSSI da área de poluição não é grande, cerca de -100dBm a -90dBm.

l Como mostrado à direita da figura, o RSCP da Best Service Cell está entre -105dBm a -100dBm.

l A área de poluição de piloto não é causada por piloto dominante




SHO caso 2

l A figura mostra o RSCP da célula SC270 próxima a Yuxing Rd

l A figura mostra a distribuição RSCP da célula SC270. Os sinais da célula SC270 são fracos na área de poluição de piloto




SHO caso 2

l Solução

[ Ajuste o azimute da célula SC270 de 150°a 130°e o down tilt de 5°para 3°. Isto aumenta a cobertura da célula SC270

l Confirme

[ Após a analise de dados de DT, a área é dominada por SC 270. E se a pilotpollution desaparece




SHO caso 2

l A figura mostra pilot pollution próxima a Yuxing Rd. após a otimização

RSCP da Best Service Cell próximaa Yuxing Rd. antes da otimização

RSCP de SC270 próxima a Yuxing Rd. apósotimização




SHO caso 3

l Descrição

[ Várias quedas de chamada aconteceram durante a otimização de RF

[ Da figura, o local de queda de chamada é uma esquina





[ De acordo com a figura, os sinais do activeactive setset scramble 104 e 168 diminuíram -17 dB antes da esquina. Mas a célula SC208 é muito boa, em torno de -8 dB





[ O trace de sinalização no RNC mostra que o UE reporta eventoevento 1A 1A para a SC 208208. Então, o RNC manda o activeactive set set updateupdate. Mas o UE não consegue recebê-lo




SHO caso 3l Este é um caso típico do “efeito esquina”, e a solução pode ser

[Ajustar os parâmetros de evento 1A

− Diminuir o time to trigger

− Diminuir o threshold

− Efeitos colaterais

[Ajuste do CIO

− Aumentar CIO da célula servidora

− Efeitos colaterais

[Otimização de RF

− Ajustar a antena para evitar flutuação de sinal




l Conclusão

[Do DT, o fenômeno típico para ‘efeito esquina’ pode ser visto na figura

[ O sinal da célula servidora diminui acentuadamente enquanto o inverso ocorre com a célula candidata. Entretanto, a queda de chamada acontece por causa do UE não receber o activeactive set set updateupdate.

SHO caso 3




SHO caso 4

l Efeito “needlepoint”

− O sinal da célula servidora diminui acentuadamente, e volta ao normal rapidamente

− Dentre os procedimentos de sinalização, acontecem os eventos 1B e 1A

− A figura mostra a flutuação de sinal no needlepoint effect””

Needle point-signal variance




SHO caso 4l Efeitos “needlepoint” e “corner”

[ Needlepoint pode não causar queda de chamada

− Needlepoint tem curta duração, e esta pode não ser suficiente para disparar um handover.

− Causa deterioração de QoS

[ Corner causa queda de chamada

− Não consegue recuperar o sinal da célula servidora




SHO caso 4

l O efeito “needlepoint” causa queda de chamada nas seguintes situações:[ Se o needlepoint não consegue satisfazer o handover

− Queda de chamadas pode não acontecer, mas ocorre deterioração de QoS, como alta BLER

− Alta BLER causa TRB reset, e assim a chamada cai

[ Se o needlepoint satisfaz o handover

− O sinal da célula servidora deteriora, e o UE não pode receber oactiveactive set set updateupdate , e assim a chamada cai

− O segundo handover no needlepoint pode causar queda de chamada

▪ No 1º handover, a célula servidora é apagada do active set. Mas ela será adicionada no active set imediatamente.




SHO caso 4

l Solução

[ Otimização de RF

− Evitar que a célula servidora tenha seu sinal deteriorado acentuadamente

[ Aumentar o tempo de retransmissão de RLC




CapCapíítulo 4 Casos de problema de tulo 4 Casos de problema de handoverhandover

4.1 An4.1 Anáálise de casos de SHOlise de casos de SHO

4.2 An4.2 Anáálise de casos de HHOlise de casos de HHO




HHO caso 1

l Descrição

[o UE vai para uma célula inter-frequency ocorre falha no handover.

[Acampa na célula inter-frequency após a desconexão

l Análise

[Do procedimento de sinalização verifica-se que a desconexão aconteceu no modo comprimido.

[O UE não inicia o modo comprimido

[Verificar o MeasurementMeasurement reportreport..

[O indicador nos eventos 2D e 2F indicador é o Ec/Io




HHO caso 1

l O Ec/Io do canal piloto (CPICH) depende de:

[Intensidade de CPICH RSCP

[Interferência de Downlink

[A relação entre Ec/Io e RSCP pode ser representada na figura:

d

Ec/N0

RSCP




HHO caso 1

l Solução

[ Mudar os indicadores de reporte de eventos 2D e 2F para RSCP

[ Confirmar após o ajuste, se o UE inicialisa o modo comprimido corretamente

l Conclusão

[ No centro da cobertura de uma dada portadora, os indicadores de eventos 2D e 2F são Ec/Io

[ Na borda da área de cobertura, os indicadores de reporte de eventos 2D e 2F são RSCP




HHO caso 2

l Descrição de Problema

[Em uma área de redes WCDMA e GSM, um CS inter-systemhandover pode ser feito com sucesso, mas um PS inter-systemhandover falha.

[O procedimento de sinalização correspondente é dado abaixo.




HHO caso 2

l Procedimento de CS handover:




HHO caso 2

l Procedimento de PS handover:




HHO caso 2

l Análise

l Resultado

l Conclusão



www.huawei.com

Obrigado


http://www.huawei.com


18 wcdma análise de problemas de handover

Engineering

Transcript of 18 wcdma análise de problemas de handover