Omf000405 alálise de casos congestionamento versão1 4 by Emerson Eduardo Rodrigues

Es tudo de Ca s os Conge s tiona me nto www.huawei.com

Re fe rê ncia s 

31160978-BSC Traffic Statistic Manual Volume I



31033203-BSS Troubleshooting Manual

Página 2

Obje tivos 

Ao completar esse curso você estará apto a: 

Compreender os princípios de congestionamento



Analisar e resolver problemas de congestionamento

Página 3

Conte údo 1.

Congestionamento de TCH

Congestionamento de SDCCH

Página 4

Conge s tiona me nto de TCH 

Congestionamento de TCH 

Princípios Básicos



Causas para um alto congestionamento de TCH



Estudo de caso – Congestionamento de TCH

Página 5

Conge s tiona me nto de TCH 

Princípios Básicos 

Definição de Taxa de Congestionamento de TCH



Pontos de medida para análise de congestionamento de TCH

Página 6

Conge s tiona me nto de TCH 

Definição da Taxa de congestionamento de TCH 

Taxa Congestionamento de TCH (excluindo hando v e r) =(TCH seizure failures for call + TCH seizure failures for very early assignment) / (Attempted TCH seizures + Attempted TCH seizures for very early assignment) *100%

Página 7

Conge s tiona me nto de TCH 

Definição da Taxa de congestionamento de TCH 

Taxa de congestionamento de TCH (incluindo hando v e r) =(TCH seizure failures for call + TCH seizure failures for very early assignment + TCH seizure failures para hando v e r de células intraBSC (falta de recursos de radio) + TCH seizure failures para hando v e r de células interBSC (falta de recursos de radio) ) / (Attempted TCH seizures (all) + Attempted TCH seizures for very early assignment + Attempted TCH seizures para hando v e r de células intraBSC + Attempted TCH seizures for interBSC)

Página 8

Conge s tiona me nto de TCH 

Pontos de medida de

Tráfego para análise da taxa de

BTS Channel_Req

IMMEDIATE ASSIGN COMMAND first SABM Establish_IND( CM Service Req) CM Service Accepted Setup Call Proceeding Channel_Active

SDCCH SDCCH SACCH(TCH) SACCH(TCH)

MSC

Channel_Active Channel_Active_Ack

congestionamento de TCH

BSC

CR(Complete_l3_information) CC

Assignment_Req

Channel_Active_Ack ASSIGNMENT COMMAND first SABM Establish_IND UA ASSIGNMENT CMP Assignment_CMP Alerting Connect Connect Ack Communication Disconnect Release Release Complete Clear_CMD Clear_CMP

Página 9

Conge s tiona me nto de TCH 

Ponto de medida - Atte mp te d TC Hs e iz ure s 

Atte m p te d TC Hs e izure s para chamada 



Re c e b e a m e n s a g e m a ssig n m e n t re q u e st d a MS C

Atte m p te d TC Hs e izure s para v e ry e arly as s ig nm e nt 

Q u a n d o n ã o h á re c u rs o s p a ra a lo c a çã o d e S DCCH e é p e rm it id o o v e ry e a rly a ssig n m e n t.





Q u a n d o a s o lic it a çã o d e c a n a l é re c e b id a e o t ip o d e c a n a l é TCH

Attempted TCH seizures para hando v e r intraBSC 

Q u a n d o a m e n s a g e m d e s o lic it a çã o d e h a n d o v e r in t ra BS C é re c e b id a (n o n - SDC C Hh a n d o v e r re q u e st).



Attempted TCH seizures para hando v e r interBSC 

Q u a n d o a m e n s a g e m d e s o lic it a çã o d e h a n d o v e r in t e rBS C é re c e b id a (h a n d o v e r ty p e is n o n - SDC C H)

Página 10

Conge s tiona me nto de TCH 

Falhas de TCH seizure: 

TCH seizure – falha na chamada,



TCH seizure – falha no very early assignment,



TCH seizure – falha no hando v e r interBSC,



TCH seizure – falha no hando v e r intraBSC,



TCH seizure – falha no hando v e r entre células.

Página 11

Conge s tiona me nto de TCH 

Ponto de medida – Falha de TCH seizure na chamada: 

(1)CONN_FAIL mensagem recebida no procedimento de as s ig nm e nt.



