Omf000405 alálise de casos congestionamento versão1.4

www.huawei.com

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

Estudo de Casos - Congestionamento


Referências

31160978-BSC Traffic Statistic Manual Volume I

31033203-BSS Troubleshooting Manual


Objetivos

Ao completar esse curso você estará apto a:

Compreender os princípios de congestionamento

Analisar e resolver problemas de congestionamento


Conteúdo

1. Congestionamento de TCH

2. Congestionamento de SDCCH


Congestionamento de TCH


Princípios Básicos

Causas para um alto congestionamento de TCH

Estudo de caso – Congestionamento de TCH




Definição de Taxa de Congestionamento de TCH

Pontos de medida para análise de congestionamento

de TCH



Definição da Taxa de congestionamento de TCH

Taxa Congestionamento de TCH (excluindo handover)

=(TCH seizure failures for call + TCH seizure failures

for very early assignment) / (Attempted TCH seizures +

Attempted TCH seizures for very early assignment)

*100%



Definição da Taxa de congestionamento de TCH

Taxa de congestionamento de TCH (incluindo handover)

=(TCH seizure failures for call + TCH seizure failures for

very early assignment + TCH seizure failures para

handover de células intraBSC (falta de recursos de radio) +

TCH seizure failures para handover de células interBSC

(falta de recursos de radio) ) / (Attempted TCH seizures

(all) + Attempted TCH seizures for very early assignment +

Attempted TCH seizures para handover de células intraBSC

+ Attempted TCH seizures for interBSC)



Channel_ActiveChannel_Active_Ack

IMMEDIATE ASSIGN COMMAND

BTS BSC MSCMSChannel_Req

first SABM Establish_IND( CM Service Req)CR(Complete_l3_information)

CC

SetupCall Proceeding

Assignment_Req

ASSIGNMENT COMMANDfirst SABM Establish_IND

ASSIGNMENT CMP Assignment_CMPAlertingConnect

Connect AckCommunication

DisconnectRelease

Release CompleteClear_CMDClear_CMP

CM Service Accepted

Channel_Active

Channel_Active_Ack

UA

SDCCHSDCCH

SACCH(TCH)SACCH(TCH)

MS call flow as the caller

Pontos de medida

de Tráfego para

análise da taxa de

congestionamento

de TCH



Ponto de medida - Attempted TCH seizures Attempted TCH seizures para chamada

Recebe a mensagem assignment request da MSC

Attempted TCH seizures para very early assignment

Quando não há recursos para alocação de SDCCH e é permitido o

very early assignment.

Quando a solicitação de canal é recebida e o tipo de canal é TCH

Attempted TCH seizures para handover intraBSC

Quando a mensagem de solicitação de handover intraBSC é recebida

(non-SDCCH handover request).

Attempted TCH seizures para handover interBSC

Quando a mensagem de solicitação de handover interBSC é recebida

(handover type is non-SDCCH)



Falhas de TCH seizure:

TCH seizure – falha na chamada,

TCH seizure – falha no very early assignment,

TCH seizure – falha no handover interBSC,

TCH seizure – falha no handover intraBSC,

TCH seizure – falha no handover entre células.



Ponto de medida – Falha de TCH seizure na

chamada: (1)CONN_FAIL mensagem recebida no procedimento de assignment.

(2)CLEAR_CMD recebida no processo de saída da BSC durante o handover. A

causa é o Direct Retry.

(3)CLEAR_CMD recebida no procediemento de assignment.

(4)RR_ABORT_REQ recebida no procedimento de saída da BSC durante o

handover e a causa do handover é um direct retry.

(5)RR_ABORT_REQ recebida no procedimento de assignment.

(6)MSG_HO_REQ_REJ recebida no processo de saída da BSC durante o

handover (direct retry).



Ponto de medida – Falha de TCH seizure na chamada

: (7) HO_FAIL mensagem recebida na saída da BSC durante um handover

(direct retry).

(8) ERR_IND recebida no procedimento de assignment.

(9) Quando a mensagem de assignment failure é enviada.

(10)TN_T7 (direct retry) timeout (outgoing BSC handover request)

(11)TN_T8 (direct retry) timeout (outgoing BSC handover complete)



Ponto de medida – falha de TCH seizure para very

early assignment: (1)CH_ACT_NACK é recebida no processo de very early TCH assignment.

