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

498 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
498
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
17
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • After BSC sends ASSIGN CMD, BTS transmits it transparently to MS, and abnormalities occur:
    1. MS fails to receive the assignment command (ASSIGN CMD) or the UA frame from BTS.
    2. BTS fails to receive SABM frame or assignment completed message (ASSIGN COMP) from MS, this causes assignment failure.
    The signaling analyzer can be used to analyze the cause of assignment failure of Abis interface message.
  • When hardware installation causes the unbalanced uplink and downlink level and TCH congestion.
    1. Uplink flow: antenna -->tower amplifier-->feeder-->lightning arrester-->rack-top connector--> CDU-->TRX board.
    The error with RF cable causes the uplink level difference. Maybe the connector is not tight.
    2. Downlink flow: TRX --> CDU-->rack-top connector-->lightning arrester-->feeder-->antenna
    VSWR alarm occurs to the transmitting tributary of antenna feeder .
    The RF cable is twisted or the connector is not tight
    The error of cell antenna connection leads to the differences in the coverage, thus causing TCH congestion.
  • Processing principles:
    1. If the congestion rate are related to the blocked TRX, check whether there is interference, check the performance of uplink and downlink.
    2. If the congestion rate is not related to TRX, interference may exist in the whole cell or the propagation environment.
  • After all assignment failures are found on a specific TRX board, take the following into consideration:
    1. MS TA value in the measurement report.
    2. Uplink/downlink signal level.
    3. Uplink/downlink signal quality.
    Analyze the causes for a certain assignment failures , and dialing test should be performed on-site.
  • 1. According to the TEI values shown in the diagram, the TRX containing this SDCCH can be identified.
    2. With the ARFCN, the TRX containing this TCH can be identified.
  • The way for on-site dialing test:
    1. Carry out dialing test at each carrier and each channel, to check whether any timeslot or board can not be assignable.
    2. Check whether the downlink levels of all carriers are nearly the same. For TRX with significantly abnormal level, the cause can be located step by step through changing the board or uplink/downlink antenna & feeder system.
  • The number of uplink reports of the first three TRXs in cell 5 under module 1 differs greatly from that of the last three TRXs. It can be seen that the uplink signal level of the last three TRXs is obviously lower than that of the first three TRXs. The level values corresponding to the receiving level grades are as follows:
    Grade 0 : -110~ -100 dBm
    Grade 1 : -100~-95 dBm
    Grade 2 : -95~-90 dBm
    Grade 3 : -90~-80 dBm
    Grade 4 : -80~-70 dBm
    Grade 5 : > -70 dBm
  • From the TCH congestion rate (including handover) formula (refer to Page 6), we can see that it’s necessary to register the “Incoming Inter Cell Handover Measurement Function” and to analyze which cells fail on TCH seizure during handover.
  • Note: SDCCH congestion related to attempted SDCCH seizures meeting a SDCCH blocked state, this is different from TCH congestion.
    Attempted SDCCH seizures meeting a SDCCH blocked state refer to no SDCCH available. It is different from SDCCH seizure failure which includes attempted SDCCH seizure meeting a SDCCH blocked state, unsuccessful channel activation (NACK) and channel activation timeout (timeout)
  • Attempt SDCCH seizures measurement point: after BSC receives Channel Required.
    Attempted SDCCH seizures meeting a SDCCH blocked state measurement point: BTS finds no SDCCH channel available and cannot activate channel.
  • Omf000405 alálise de casos congestionamento versão1.4

    1. 1. www.huawei.com Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Estudo de Casos - Congestionamento
    2. 2. Página 2 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Referências  31160978-BSC Traffic Statistic Manual Volume I  31033203-BSS Troubleshooting Manual
    3. 3. Página 3 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Objetivos  Ao completar esse curso você estará apto a:  Compreender os princípios de congestionamento  Analisar e resolver problemas de congestionamento
    4. 4. Página 4 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Conteúdo 1. Congestionamento de TCH 2. Congestionamento de SDCCH
    5. 5. Página 5 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Congestionamento de TCH  Princípios Básicos  Causas para um alto congestionamento de TCH  Estudo de caso – Congestionamento de TCH
    6. 6. Página 6 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Princípios Básicos  Definição de Taxa de Congestionamento de TCH  Pontos de medida para análise de congestionamento de TCH
    7. 7. Página 7 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Definição da Taxa de congestionamento de TCH  Taxa Congestionamento de TCH (excluindo hando ve r) =(TCH seizure failures for call + TCH seizure failures for very early assignment) / (Attempted TCH seizures + Attempted TCH seizures for very early assignment) *100%
    8. 8. Página 8 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Definição da Taxa de congestionamento de TCH  Taxa de congestionamento de TCH (incluindo hando ve r) =(TCH seizure failures for call + TCH seizure failures for very early assignment + TCH seizure failures para hando ve r de células intraBSC (falta de recursos de radio) + TCH seizure failures para hando ve 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 ve r de células intraBSC + Attempted TCH seizures for interBSC)
    9. 9. Página 9 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH Channel_Active Channel_Active_Ack IMMEDIATE ASSIGN COMMAND BTS BSC MSCMS Channel_Req first SABM Establish_IND( CM Service Req) CR(Complete_l3_information) CC Setup Call Proceeding Assignment_Req ASSIGNMENT COMMAND first SABM Establish_IND ASSIGNMENT CMP Assignment_CMP Alerting Connect Connect Ack Communication Disconnect Release Release Complete Clear_CMD Clear_CMP CM Service Accepted Channel_Active Channel_Active_Ack UA SDCCH SDCCH 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
    10. 10. Página 10 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Ponto de medida - Atte m pte d TCH se iz ure s  Atte m pte d TCH se izure s para chamada  Recebeamensagemassignment request daMSC  Atte m pte d TCH se izure s para ve ry e arly assig nm e nt  Quando não hárecursosparaalocação deSDCCH eépermitido o very early assignment.  QuandoasolicitaçãodecanalérecebidaeotipodecanaléTCH  Attempted TCH seizures para hando ve r intraBSC  Quando a mensagem de solicitação de handover intraBSC é recebida(non-SDCCH handover request).  Attempted TCH seizures para hando ve r interBSC  Quandoamensagem desolicitaçãodehandoverinterBSCérecebida (handover type is non-SDCCH)
    11. 11. Página 11 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Falhas de TCH seizure:  TCH seizure – falha na chamada,  TCH seizure – falha no very early assignment,  TCH seizure – falha no hando ve r interBSC,  TCH seizure – falha no hando ve r intraBSC,  TCH seizure – falha no hando ve r entre células.
    12. 12. Página 12 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Ponto de medida – Falha de TCH seizure na chamada:  (1)CONN_FAIL mensagem recebida no procedimento de assig nm e nt.  (2)CLEAR_CMD recebida no processo de saída da BSC durante o hando ve r. A causa é o Direct Retry.  (3)CLEAR_CMD recebida no procediemento de assig nm e nt.  (4)RR_ABORT_REQ recebida no procedimento de saída da BSC durante o hando ve r e a causa do handover é um dire ct re try.  (5)RR_ABORT_REQ recebida no procedimento de assig nm e nt.  (6)MSG_HO_REQ_REJ recebida no processo de saída da BSC durante o hando ve r (dire ct re try).
    13. 13. Página 13 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Ponto de medida – Falha de TCH seizure na chamada :  (7) HO_FAIL mensagem recebida na saída da BSC durante um hando ve r (dire ct re try).  (8) ERR_IND recebida no procedimento de assig nm e nt.  (9) Quando a mensagem de assig 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)
    14. 14. Página 14 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Ponto de medida – falha de TCH se iz ure para ve ry e arly assig nm e nt:  (1)CH_ACT_NACK é recebida no processo de ve ry e arly TCH assig nm e nt. (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 tim e o ut no processo very early TCH assignment.
    15. 15. Página 15 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Ponto de medida - Falha de TCH seizure para hando ve r intraBSC:  Falha de alocação de TCH no hando ve r intraBSC  Ponto de medida – Falha de TCH seizure para hando ve r inte rBSC:  Quando não há TCH disponível a mensagem inte rBSC inco m ing ce llhando ve r failure é enviada.
    16. 16. Página 16 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento 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 Intrace ll Hando ve r Re q ue st 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
    17. 17. Página 17 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Ponto de medida - falha de TCH seizure devido a falhas na interface A:  Interface A  Apósoenviodamensagem Assignment_ReqpelaMSC, sehouverfalhanos circuitosde tronco da interface A a BSC irá retornarAssignment_Failure diretamente.  Nestecaso, geralmenteacausaéaincorretadesignação doscircuitosde tronco(CIC).
    18. 18. Página 18 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Falhas de TCH seizure devido a falhas nas interfaces Abis e Um:  Interfaces Abis e Um  1. FalhadaplacadeTRXouinstabilidadedeperformance  2. Níveldedesbalanceamentoentreuplink/downlinknaBTS  3. Baixaqualidadedesinaldeuplink/downlinkdevidoainterferência  4. SDCCH e TCH pertencentesa diferentesTRX que realizam diferentes coberturas
    19. 19. Página 19 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Causas para um alto congestionamento de TCH  Causas  Manutenção
    20. 20. Página 20 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 hando ve r provocadas por Co -fre q üê ncia e co -BSIC, levando a um TCH assig nm e nt failure  Falha ou instabilidade em placas de circuito  Hardware da BTS não instalado corretamente, provocando desbalanceamento entre sinais de uplink/do wnlink.  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 assig nm e nt failure devido a topografia e isolamento do site.
    21. 21. Página 21 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Como localizar as causas para a alta taxa de congestionamento de TCH  Analisando as causas de congestionamento remotamente  1. EstatísticasdeTráfego  2. InformaçõesdeAlarme  3. ManutençãodaBTSremotamenteatravésdoOMC  4. AnálisedemensagensnainterfaceAbis  Verificação da BTS o n-site
    22. 22. Página 22 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Análise Remota 1: Estatísticas de tráfego  Em “TCH Me asure m e nt Functio n”, verifique se os canais estão todos ocupados ou não  Sesim, realizeumload handover ousugiraexpansãodacapacidade.  Senão, verifiqueasbandasdeinterferência1~5. Seconstatadaainterferência, ataxaquedadechamadasnacélulaprovavelmenteseráaltatambém.  Registre uma “Re ce iving Le ve lMe asure m e nt Functio n”  1. Verifiqueoresultadoporobjetoevejaquandoosnúmerosdosrelatórios parauplink e downlink estão balanceados em uma mesmaplacaTRX.  2. Verifiqueoresultadoportempoparaverquandoasmedidasnosrelatórios são elevados. Desta forma pode-se verificarse o congestionamento está relacionadoàplacaTRXounão.
    23. 23. Página 23 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento 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.
    24. 24. Página 24 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento 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.
    25. 25. Página 25 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  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 Assig nm e nt CMD enviado no SDCCH  Seo assignment sempreresultaem falhaparaum TRXespecífico, a causamaisprovávelpodeserumadasseguintes: – Falha ou instabilidade na placa TRX – Desbalanceamento ou problema de hardware no Uplink/do wnlink – Baixa qualidade dos sinais de uplink ou do wnlink. Analise o valor do TA da MS para identificar o problema.  Seoassignment falhaemtodasasplacasreferentesàcélula, deforma aleatória, analiseorelatóriodemedições. Ascausaspodemserasseguintes: – 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.
    26. 26. Página 26 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH
    27. 27. Página 27 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de TCH  Verificação da BTS o n-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 assig nm e nt 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 hando ve r e interferências no do wnlink.  Procure por fontes de interferência utilizando um analisador de espectro.  Observe se a topografia na área de cobertura da célula é complexa.
    28. 28. Página 28 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 do wnlink  Caso 5: Efeitos do repetidor na célula  Caso 6: Outros erros de configuração  Caso 7: Site isolado e topografia complexa
    29. 29. Página 29 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 hando ve r) de toda a rede aumentou 4% e que a maioria das células estavam com nível de congestionamento elevado.
    30. 30. Página 30 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 se izure failure através das estatísticas de tráfego e finalmente localizar o problema (seja ele causado por configuração de dados ou hardware ).
    31. 31. Página 31 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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.  Analiseasestatísticasdetráfegoeprocureporcongestionamentosemcélulas deummóduloespecíficodaBSC(célulasdomódulo1, 2, ...).  Verifique se as TCH seizure failures (requested terrestrial resource unavailable). Issodemonstraquea faltaderecursoséaprincipalcausadoaltocongestionamentodomódulosob análise.  A causaparaterrestrial resources unavailability é relacionadaprincipalmenteàsinterfacesA eAbis. Époucoprovávelquea interfaceAbissejaresponsávelporfalhasdediversascélulasaomesmotempo em um mesmo módulo, portanto podemos voltar a atenção para o hardware eaconfiguraçãodedadosdainterfaceAdestemódulo.
    32. 32. Página 32 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Estudo de Casos – Congestionamento de TCH  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 tim e slo 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).
    33. 33. Página 33 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Estudo de Casos – Congestionamento 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á.
    34. 34. Página 34 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 Erlna hora de maior tráfego.  Ao mesmo tempo, o número de “TCH se izure failure s fo r call(no radio re so urce )” é 0.  Observou-se que o estado dos todos canais na célula 1 = “idle ”.
    35. 35. Página 35 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Falha na placa TRX  Caso 2 – Análise:  1. Nenhuma configuração de dados fora efetuada e não existe ho pping 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 assig nm e nt failure .  3. Descobrindo o TRX relacionado com a falha, tente localizar a falha no TRX que pode ser relacionada com o assig nm e nt faiIlure . Confirme se a falha persiste após um re se t e substitua o TRX.
    36. 36. Página 36 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Falha na placa TRX  Caso 2 - Manutenção:  1. Verificando o estado dos BT channe 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 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.
    37. 37. Página 37 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Falha na placa TRX  Caso 2 – Conclusão:  1.Falha na placa TRX provoca alta taxa de congestionamento e TCH se 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.
    38. 38. Página 38 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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.
    39. 39. Página 39 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no uplink  Caso 3 - Análise:  Verificando o hardware da BTS a procura de falhas:  Falhadehardware: acomunicaçãoestavanormalparatodasascélulas, portantodescartadaapossibilidadedefalhadehardwareparaasmesmas.  Conexõesdehardware: analiseasestatísticasdetráfegoparaouplink eo downlink, verificandotambémasconexõesparaambasasdireções.
    40. 40. Página 40 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no uplink  Caso 3 - Manutenção:  Foi registrada uma “Re ce iving Le ve lMe asure m e nt Functio 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 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.
    41. 41. Página 41 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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. 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 Module ID 1, Cell ID 5, TRX No. 16 Module ID 1, Cell ID 5, TRX No. 17 Problema de hardware no uplink  Caso 3
    42. 42. Página 42 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no uplink  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 “Re ce iving Le ve lMe asure m e nt Functio n”.
    43. 43. Página 43 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no Do wnlink  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.
    44. 44. Página 44 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no Do wnlink  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.
    45. 45. Página 45 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no Do wnlink  Caso 4 - Manutenção:  Realizando um trace na interface Abis da BTS e analisando a sinalização, foi verificado que no processo de TCH se izure 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 do wnlink.  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.
    46. 46. Página 46 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de hardware no Do wnlink  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.
    47. 47. Página 47 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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%.
    48. 48. Página 48 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Efeitos do Repetidor na Célula  Caso 5 - Análise:  Como o congestionamento apareceu após a expansão:  Verificou-seaocorrênciaparatodosTRX. Casoaverificaçãofossepositiva, uma reavaliação dasconexõesdo novo hardwaredaBTSserianecessáriapara localizaçãodefalhas.  CasooproblemaapontasseparaumoupoucosTRX, apenasessesseriamalvo deanálisedehardware.  Excluindo-seoproblemadehardwarenosite, causasexternaspassam aser alvo deinvestigação. Porexemplo, um repetidorquenãosofreu adevida expansãofoi ocausadordosproblemasdeassignment failure.
    49. 49. Página 49 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Efeitos do Repetidor 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 assig 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.
    50. 50. Página 50 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Efeitos do Repetidor 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 assig nm e nt failure .
    51. 51. Página 51 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Outros erros de configuração  Caso 6 – Descrição da falha:  Na otimização da rede, a taxa de congestionamento (incluindo hando ve r) nas horas de maior tráfego atingia 10% para duas células. As “TCH se izure failure s e xcluding hando ve r” e “TCH se izure failure s fo r call (no radio re so urce )” estavam normais. Neste caso a “TCH se izure failure s (all)” indicava 89, mas as “TCH se 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.
    52. 52. Página 52 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Outros erros 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 ve 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 ve r (se normal ou não).
    53. 53. Página 53 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Outros erros de configuração  Caso 6 – Manutenção:  Registrando uma “Inco m ing Inte r Ce ll Hando ve r Me asure m e nt Functio n” durante 15 minutos e procurando por falhas de hando ve 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 ve rs significa que existe problema com a configuração de dados de hando ve r. Verificando esses dados, constatou-se que havia “co -fre q üê ncia ” e “co -BSIC”. As duas células eram adjacentes à célula A, portanto o hando ve r para as duas células falhavam.  Alterando o BCCH e o BSIC de uma das células o problema de hando ve r foi solucionado, desaparecendo também o problema de congestionamento.
    54. 54. Página 54 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Outros erros de configuração  Caso 6 - Conclusão:  Duas células, ambas adjacentes à célula A com “co -fre q üê ncia” e “co -BSIC” resultavam em baixa taxa de sucesso de hando ve r e também alta taxa de congestionamento de TCH incluindo hando ve r.  Este caso indica que as taxas de congestionamento de TCH com e sem hando ve r eram diferentes.
    55. 55. Página 55 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 hando ve r), variando de 3 a 10% (na proporção do volume de tráfego). Entretanto as “TCH se iz ure failure s fo r call(no radio re so urce )” indicavam 0%.  1. Bloqueandoos2TRX(um porvez), ataxadecongestionamentonãose alteravasignificativamente.  2. Outrosíndices: ataxadecall drop estavaem 5% eainterferência apresentavavaloresnormais.
    56. 56. Página 56 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Site isolado e topografia complexa  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 assig nm e nt failure a taxa de queda de chamadas foi considerada juntamente com a performance do uplink e do wnlink no que se refere ao nível e qualidade dos mesmos.
    57. 57. Página 57 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Site isolado e topografia complexa  Caso 7 - Manutenção:  Verificando a “Call Dro p Me asure 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 ce iving Le ve l Me asure m e nt Functio 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 uplink estava muito baixo (cerca de -98dBm) quando ocorria o assig nm e nt fails.  Um drive te st 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 wnlink é de cerca de -90dBm, entretanto no uplink o sinal não é suficiente, gerando portanto o TCH assig nm e nt fails.
    58. 58. Página 58 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Site isolado e topografia complexa  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 “o ve r sho o ting ” no do wnlink.
    59. 59. Página 59 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Conteúdo 1. Congestionamento de TCH 2. Congestionamento de SDCCH
    60. 60. Página 60 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de SDCCH  Congestionamento de SDCCH  Princípios Básicos  Causas e Soluções para congestionamento de SDCCH  Estudos de Casos de congestionamento de SDCCH
    61. 61. Página 61 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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
    62. 62. Página 62 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento de SDCCH MS BTS BSC MSC BSC random access – immediate assignment Cell SDCCH seizure request times Channel Required Channel 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
    63. 63. Página 63 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Causas e soluções para o congestionamento de SDCCH  As fronteiras de uma lo catio n are a são fonte de excessivas tarefas de lo catio n update e SDCCH atte m pt  Otimização do projeto da lo catio n are a  Modificação do CRH (Ce llRe se le ct Hyste re sis )  Modificação do T3212 para o lo catio n update periódico da BSC  Solução de problemas de hando ve r entre redes dual-band  Quantidade excessiva de sho rt m e ssag e s  Adição de canais SDCCH  Habilitação da função de alocação dinâmica de SDCCH
    64. 64. Página 64 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Congestionamento 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 e xte nde d transm issio n tim e slo ts  Falhas de placas (TRX) e problemas de transmissão também resultam em congestionamento de SDCCH
    65. 65. Página 65 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Estudos de Casos – Congestionamento de SDCCH  Casos de congestionamento de SDCCH  Caso 1: Excesso de lo catio n update  Caso 2: Falha de placa no equipamento de transmissão  Caso 3: Problema de transmissão de tim e slo t no m ux
    66. 66. Página 66 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Excesso de lo catio n update  Caso 1 – Descrição da falha:  A taxa de call se tup succe ssful em uma dada rede estava baixa. Analisando as estatísticas de tráfego constatou-se o congestionamento de SDCCH em alguns sites.
    67. 67. Página 67 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Excesso de lo catio n update  Caso 1 - Análise:  Sendo pequeno o número de BTS congestionadas, registrou-se uma “SDCCH Me asure m e nt Functio n” e procedeu-se com a análise da taxa SDCCH se izure para diferentes causas, com a finalidade de se encontrar o real motivo para o congestionamento de SDCCH.
    68. 68. Página 68 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Excesso de lo catio n update  Caso 1 – Manutenção:  1. Registrando uma “SDCCH Me asure m e nt Functio n”  Nacélulacongestionada, ovalordeSDCCHattemptedchegavade300-400vezesemuma certahora. A configuraçãodossiteseraS1/1/1. Cadacélulaeraconfiguradacom canal SDCCH/8. Normalmenteéum númerosuficienteparasuportaressesvaloresde300-400 vezes, entretantoexistiam dezenasdecongestionamentosdeSDCCH paracadacélulana horademaiortráfego.  Foi constatado que a maioria dosSDCCH seizures estavam relacionadoscom location update. Analisandoalocalizaçãodascélulas, foi verificadoqueasaquelas que apresentavam congestionamento se situavam na fronteira de duaslocation areas atravessadasporumalinhaférrea, equeamaioriadoslocation update estavam localizadosem um intervalode5minutos. Investigandoohoráriodostrens, foi constatadoque4a5trenspassavam dentrodaqueleintervalodetempo, ocasionando portantotodootráfegodeMSssolicitandolocation update.  2. A adição de SDCCH ou habilitação da função de alocação dinâmica de SDCCH resolveu o problema.
    69. 69. Página 69 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Excesso de lo catio n update  Caso 1 - Conclusão:  Para casos de congestionamento de SDCCH devido a lo catio n update , verifique quando esse acontecimento é causado por configuração inadequada da lo catio n are a. Adicione canais SDCCH ou habilite a função de alocação dinâmica deste para solucionar esses tipos de problema.
    70. 70. Página 70 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 se izure failure atingia valores superiores a 1000 (na hora de maior movimento).
    71. 71. Página 71 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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-seprimeiramenteosdadosdeconfiguraçãoeohardware. Devidoao fatodetodoositesofreroproblemadecongestionamento, fazendoatroca doenlaceAbiscomoutrositedemesmaconfiguração, confirmou-sequenão haviaproblemasdehardwareouconfiguraçãodedadosrelativosainterface Abis.  Passou-seentãoparaaanálisedosistemadetransmissãodainterfaceAbis.
    72. 72. Página 72 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 re co ve 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 se 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.
    73. 73. Página 73 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. 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 assig nm e nt eram perdidas, gerando re-envios que ocasionavam o congestionamento.
    74. 74. Página 74 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de transmissão de tim e slo 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.  Verificou-seos4sites, osestadosdasplacasestavamnormais. Quasenenhum canalTCHapresentavaTCH seized successfully. Algumasvezes oestadodeumTCHestavaem“A”, masretornavapara“I” dentrodealguns segundos.  OengenheirodeoperaçõesinformouqueaBTS-AestavaconectadaàsBTSsB, C e D, compartilhando o mesmo E1 (transmission timeslot multiplexer).
    75. 75. Página 75 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de transmissão de tim e slo 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.
    76. 76. Página 76 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de transmissão de tim e slo 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.
    77. 77. Página 77 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de transmissão de tim e slo t no Mux  Caso 3 – Manutenção:  5. Foi realizada um re se t no equipamento MUX e um re se t 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.
    78. 78. Página 78 Copyright © 2006 Huawei Technologies Co., Ltd. All rights reserved. Problema de transmissão de tim e slo 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.
    79. 79. Obrigado www.huawei.com

    ×