(2)CLEAR_CMD recebida no processo de saída da BSC durante o hando v e r. A causa é o Direct Retry.



(3)CLEAR_CMD recebida no procediemento de as s ig nm e nt.



(4)RR_ABORT_REQ recebida no procedimento de saída da BSC durante o hando v e r e a causa do handover é um dire c t re try.



(5)RR_ABORT_REQ recebida no procedimento de as s ig nm e nt.



(6)MSG_HO_REQ_REJ recebida no processo de saída da BSC durante o hando v e r (dire c t re try).

Página 12

Conge s tiona me nto de TCH 

Ponto de medida – Falha de TCH seizure na chamada : 

(7) HO_FAIL mensagem recebida na saída da BSC durante um hando v e r (dire c t re try).



(8) ERR_IND recebida no procedimento de as s ig nm e nt.



(9) Quando a mensagem de as s ig nm e nt failure é enviada.



(10)TN_T7 (direct retry) tim e o ut (outgoing BSC handover request)



(11)TN_T8 (direct retry) tim e o ut (outgoing BSC handover complete)

Página 13

Conge s tiona me nto de TCH 

Ponto de medida – falha de TCH s e iz ure para v e ry e arly as s ig nme nt: 

(1)CH_ACT_NACK

recebida

processo

v e ry

e arly

TCH

as s ig nm e nt.