(CH_ACT_NACK é recebida no status WAIT_RR_EST em transmissão BTS via

satélite)

(2) No processo very early TCH assignment, a causa do retorno é (erro interno)

CVI_INTERNAL_ERR quando o canal está sendo alocado.

(3) No processo very early TCH assignment, a causa do retorno é (requisição

de canal ilegal) CVI_NO_ACCEPT quando o canal está sendo alocado.

(4) No processo very early TCH assignment, nenhum canal é alocado.

(5)TN_WAIT_CH_ACT timeout no processo very early TCH assignment.



Ponto de medida - Falha de TCH seizure para

handover intraBSC:

Falha de alocação de TCH no handover intraBSC

Ponto de medida – Falha de TCH seizure para

handover interBSC:

Quando não há TCH disponível a mensagem interBSC

incoming cell handover failure é enviada.



Ponto de Medida – Falha de TCH seizure para handover intra célula:

No novo procedimento de ativação de TCH, este item é medido quando a célula servidora recebe a mensagem CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE da BTS.

Este item é medido se a implementação do procedimento de handover intra célula falha devido ao algoritmo de encriptação na mensagem Intracell Handover Request não ser suportado.

Sem resposta ao final da contagem do temporizador (timer interno de 5 seconds) quando a célula servidora ativa o novo TCH.

No procedimento de handover intra célula, quando há solicitação de TCH mas não há TCH disponível na célula servidora e isso leva à falha do handover. Neste caso este item é medido



Ponto de medida - falha de TCH seizure devido a

falhas na interface A:

Interface A Após o envio da mensagem Assignment_Req pela MSC, se houver falha

nos circuitos de tronco da interface A a BSC irá retornar

Assignment_Failure diretamente.

Neste caso, geralmente a causa é a incorreta designação dos circuitos de

tronco (CIC).



Falhas de TCH seizure devido a falhas nas interfaces

Abis e Um:

Interfaces Abis e Um 1. Falha da placa de TRX ou instabilidade de performance

2. Nível de desbalanceamento entre uplink/downlink na BTS

3. Baixa qualidade de sinal de uplink/downlink devido a interferência

4. SDCCH e TCH pertencentes a diferentes TRX que realizam diferentes

coberturas


Causas para um alto congestionamento de TCH Causas

Manutenção


Causas para um alto congestionamento de TCH Causas para uma alta taxa de congestionamento de

TCH: Configuração incorreta dos circuitos de entroncamento da interface A

Falhas no handover provocadas por Co-freqüência e co-BSIC, levando a um TCH

assignment failure

Falha ou instabilidade em placas de circuito

Hardware da BTS não instalado corretamente, provocando desbalanceamento

entre sinais de uplink/downlink.

Potência de transmissão do TRX de BCCH muito superior à potência de

transmissão dos TRX de TCH da mesma célula

Nível de interferência

TCH assignment failure devido a topografia e isolamento do site.



Como localizar as causas para a alta taxa de

congestionamento de TCH

Analisando as causas de congestionamento

remotamente

1. Estatísticas de Tráfego

2. Informações de Alarme

3. Manutenção da BTS remotamente através do OMC

4. Análise de mensagens na interface Abis

Verificação da BTS on-site


Congestionamento de TCH Análise Remota 1: Estatísticas de tráfego

Em “TCH Measurement Function”, verifique se os

canais estão todos ocupados ou não Se sim, realize um load handover ou sugira expansão da capacidade.

Se não, verifique as bandas de interferência 1~5. Se constatada a

interferência, a taxa queda de chamadas na célula provavelmente será

alta também.

Registre uma “Receiving Level Measurement Function” 1. Verifique o resultado por objeto e veja quando os números dos relatórios

para uplink e downlink estão balanceados em uma mesma placa TRX.

2. Verifique o resultado por tempo para ver quando as medidas nos

relatórios são elevados. Desta forma pode-se verificar se o

congestionamento está relacionado à placa TRX ou não.



Análise Remota 2: informações de alarme Verifique se os alarmes do site que possui alta taxa de congestionamento.

Verifique quando existem alarmes, tais como alta VSWR, perda de sincronismo

de quadro PCM e alarme de barramento de dados de uplink. Julgue quando a

taxa de congestionamento está associada com esses alarmes nas estatísticas

de tráfego.



Análise Remota 3: Manutenção remota da BTS no

OMC No console de manutenção remota da BTS realize o bloqueio de TCHs e