(CH_ACT_NACK é recebida no s tatus 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 tim e o ut no processo very early TCH assignment.

Página 14

Conge s tiona me nto de TCH 

Ponto de medida - Falha de TCH seizure para hando v e r intraBSC : 



Falha de alocação de TCH no hando v e r intraBSC

Ponto de medida – Falha de TCH seizure para hando v e r inte rBSC : 

Quando não há TCH disponível a mensagem inte rBSC inc o ming c e ll hando v e r failure é enviada.

Página 15

Conge s tiona me nto de TCH 

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 Intrac e ll Hando v e r Re q ue s t não ser suportado. Sem resposta ao final da contagem do temporizador (tim e r 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

Página 16

Conge s tiona me nto de TCH 

Ponto de medida - falha de TCH seizure devido a falhas na interface A: 

Interface A 

Ap ó s o e n v io d a m e n s a g e m As s ig n m e n t _Re q p e la MS C, s e h o u v e r fa lh a n o s c ir c u it o s d e t r o n c o d a in t e rfa c e A a BS C ir á re t o rn a r As s ig n m e n t _Fa ilu re d ire t a m e n t e .



Ne s t e c a s o , g e r a lm e n t e a c a u s a é a in c o rre t a d e s ig n a çã o d o s c irc u it o s d e t ro n c o (CIC).

Página 17

Conge s tiona me nto de TCH 

Falhas de TCH seizure devido a falhas nas interfaces Abis e Um: 

Interfaces Abis e Um 

1 . Fa lh a d a p la c a d e TRX o u in s t a b ilid a d e d e p e rfo rm a n c e



2 . N ív e l d e d e s b a la n c e a m e n t o e n t re u p lin k /d o w n lin k n a BTS



3 . Ba ix a q u a lid a d e d e s in a l d e u p lin k /d o w n lin k d e v id o a in t e rfe r ên c ia



4 . S DCCH e TCH p e rt e n c e n t e s a d ife re n t e s TRX q u e re a liz a m d ife re n t e s c o b e rt u r a s

Página 18

Ca us a s pa ra um a lto conge s tiona me nto de TCH 

Causas



Manutenção

Página 19

Ca us a s pa ra um a lto conge s tiona me nto de TCH 

Causas para uma alta taxa de congestionamento de TCH: 

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



Falhas no hando v e r provocadas por C o - fre q üê nc ia e c o - BSIC , levando a um TC H as s ig nm e nt failure



Falha ou instabilidade em placas de circuito



Hardware da BTS não instalado corretamente, provocando desbalanceamento entre sinais de up link/do w nlink.



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



TC Has s ig nm e nt failure devido a topografia e isolamento do site.

Página 20

Conge s tiona me nto de TCH 

Como

localizar

causas

para

alta

taxa

congestionamento de TCH 



Analisando as causas de congestionamento remotamente 

1 . Es t a t ís t ic a s d e Tr á fe g o



2 . In fo rm a çõ e s d e Ala rm e



3 . Ma n u t e n çã o d a BTS r e m o t a m e n t e a t ra v és d o O MC



4 . An á lis e d e m e n s a g e n s n a in t e r fa c e Ab is

Verificação da BTS o n- s ite

Página 21

Conge s tiona me nto de TCH 

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

Em “TC HMe as ure me nt Func tio n”, verifique se os canais estão todos ocupados ou não 

S e s im , r e a liz e u m lo a d h a n d o v e r o u s u g ira e x p a n s ã o d a c a p a c id a d e .



S e n ã o , v e rifiq u e a s b a n d a s d e in t e rfe r ên c ia 1 ~ 5 . S e c o n s t a t a d a a in t e r fe r ê n c ia , a t a x a q u e d a d e c h a m a d a s n a c élu la p ro v a v e lm e n t e s e r á a lt a t a m b é m .



Registre uma “Re c e iv ing Le v e l Me as ure m e nt Func tio n” 

1 . Ve r ifiq u e o r e s u lt a d o p o r o b je t o e v e ja q u a n d o o s n ú m e ro s d o s re la t ório s p a r a u p lin k e d o w n lin k e stã o b a la n c e a d o s e m u m a m e s m a p la c a TRX.



2 . Ve r ifiq u e o re s u lt a d o p o r t e m p o p a ra v e r q u a n d o a s m e d id a s n o s r e la t ó rio s

s ão

e le v a d o s .

De s t a

fo rm a

p o d e -s e

v e rific a r

Página 22

Conge s tiona me nto de TCH 

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.

Página 23

Conge s tiona me nto de TCH 

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.

Página 24

Conge s tiona me nto de TCH 

Análise Remota 4:

Análise de mensagens na interface

Abis. 

Realize um trac e nas mensagens da interface Abis da BTS em congestionamento e analise o As s ig nme nt C MD enviado no SDCCH 

S e o a ssig n m e n t s e m p re re s u lt a e m fa lh a p a ra u m TRX e s p e c ífic o , a c a u s a m a is p r o v á v e l p o d e s e r u m a d a s s e g u in t e s : – Fa lha ou ins ta bilida de na pla ca TRX – De s ba la nce a me nto ou proble ma de hardw are no Up link/do w nlink – Ba ixa qua lida de dos s ina is de up link ou do w nlink. Ana lis e o va lor do TA da MS pa ra ide ntifica r o proble ma .



S e o a ssig n m e n t fa lh a e m t o d a s a s p la c a s re fe re n t e s à c élu la , d e fo rm a a le a t ó r ia , a n a lis e o re la t ório d e m e d i çõ e s . As c a u s a s p o d e m

ser as

s e g u in t e s : – P roble ma re la ciona do com a topogra fia na re giã o de cobe rtura da cé lula (complica do) Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. – Exis te inte rfe rê ncia e m toda a cé lula , ta is como proble ma s com re pe tidore s .

Página 25

Conge s tiona me nto de TCH

Página 26

Conge s tiona me nto de TCH 

Verificação da BTS o n- s ite 

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 as s ig nm e nt ocorrem para um certo TRX ou toda a célula de forma aleatória.



Realize um driv e test para verificar se existem anomalias relacionadas com o procedimento de hando v e r e interferências no do w nlink.



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



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

Página 27

Es tudo de Ca s os – Conge s tiona me nto 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 hardw are no up link



Caso 4: Problema de hardw are no do w nlink



Caso 5: Efeitos do repetidor na célula



Caso 6: Outros erros de configuração



Caso 7: Site isolado e topografia complexa

Página 28

Erro na configura çã o da Inte rfa ce 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 hando v e r) de toda a rede aumentou 4% e que a maioria das células estavam com nível de congestionamento elevado.

Página 29

Erro na configura çã o da Inte rfa ce 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 TC H s e izure failure através das estatísticas de tráfego e finalmente localizar o problema (seja ele causado por configuração de dados ou hardw are ).

Página 30

Es tudo de Ca s os – Conge s tiona me nto 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. 



An a lis e a s e s t a t ís t ic a s d e t r á fe g o e p ro c u re p o r c o n g e s t io n a m e n t o s e m c é lu la s d e u m m ó d u lo e s p e c ífic o d a BS C (c élu la s d o m ód u lo 1 , 2 , ...). Ve rifiq u e s e a s TC H se izu re fa ilu re s (re q u e ste d te rre stria l re so u rc e u n a v a ila b le ). Is s o d e m o n s t ra q u e a fa lt a d e re c u rs o s é a p rin c ip a l c a u s a d o a lt o c o n g e s t io n a m e n t o d o m ód u lo s o b a n ális e . A c a u s a p a r a te rre stria l re so u rc e s u n a v a ila b ility é re la c io n a d a p rin c ip a lm e n t e à s in t e r fa c e s A e Ab is . É p o u c o p ro v áv e l q u e a in t e rfa c e Ab is s e ja r e s p o n s á v e l p o r fa lh a s d e d iv e rs a s c élu la s a o m e s m o t e m p o e m u m m e s m o m ó d u lo , p o rt a n t o p o d e m o s v o lt a r a a t e n çã o p a ra o h a rd w a re e a c o n fig u r a çã o d e d a d o s d a in t e rfa c e A d e s t e m ód u lo .

Página 31

Es tudo de Ca s os – Conge s tiona me nto de TCH 

Caso 1 - Manutenção: 

2.Verificando o hardw are da Interface A, constatou-se que não havia problemas com este, portanto, hardw are 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 tim e s lo ts 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).

Página 32

Es tudo de Ca s os – Conge s tiona me nto de TCH 

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á.

Página 33

Fa lha na pla ca 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 “TC Hs e izure failure s fo r c all (no radio re s o urc e )” é 0.



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

Página 34

Fa lha na pla ca TRX 

Caso 2 – Análise: 

1. Nenhuma configuração de dados fora efetuada e não existe ho p p ing 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 as s ig nm e nt failure .



3. Descobrindo o TRX relacionado com a falha, tente localizar a falha no TRX que pode ser relacionada com o as s ig nm e nt faiIlure . Confirme se a falha persiste após um re s e t e substitua o TRX.

Página 35

Fa lha na pla ca TRX 

Caso 2 - Manutenção: 

1. Verificando o estado dos BT c hanne ls através do O MC 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 s ite 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.

Página 36

Fa lha na pla ca TRX 

Caso 2 – Conclusão: 

1.Falha na placa TRX provoca alta taxa de congestionamento e TC Hs e izure failure s .



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.

Página 37

P roble ma de hardw are no up link 

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.

Página 38

P roble ma de hardw are no up link 

Caso 3 - Análise: 

Verificando o hardware da BTS a procura de falhas: 

Fa lh a d e h a rd w a re : a c o m u n ic a çã o e s t a v a n o rm a l p a ra t o d a s a s c élu la s , p o r t a n t o d e s c a rt a d a a p o s s ib ilid a d e d e fa lh a d e h a rd w a re p a ra a s m e s m a s .



Co n e x õ e s d e h a rd w a re : a n a lis e a s e s t a t ís t ic a s d e t r áfe g o p a ra o u p lin k e o d o w n lin k, v e r ific a n d o t a m b é m a s c o n e x õ e s p a ra a m b a s a s d ire çõ e s .

Página 39

P roble ma de hardw are no up link 

Caso 3 - Manutenção: 

Foi registrada uma “Re c e iv ing Le v e l Me as ure m e nt Func tio n” 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 up link 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.

Página 40

P roble ma de hardw are no up link 

Caso 3 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. 12 Module ID 1, Cell ID 5, TRX No. 13

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

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

655

105

293

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

294

166

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

222

142

Página 41

P roble ma de hardw are no up link 

Caso 3 - Conclusão: 

A causa da “TCH seizure failure” foi provocada por problemas de conexão do hardw are . 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 up link foi encontrado através da “Re c e iv ing Le v e l Me as ure m e nt Func tio n”.

Página 42

P roble ma de hardw are no Do w nlink 

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.

Página 43

P roble ma de hardw are no Do w nlink 

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.

Página 44

P roble ma de hardw are no Do w nlink 

Caso 4 - Manutenção: 



Realizando um trac e na interface Abis da BTS e analisando a sinalização, foi verificado que no processo de TC Hs e izure failure , o sinal de up link 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 trac e . 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 do w nlink. 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.

Página 45

P roble ma de hardw are no Do w nlink 

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.

Página 46

Efe itos do Re pe tidor 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%.

Página 47

Efe itos do Re pe tidor na Cé lula 

Caso 5 - Análise: 

Como o congestionamento apareceu após a expansão: 