observe se o congestionamento está relacionado à placa TRX sob análise.



Análise Remota 4: Análise de mensagens na interface

Abis.

Realize um trace nas mensagens da interface Abis da BTS

em congestionamento e analise o Assignment CMD enviado

no SDCCH Se o assignment sempre resulta em falha para um TRX específico, a causa mais

provável pode ser uma das seguintes:

– Falha ou instabilidade na placa TRX

– Desbalanceamento ou problema de hardware no Uplink/downlink

– Baixa qualidade dos sinais de uplink ou downlink. Analise o valor do TA da MS para

identificar o problema.

Se o assignment falha em todas as placas referentes à célula, de forma aleatória,

analise o relatório de medições. As causas podem ser as seguintes:

– Problema relacionado com a topografia na região de cobertura da célula (complicado)

– Existe interferência em toda a célula, tais como problemas com repetidores.


Congestionamento de TCHCongestionamento de TCH



Verificação da BTS on-site Verificar as condições das antenas e cabos de RF na busca por anomalias.

Realize chamadas de teste para o mesmo local e monitore para verificar se as

falhas de assignment ocorrem para um certo TRX ou toda a célula de forma

aleatória.

Realize um drive test para verificar se existem anomalias relacionadas com o

procedimento de handover e interferências no downlink.

Procure por fontes de interferência utilizando um analisador de espectro.

Observe se a topografia na área de cobertura da célula é complexa.


Estudo de Casos – Congestionamento de TCH

Casos de congestionamento de TCH

Caso 1: Erro na configuração da Interface A

Caso 2: Falha na placa TRX

Caso 3: Problema de hardware no uplink

Caso 4: Problema de hardware no downlink

Caso 5: Efeitos do repetidor na célula

Caso 6: Outros erros de configuração

Caso 7: Site isolado e topografia complexa


Erro na configuração da Interface A Caso 1 – Descrição da falha:

Na rede local existe uma BSC. A partir de um certo dia foi constatado que a

taxa de congestionamento de TCH (excluindo handover) de toda a rede

aumentou 4% e que a maioria das células estavam com nível de

congestionamento elevado.


Erro na configuração da Interface A Caso 1 – Análise:

Desde que as freqüências dos sites não haviam sofrido alterações, foi

descartada a possibilidade de problemas na interface Um.

A taxa de congestionamento estava anormal para a maioria das BTS. Neste

caso, devemos analisar em uma escala menor a procura de problemas

relacionados a um certo módulo ou modificações realizadas na base de dados.

Analisar a causa principal de TCH seizure failure através das estatísticas de

tráfego e finalmente localizar o problema (seja ele causado por configuração

de dados ou hardware).


Estudo de Casos – Congestionamento de TCH Caso 1 – Manutenção:

1.Análise das estatísticas de tráfego. O problema ocorreu após alteração de dados na BSC. Pode ser que esteja relacionado ao procedimento de recarga da base de dados na BSC.

Analise as estatísticas de tráfego e procure por congestionamentos em células de um módulo específico da BSC (células do módulo 1, 2, ...).

Verifique se as TCH seizure failures (requested terrestrial resource unavailable). Isso demonstra que a falta de recursos é a principal causa do alto congestionamento do módulo sob análise.

A causa para terrestrial resources unavailability é relacionada principalmente às interfaces A e Abis. É pouco provável que a interface Abis seja responsável por falhas de diversas células ao mesmo tempo em um mesmo módulo, portanto podemos voltar a atenção para o hardware e a configuração de dados da interface A deste módulo.



Caso 1 - Manutenção: 2.Verificando o hardware da Interface A, constatou-se que não havia

problemas com este, portanto, hardware excluído da análise.

3. Verificando a configuração de dados da interface A, descobriu-se que o

código CIC dos primeiros 32 timeslots do grupo 0, módulo 1 estava em

“65535”. Entretanto, o grupo 0 do módulo 1 na tabela de grupos de tronco

corresponde aos circuitos de conexão entre BSC e MSC. Sendo assim, o CIC

correspondente deve estar na faixa de 0 a 31. Realizando a alteração o

sistema voltou a operação normal (sem congestionamento).



Caso 1 - Conclusão: 1. Na configuração de dados de entroncamento da interface A o CIC deve estar

correto, caso contrário poderá ocorrer problemas na alocação de TCH gerando

altas taxas de congestionamento.

2. Observe ainda que se o CIC de duas placas FTC (múltiplos circuitos de

tronco) são iguais, o problema citado também ocorrerá.


Falha na placa TRX

Caso 2 – Descrição da falha: A configuração da BTS e S6/4/2 e esta foi colocada em serviço corretamente.

Certo dia, o resultado das estatísticas de tráfego apontaram que a taxa de

congestionamento de TCH na célula 1 (6 TRXs) subiu para 20%.

O volume de tráfego da célula é baixo, da ordem de 0.8 Erl na hora de maior

tráfego.

Ao mesmo tempo, o número de “TCH seizure failures for call (no radio

resource)” é 0.

Observou-se que o estado dos todos canais na célula 1 = “idle”.


Falha na placa TRX

Caso 2 – Análise: 1. Nenhuma configuração de dados fora efetuada e não existe hopping na

célula. Os 6 TRXs utilizam freqüências diferentes, o que descarta a existência

de interferência externa ao mesmo tempo, ou seja não deve ser problema com

a interface Um.

2. Verificando o Hardware... Desde que o problema apenas ocorre na célula 1,

pode-se bloquear os TRXs um a um e determinar qual o TRX está relacionado

com o assignment failure.

3. Descobrindo o TRX relacionado com a falha, tente localizar a falha no TRX

que pode ser relacionada com o assignment faiIlure. Confirme se a falha

persiste após um reset e substitua o TRX.


Falha na placa TRX

Caso 2 - Manutenção: 1. Verificando o estado dos BT channels através do OMC verificou-se a

possibilidade de haver TCH seizure failure no BT4 da célula 1.

2. Bloqueando o TRX4, não foi constatado problema de congestionamento

durante todo o dia, o que indica o problema com o TRX4.

3. Desbloqueando e reiniciando o TRX4, o problema ressurge.

4. Indo ao site da BTS sob análise e realizando a chamada de teste, constatou-

se que o problema ainda persiste. Realizando a troca das placas entre TRX4 e

TRX5, o teste de chamada aponta problemas no TRX5.

5. Substituindo a placa TRX identificada como problemática, o sintoma

desapareceu.


Falha na placa TRX

Caso 2 – Conclusão: 1.Falha na placa TRX provoca alta taxa de congestionamento e TCH seizure

failures.

2. Geralmente um problema de placa pode não ser identificado através do

console de manutenção da BTS, entretanto o problema pode ser confirmado

através do bloqueio dos TRX sob suspeita.


Problema de hardware no uplink

Caso 3 – Descrição da Falha: Em uma BTS configurada como S6/6/6, a taxa de congestionamento de 3

células estava elevada desde o início de operação do site. Havia sido

constatado que não existia problemas de interferência.



Caso 3 - Análise:

Verificando o hardware da BTS a procura de falhas: Falha de hardware: a comunicação estava normal para todas as células,

portanto descartada a possibilidade de falha de hardware para as mesmas.

Conexões de hardware: analise as estatísticas de tráfego para o uplink e o

downlink, verificando também as conexões para ambas as direções.



Caso 3 - Manutenção: Foi registrada uma “Receiving Level Measurement Function” e feita uma busca de

resultados em função da quantidade. Descobriu-se que o nível de recepção e a

qualidade do sinal de diferentes TRX de uma mesma célula eram semelhantes

entre si, porém as medidas apontadas pelo relatório de uplink divergiam.

Foi feita uma verificação no hardware e foi encontrado um problema de conexão

entre o TRX e a CDU. Após alterar a conexão para a correta posição, o problema

foi resolvido.


14258222 16646294 293105655

501

303 702

Times of uplink receiving level rank 0 and receiving quality rank 0

Times of uplink receiving level rank 0 and receiving quality rank 1

Times of Uplink receiving level rank 0 and receiving quality rank 2

30 minutes starting from 11:00 18-3-2001 Module ID 1, Cell ID 5, TRX No. 12Module ID 1, Cell ID 5, TRX No. 13

Module ID 1, Cell ID 5, TRX No. 14




Problema de hardware no uplinkProblema de hardware no uplink

Caso 3



Caso 3 - Conclusão: A causa da “TCH seizure failure” foi provocada por problemas de conexão do

hardware. Tal problema pode ser localizado de forma precisa através da

análise de estatísticas de tráfego. Neste caso o problema de recepção na via