Ve rific o u -s e a o c o rr ê n c ia p a ra t o d o s TRX. Ca s o a v e rific a çã o fo s s e p o s it iv a , u m a r e a v a lia çã o d a s c o n e x õ e s d o n o v o h a rd w a re d a BTS s e ria n e c e s s ária p a r a lo c a liz a çã o d e fa lh a s .



Ca s o o p r o b le m a a p o n t a s s e p a ra u m o u p o u c o s TRX, a p e n a s e s s e s s e ria m a lv o d e a n á lis e d e h a rd w a re .



Ex c lu in d o -s e o p ro b le m a d e h a rd w a re n o s it e , c a u s a s e x t e rn a s p a s s a m a s e r a lv o d e in v e s t ig a çã o . Po r e x e m p lo , u m re p e t id o r q u e n ão s o fre u a d e v id a e x p a n s ã o fo i o c a u s a d o r d o s p ro b le m a s d e a ssig n m e n t fa ilu re .

Página 48

Efe itos do Re pe tidor na Cé lula 

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 as s ig nm e nt 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.

Página 49

Efe itos do Re pe tidor na Cé lula 

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 as s ig nm e nt failure .

Página 50

Outros e rros de configura çã o 

Caso 6 – Descrição da falha: 

Na otimização da rede, a taxa de congestionamento (incluindo hando v e r) nas horas de maior tráfego atingia 10% para duas células. As “TC H s e izure failure s e x c luding hando v e r” e “TC H s e izure failure s fo r c all (no radio re s o urc e )” estavam normais. Neste caso a “TC H s e izure failure s (all)” indicava 89, mas as “TC H s e izure failure s fo r MO C ” 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.

Página 51

Outros e rros de configura çã o 

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 hando v e r. 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 hando v e r (se normal ou não).

Página 52

Outros e rros de configura çã o 

Caso 6 – Manutenção: 

Registrando uma “Inc o m ing Inte r C e ll Hando v e r Me as ure m e nt Func tio n” durante 15 minutos e procurando por falhas de hando v e r 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 hando v e rs significa que existe problema com a configuração de dados de hando v e r. Verificando esses dados, constatou-se que havia “c o - fre q üê nc ia” e “c o - BSIC ”. As duas células eram adjacentes à célula A, portanto o hando v e r para as duas células falhavam.



Alterando o BCCH e o BSIC de uma das células o problema de hando v e r foi solucionado, desaparecendo também o problema de congestionamento.

Página 53

Outros e rros de configura çã o 

Caso 6 - Conclusão: 

Duas células, ambas adjacentes à célula A com “c o - fre q üê nc ia” e “c o - BSIC ” resultavam em baixa taxa de sucesso de hando v e r e também alta taxa de congestionamento de TCH incluindo hando v e r.



Este caso indica que as taxas de congestionamento de TCH com e sem hando v e r eram diferentes.

Página 54

S ite is ola do e topogra fia comple xa 

Caso 7 – Descrição da falha: 

Um site do tipo O2 em uma área suburbana sofria de alta taxa de congestionamento (excluindo hando v e r), variando de 3 a 10% (na proporção do volume de tráfego). Entretanto as “TC H s e iz ure failure s fo r c all (no radio re s o urc e )” indicavam 0%. 

1 . Blo q u e a n d o o s 2 TRX (u m p o r v e z ), a t a x a d e c o n g e s t io n a m e n t o n ão s e a lt e ra v a s ig n ific a t iv a m e n t e .



2 . O u t r o s ín d ic e s : a t a x a d e c a ll d ro p e s t a v a e m 5 % e a in t e rfe r ê n c ia a p r e s e n t a v a v a lo re s n o rm a is .

Página 55

S ite is ola do e topogra fia comple xa 

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 as s ig nm e nt failure a taxa de queda de chamadas foi considerada juntamente com a performance do up link e do w nlink no que se refere ao nível e qualidade dos mesmos.

Página 56

S ite is ola do e topogra fia comple xa 

Caso 7 - Manutenção: 



Verificando a “C all Dro p Me as ure m e nt” 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 “Re c e iv ing Le v e l Me as ure m e nt Func tio n” 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 up link estava muito baixo (cerca de -98dBm) quando ocorria o as s ig nm e nt fails . Um driv e te s t 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 do w nlink é de cerca de -90dBm, entretanto no up link o sinal não é suficiente, gerando portanto o TC Has s ig nm e nt fails .