de uplink foi encontrado através da “Receiving Level Measurement Function”.


Problema de hardware no Downlink Caso 4 – Descrição da Falha:

Certo dia uma BTS S6/6/5 apresentou uma alta taxa de congestionamento.

Nenhum tipo de ajuste havia sido realizado neste período.


Problema de hardware no Downlink Caso 4 - Análise:

Anteriormente a falha, nenhum tipo de intervenção havia sido executado no

site em questão, portanto o foco para início da análise apontava para

problemas de hardware. Partiu-se então à procura de alarmes e falhas.


Problema de hardware no Downlink Caso 4 - Manutenção:

Realizando um trace na interface Abis da BTS e analisando a sinalização, foi verificado que no processo de TCH seizure failure, o sinal de uplink no relatório de medidas da MS estava normal. Após o envio de ASSIGNMENT CMD pela BSC, o canal de downlink não podia ser alocado. Verificou-se portanto que os níveis de uplink e downlink estavam desbalanceados, já que a mensagem ASSI FAILURE foi apresentada no trace. A falha portanto foi identificada como relativa ao último TRX da célula.

Bloqueando o TRX, a taxa de congestionamento caiu para menos de 1%. Confirmado portanto o problema de hardware do TRX, relacionado com o downlink.

Observando as informações de hardware, foi constatado que o VSWR do conjunto TX Antena e cabos da placa sob análise estava acima de 2.5.

Realizando a devida manutenção no subsistema de RF o problema foi resolvido.


Problema de hardware no Downlink Caso 4 - Conclusão:

Alarmes de VSWR indicam que problemas mais sérios aparecerão, como

problemas de cobertura e problemas na designação de canais. Quando uma

MS está sob a cobertura de um TRX com BCCH e o sinal é bom o suficiente

para a troca de sinalização, mas após a designação de um TCH, este se

encontra em uma placa com alto VSWR, falhas de “TCH seizure” e taxas de

congestionamento surgirão com valores elevados.


Efeitos do Repetidor na Célula

Caso 5 – Descrição da falha: Durante a expansão de uma BTS O2 para O4, foi verificada uma alta taxa de

congestionamento. O valor de pico chegou a 40%.


Efeitos do Repetidor na Célula Caso 5 - Análise:

Como o congestionamento apareceu após a expansão: Verificou-se a ocorrência para todos TRX. Caso a verificação fosse positiva,

uma reavaliação das conexões do novo hardware da BTS seria necessária

para localização de falhas.

Caso o problema apontasse para um ou poucos TRX, apenas esses seriam

alvo de análise de hardware.

Excluindo-se o problema de hardware no site, causas externas passam a

ser alvo de investigação. Por exemplo, um repetidor que não sofreu a

devida expansão foi o causador dos problemas de assignment failure.



Caso 5 – Manutenção: Bloqueando os dois últimos TRX do site através do OMC, verificou-se que a

taxa de congestionamento se reduzia para valores normais. Sendo assim, o

problema fica caracterizado na operação de expansão do site.

Analisando a sinalização da interface Abis, a ocorrência de assignment failure

se dá somente com a presença dos rádios adicionados ao site. A análise do

relatório de medidas de SDCCH demonstrava que o nível no SDCCH estava

normal e que o valor de TA era alto. Entretanto não havia relatório de medidas

no SACCH (TCH). Devido ao fato de algumas vezes a designação desses 2 TRX

obter sucesso, foi descartada a possibilidade de os dois TRX novos

apresentarem problemas.

O operador informou a existência de um repetidor na célula. Devido a

expansão do site, o repetidor não estava configurado para suportar esses dois

novos TRX. Reconfigurando o mesmo, o problema foi resolvido.



Caso 5 - Conclusão: Devido a existência do repetidor no site, a área de cobertura original dos TRX

existentes era diferente da cobertura após a expansão, o que resultava em

assignment failure.


Outros erros de configuração

Caso 6 – Descrição da falha: Na otimização da rede, a taxa de congestionamento (incluindo handover) nas

horas de maior tráfego atingia 10% para duas células. As “TCH seizure failures

excluding handover” e “TCH seizure failures for call (no radio resource)”

estavam normais. Neste caso a “TCH seizure failures (all)” indicava 89, mas

as “TCH seizure failures for MOC” indicavam 0.

O volume de tráfego era um pouco inferior ao volume anterior a otimização.

A interferência estava normal.