Página 57

S ite is ola do e topogra fia comple xa 

Caso 7 - Conclusão: 

Neste caso a baixa cobertura no up link 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 up link e evitar o chamado “o v e r s ho o ting ” no do w nlink.

Página 58

Conte údo 1.

Congestionamento de TCH

Congestionamento de SDCCH

Página 59

Conge s tiona me nto de S DCCH 

Congestionamento de SDCCH 

Princípios Básicos



Causas e Soluções para congestionamento de SDCCH



Estudos de Casos de congestionamento de SDCCH

Página 60

Conge s tiona me nto de S DCCH 

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

Página 61

Conge s tiona me nto de S DCCH MS

BTS Channel Request (RACH)

BSC

MSC

Channel Required BSC random access – immediate assignment Cell SDCCH seizure request times Cell immediate assignment request times Attempted SDCCH seizures meeting a SDCCH blocked state (No SDCCH available) Cell SDCCH seizure failure BTSS008015 Immediate Assignment Command

Immediate Assignment Reject

Página 62

Ca us a s e s oluçõe s pa ra o conge s tiona me nto de S DCCH 

As fronteiras de uma lo c atio n are a são fonte de excessivas tarefas de lo c atio n up date e SDCCH atte m p t





Otimização do projeto da lo c atio n are a



Modificação do CRH (C e ll Re s e le c t Hys te re s is )



Modificação do T3212 para o lo c atio n up date periódico da BSC



Solução de problemas de hando v e r entre redes dual- b and

Quantidade excessiva de s ho rt me s s ag e s 

Adição de canais SDCCH



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

Página 63

Conge s tiona me nto de S DCCH 

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 e x te nde d trans m is s io n tim e s lo ts

Falhas de placas (TRX) e problemas de transmissão também resultam em congestionamento de SDCCH

Página 64

Es tudos de Ca s os – Conge s tiona me nto de S DCCH 

Casos de congestionamento de SDCCH 

Caso 1: Excesso de lo c atio n up date



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



Caso 3: Problema de transmissão de tim e s lo t no mux

Página 65

Exce s s o de lo c atio n up date 

Caso 1 – Descrição da falha: 

A taxa de c all s e tup s uc c e s s ful em uma dada rede estava baixa. Analisando as estatísticas de tráfego constatou-se o congestionamento de SDCCH em alguns sites.

Página 66

Exce s s o de lo c atio n up date 

Caso 1 - Análise: 

Sendo pequeno o número de BTS congestionadas, registrou-se uma “SDC C H Me as ure m e nt Func tio n” e procedeu-se com a análise da taxa SDC C H s e izure para diferentes causas, com a finalidade de se encontrar o real motivo para o congestionamento de SDCCH.

Página 67

Exce s s o de lo c atio n up date 

Caso 1 – Manutenção: 

1. Registrando uma “SDC C H Me as ure me nt Func tio n” 





Na c é lu la c o n g e s t io n a d a , o v a lo r d e S DCCH a t t e m p t e d c h e g a v a d e 3 0 0 -4 0 0 v e z e s e m u m a c e rt a h o ra . A c o n fig u ra çã o d o s s it e s e ra S 1 /1 /1 . Ca d a c élu la e ra c o n fig u r a d a c o m c a n a l S DCCH/8 . No r m a lm e n t e é u m n ú m e ro s u fic ie n t e p a r a s u p o r t a r e s s e s v a lo re s d e 3 0 0 -4 0 0 v e ze s , e n t re t a n t o e x is t ia m d e z e n a s d e c o n g e s t io n a m e n t o s d e S DCCH p a ra c a d a c é lu la n a h o ra d e m a io r t r áfe g o . Fo i c o n s t a t a d o q u e a m a io ria d o s SDC C H se izu re s e s t a v a m re la c io n a d o s c o m lo c a tio n u p d a te . An a lis a n d o a lo c a liza çã o d a s c é lu la s , fo i v e rific a d o q u e a s a q u e la s q u e a p re s e n t a v a m c o n g e s t io n a m e n t o s e s it u a v a m n a fr o n t e ir a d e d u a s lo c a tio n a re a s a t ra v e s s a d a s p o r u m a lin h a f é r re a , e q u e a m a io ria d o s lo c a tio n u p d a te e s t a v a m lo c a liz a d o s e m u m in t e rv a lo d e 5 m in u t o s . In v e s t ig a n d o o h o r ário d o s t re n s , fo i c o n s t a t a d o q u e 4 a 5 t re n s p a s s a v a m d e n t ro d a q u e le in t e rv a lo d e t e m p o , o c a s io n a n d o p o rt a n t o t o d o o t r á fe g o d e MS s s o lic it a n d o lo c a tio n u p d a te .

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

Página 68

Exce s s o de lo c atio n up date 

Caso 1 - Conclusão: 

Para casos de congestionamento de SDCCH devido a lo c atio n up date , verifique quando esse acontecimento é causado por configuração inadequada da lo c atio n are a. Adicione canais SDCCH ou habilite a função de alocação dinâmica deste para solucionar esses tipos de problema.

Página 69

Fa lha de pla ca no e quipa me nto de tra ns mis s ã 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 SDC C Hs e izure failure atingia valores superiores a 1000 (na hora de maior movimento).

Página 70

Fa lha de pla ca no e quipa me nto de tra ns mis s ã o 

Caso 2 - Análise: 

Sabendo que a comunicação estava normal mas os canais SDCCH

estavam

congestionados

após

entrada

operação da nova BTS: 

Ve rific o u -s e p r im e ira m e n t e o s d a d o s d e c o n fig u ra çã o e o h a rd w a re . De v id o a o fa t o d e t o d o o s it e s o fre r o p ro b le m a d e c o n g e s t io n a m e n t o , fa z e n d o a t ro c a d o e n la c e Ab is c o m o u t ro s it e d e m e s m a c o n fig u ra çã o , c o n firm o u -s e q u e n ã o h a v ia p ro b le m a s d e h a rd w a re o u c o n fig u ra çã o d e d a d o s re la t iv o s a in t e r fa c e Ab is .



Pa s s o u -s e e n t ã o p a ra a a n á lis e d o s is t e m a d e t ra n s m is s ão d a in t e rfa c e Ab is .

Página 71

Fa lha de pla ca no e quipa me nto de tra ns mis s ã o 

Caso 2 - Manutenção: 



Verificando o estado dos alarmes, foi constatado o alarme LAPD link fault alarm and re c o v e ry 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 s e lf- lo o p 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.

Página 72

Fa lha de pla ca no e quipa me nto de tra ns mis s ã o 

Caso 2 - Conclusão: 

Neste caso, devido a alta taxa de BER na transmissão da interface Abis, diversas mensagens de SDC C H as s ig nm e nt eram perdidas, gerando re-envios que ocasionavam o congestionamento.

Página 73

P roble ma de tra ns mis s ã o de tim e s lo t 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. 

Ve rific o u -s e o s 4 s it e s , o s e s t a d o s d a s p la c a s e s t a v a m n o rm a is . Q u a s e n e n h u m c a n a l TCH a p re s e n t a v a TC H se ize d su c c e ssfu lly . Alg u m a s v e z e s o e s t a d o d e u m TCH e s t a v a e m “A”, m a s re t o rn a v a p a ra “I”d e n t ro d e a lg u n s se gundos.



O e n g e n h e iro d e o p e ra çõ e s in fo rm o u q u e a BTS -A e s t a v a c o n e c t a d a às BTS s

B, C e

D, c o m p a rt ilh a n d o

m esm o

( tra n sm issio n tim e slo t

m u ltip le x e r).

Página 74

P roble ma de tra ns mis s ã o de tim e s lo t 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.

Página 75

P roble ma de tra ns mis s ã o de tim e s lo t 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 tim e o ut na comunicação. O problema de congestionamento de SDCCH permaneceu após a recarga de software.

Página 76

P roble ma de tra ns mis s ã o de tim e s lo t no Mux 

Caso 3 – Manutenção: 

5. Foi realizada um re s e t no equipamento MUX e um re s e t nas 4 BTSs, a partir do qual os canais SDCCH e TCH passaram a operar satisfatoriamente. Um trac e da sinalização na interface Abis mostrou que as mensagens CHAN_ACTIV, CHAN_ACTIV_ACK e IMMEDIATE_ASSIGN_CMD

apareceram.

congestionamento

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.

Página 77

P roble ma de tra ns mis s ã o de tim e s lo t 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.

Página 78

Obrigado www.huawei.com