A taxa de congestionamento anterior a otimização estava normal.



Caso 6 - Análise: Quando os parâmetros de rede foram modificados a taxa de

congestionamento de duas células se elevaram, entretanto apenas para

congestionamento incluindo handover. Sendo assim problemas de hardware

ou interferência de rádio puderam ser descartadas. Neste caso, a análise se

restringe a verificação do handover (se normal ou não).



Caso 6 – Manutenção: Registrando uma “Incoming Inter Cell Handover Measurement Function”

durante 15 minutos e procurando por falhas de handover da célula A

(CGI=×××××××××1768) para essas duas células, foi verificado se a causa

era congestionamento ou não.

Falhas para todos os handovers significa que existe problema com a

configuração de dados de handover. Verificando esses dados, constatou-se

que havia “co-freqüência” e “co-BSIC”. As duas células eram adjacentes à

célula A, portanto o handover para as duas células falhavam.

Alterando o BCCH e o BSIC de uma das células o problema de handover foi

solucionado, desaparecendo também o problema de congestionamento.



Caso 6 - Conclusão: Duas células, ambas adjacentes à célula A com “co-freqüência” e “co-BSIC”

resultavam em baixa taxa de sucesso de handover e também alta taxa de

congestionamento de TCH incluindo handover.

Este caso indica que as taxas de congestionamento de TCH com e sem

handover eram diferentes.


Site isolado e topografia complexa

Caso 7 – Descrição da falha:

Um site do tipo O2 em uma área suburbana sofria de

alta taxa de congestionamento (excluindo handover),

variando de 3 a 10% (na proporção do volume de

tráfego). Entretanto as “TCH seizure failures for call (no

radio resource)” indicavam 0%. 1. Bloqueando os 2 TRX (um por vez), a taxa de congestionamento não se

alterava significativamente.

2. Outros índices: a taxa de call drop estava em 5% e a interferência

apresentava valores normais.



Caso 7 - Análise: 1. Uma vez que a taxa de congestionamento não estava tão elevada, o

problema poderia não estar relacionado com falha de hardware ou

configuração de dados.

2. Se a banda de interferência apresentava valores normais, a interface Um

também foi descartada como fonte de problemas.

3. Analisando a causa do assignment failure a taxa de queda de chamadas foi

considerada juntamente com a performance do uplink e downlink no que se

refere ao nível e qualidade dos mesmos.



Caso 7 - Manutenção: Verificando a “Call Drop Measurement” e o valor sabendo que o valor de TA

era elevado quando ocorria a queda da chamada, descobriu-se que a distância de comunicação era de 25.6 a 31Km da BTS.

Analisando a “Receiving Level Measurement Function” descobriu-se que haviam várias medidas relacionando baixos níveis de sinal.

No trace da sinalização da interface Abis descobriu-se que o nível do sinal no uplink estava muito baixo (cerca de -98dBm) quando ocorria o assignment fails.

Um drive test no site demonstra que o mesmo está isolado e com uma área de cobertura bastante ampla e complexa em termos de topografia. Quando um móvel está a 25Km ou mais de distância da BTS o nível de recepção no downlink é de cerca de -90dBm, entretanto no uplink o sinal não é suficiente, gerando portanto o TCH assignment fails.



Caso 7 - Conclusão: Neste caso a baixa cobertura no uplink gerava a elevada taxa de

congestionamento. A adição de novas BTS podem ajudar na obtenção de uma

cobertura contínua na região de interesse. A alteração de sites tipo omni para

setorizados ou a adição de TMA podem melhorar a intensidade do sinal no

uplink e evitar o chamado “over shooting” no downlink.


Conteúdo

1. Congestionamento de TCH

2. Congestionamento de SDCCH


Congestionamento de SDCCH



Causas e Soluções para congestionamento de SDCCH

Estudos de Casos de congestionamento de SDCCH



A fórmula para a taxa de congestionamento de

SDCCH é: SDCCH congestion rate=Attempted SDCCH seizures que encontram um SDCCH

blocked state /Attempted SDCCH seizures (all)

Causas para SDCCH seizure: SDCCH assignment para MOC

SDCCH assignment para MTC

Location update

SDCCH handover

Short message

IMSI attach e detach


Congestionamento de SDCCHCongestionamento de SDCCH

MS BTS BSC MSC

BSC random access – immediate assignment

Cell SDCCH seizure request times

Channel RequiredChannel Request (RACH)

Cell immediate assignment request times

Cell SDCCH seizure failure BTSS008015

Attempted SDCCH seizures meeting a SDCCH blocked state (No SDCCH available)

Immediate Assignment Command

Immediate Assignment Reject


Causas e soluções para o congestionamento de SDCCH As fronteiras de uma location area são fonte de

excessivas tarefas de location update e SDCCH

attempt Otimização do projeto da location area

Modificação do CRH (Cell Reselect Hysteresis)

Modificação do T3212 para o location update periódico da BSC

Solução de problemas de handover entre redes dual-band

Quantidade excessiva de short messages Adição de canais SDCCH

Habilitação da função de alocação dinâmica de SDCCH



Capacidade insuficiente do sistema devido a falta de

canais de SDCCH Expansão de canais TCH e SDCCH

Mais canais SDCCH devem ser adicionados

Configuração incorreta de parâmetros – RACH Aumentar o limiar de acesso (RACH access threshold) para transpor a barreira

imposta pela interferência.

Diminuir o número de retransmissões e aumentar os extended transmission

timeslots

Falhas de placas (TRX) e problemas de transmissão

também resultam em congestionamento de SDCCH


Estudos de Casos – Congestionamento de SDCCH Casos de congestionamento de SDCCH

Caso 1: Excesso de location update

Caso 2: Falha de placa no equipamento de transmissão

Caso 3: Problema de transmissão de timeslot no mux


Excesso de location update

Caso 1 – Descrição da falha: A taxa de call setup successful em uma dada rede estava baixa. Analisando as

estatísticas de tráfego constatou-se o congestionamento de SDCCH em alguns

sites.



Caso 1 - Análise: Sendo pequeno o número de BTS congestionadas, registrou-se uma “SDCCH

Measurement Function” e procedeu-se com a análise da taxa SDCCH seizure

para diferentes causas, com a finalidade de se encontrar o real motivo para o

congestionamento de SDCCH.



Caso 1 – Manutenção: 1. Registrando uma “SDCCH Measurement Function”

Na célula congestionada, o valor de SDCCH attempted chegava de 300-400 vezes em uma certa hora. A configuração dos sites era S1/1/1. Cada célula era configurada com canal SDCCH/8. Normalmente é um número suficiente para suportar esses valores de 300-400 vezes, entretanto existiam dezenas de congestionamentos de SDCCH para cada célula na hora de maior tráfego.

Foi constatado que a maioria dos SDCCH seizures estavam relacionados com location update. Analisando a localização das células, foi verificado que as aquelas que apresentavam congestionamento se situavam na fronteira de duas location areas atravessadas por uma linha férrea, e que a maioria dos location update estavam localizados em um intervalo de 5 minutos. Investigando o horário dos trens, foi constatado que 4 a 5 trens passavam dentro daquele intervalo de tempo, ocasionando portanto todo o tráfego de MSs solicitando location update.

2. A adição de SDCCH ou habilitação da função de alocação dinâmica de SDCCH resolveu o problema.



Caso 1 - Conclusão: Para casos de congestionamento de SDCCH devido a location update, verifique

quando esse acontecimento é causado por configuração inadequada da

location area. Adicione canais SDCCH ou habilite a função de alocação

dinâmica deste para solucionar esses tipos de problema.


Falha de placa no equipamento de transmissão Caso 2 – Descrição da falha:

Após colocar em operação uma nova BTS30, os canais SDCCH estavam todos

no estado “A” e os canais TCH estavam nos estados “I” ou “A”. Quando uma

chamada era realizada, a comunicação procedia de forma normal. Observando

as estatísticas de tráfego, constatou-se que as SDCCH seizure failure atingia

valores superiores a 1000 (na hora de maior movimento).


Falha de placa no equipamento de transmissão Caso 2 - Análise:

Sabendo que a comunicação estava normal mas os

canais SDCCH estavam congestionados após a entrada

em operação da nova BTS: Verificou-se primeiramente os dados de configuração e o hardware. Devido

ao fato de todo o site sofrer o problema de congestionamento, fazendo a

troca do enlace Abis com outro site de mesma configuração, confirmou-se

que não havia problemas de hardware ou configuração de dados relativos

a interface Abis.

Passou-se então para a análise do sistema de transmissão da interface

Abis.


Falha de placa no equipamento de transmissão Caso 2 - Manutenção:

Verificando o estado dos alarmes, foi constatado o alarme LAPD link fault alarm and recovery alarm (dentro de um segundo). O alarme aparecia a cada dez minutos.

Conforme verificado durante a análise, a troca de cabos da interface Abis com outro site não apresentou problemas, entretanto verificou-se que o alarme.

Após realizar a operação de troca das placas TMU e TRX o problema ainda persistia.

Realizando a medida da transmissão através de um self-loop na BIE, verificou-se uma elevada taxa de erro de bit (BER) para a transmissão. Aprofundando os testes no equipamento de transmissão, foi constatado um problema com a placa responsável pelos 2Mbps do referido site. A substituição desta resolveu o problema.


Falha de placa no equipamento de transmissão Caso 2 - Conclusão:

Neste caso, devido a alta taxa de BER na transmissão da interface Abis,

diversas mensagens de SDCCH assignment eram perdidas, gerando re-envios

que ocasionavam o congestionamento.


Problema de transmissão de timeslot no Mux Caso 3 – Descrição da falha:

Diversos clientes reclamando de dificuldades em

realizar chamadas através dos sites (ABCD), mas esses

não relatavam qualquer informação de alarme. Verificou-se os 4 sites, os estados das placas estavam normais. Quase

nenhum canal TCH apresentava TCH seized successfully. Algumas vezes o

estado de um TCH estava em “A”, mas retornava para “I” dentro de alguns

segundos.

O engenheiro de operações informou que a BTS-A estava conectada às

BTSs B, C e D, compartilhando o mesmo E1 (transmission timeslot

multiplexer).


Problema de transmissão de timeslot no Mux Caso 3 - Análise:

O compartilhamento de informações é de extrema importância para auxiliar

no julgamento do problema (hardware ou transmissão neste caso). Como é

pouco provável que ocorra uma falha de hardware nas 4 BTSs e, sendo a

transmissão comum para os 4 sites, esta deve ser verificada cuidadosamente.


Problema de transmissão de timeslot no Mux Caso 3 - Manutenção:

1. Observou-se na BIE a indicação de BER para a transmissão. Entretanto não havia indicação anormal no equipamento de microondas ou transceptor óptico.

2. Verificou-se a sinalização da interface Abis e encontrou-se um grande número de mensagens de PAGING_CMD, porém apenas uma mensagem de RF_RESOURCE_INDICATION aparecia ocasionalmente. Não foi encontrada nenhuma mensagem do tipo CHAN_ACTIV, CHAN_ACTIV_ACK ou IMMEDIATE_ASSIGN_CMD. Isso indicava inatividade dos canais SDCCH.

3. Verificou-se o registro de O&M e nenhuma alteração de dados havia sido realizada.

4. Realizou-se o procedimento de recarga de software na BTS e descobriu-se que o sistema respondia de forma lenta e com problemas de timeout na comunicação. O problema de congestionamento de SDCCH permaneceu após a recarga de software.


Problema de transmissão de timeslot no Mux Caso 3 – Manutenção:

5. Foi realizada um reset no equipamento MUX e um reset nas 4 BTSs, a partir

do qual os canais SDCCH e TCH passaram a operar satisfatoriamente. Um

trace da sinalização na interface Abis mostrou que as mensagens

CHAN_ACTIV, CHAN_ACTIV_ACK e IMMEDIATE_ASSIGN_CMD apareceram. O

congestionamento de SDCCH foi solucionado e as MSs voltaram a realizar

chamadas naquela região.

6. Para evitar a repetição deste problema foi sugerida a modificação na

configuração do equipamento Mux.


Problema de transmissão de timeslot no Mux Caso 3 - Conclusão:

O problema na transmissão provocava congestionamento de SDCCH devido a

repetidas solicitações das MSs. Problemas de transmissão podem ser

provocados por diversas razões. Neste caso, a falha no combinador primário

do equipamento Mux ocasionou na não ativação adequada dos canais SDCCH.

Sendo assim, todas as BTSs conectadas a esse equipamento apresentavam o

mesmo problema. Lidando com esses tipos de problema, procure investigar

suas particularidades e a similaridade de fatos para então finalmente localizar

o problema com um método exclusivo.

Obrigadowww.huawei.com

Omf000405 alálise de casos congestionamento versão1.4

Documents

Transcript of Omf000405 alálise de casos congestionamento versão1.4