lte_rl40 1.0 release documentation.en.pt

LN4.0 1.0 Versão de Manutenção

Id: LTE_RL40_1.0 Família de produtos: Estações Base Produto: Flexi Multiradio BTS LTE Lançamento: LN4.0 1.0

Data de Aprovação: 03-Julho-2013

Nome do documento:

LTE_RL40 1.0 Resumo de correções e aprimoramentos

LTE_RL40 1.0 Mudança Nota Formas

LTE_RL40 documento 1.0 Impacto

LTE_RL40 Instruções 1.0 Instalação

LTE_RL40 1.0 SW relatório de verificação de atualização

LGF-LTE-RL40-2013-w20

Contato Contacte o apoio local da Nokia Siemens Networks

Resumo das alterações:

2013/05/17 2013-05-31

V 1.0 V 2.0

Versão aprovada Atualizado: - Documento LGF (notas adicionado ao NA05257421 e NA05190578), - Resumo de correções e Melhorias e Mudança Nota Formas documentos (removidos do conteúdo: CRL0799 - Addl RF-Sharing Configurações LTE-GSM para RL40) Atualizado Instruções de instalação documento

2013/07/03 V 3.0

LTE_RL40_1.0 Startpage A Nokia Siemens Networks © CONFIDENCIAL APROVADO 3.0

Resumo de correções e

Melhorias

ID: Solte entrega: Família de produtos: Produto: Lançamento:

Data de Aprovação:

LTE_RL40_1.0

RL40 1,0

Estações Base

Flexi Multiradio BTS LTE

LN4.0 1.0

31-May-2013

CONFIDENCIAL APROVADO 2.0

Resumo LTE_RL40_1.0 de correções e aprimoramentos A Nokia Siemens Networks ©

1 (23)

Índice

1. 2.

2.1 2.2 2.3

Propósito ......................................................................................................................................................... 3 Correções .................................................................................................................................................... 3

Novas correções de clientes documentado em mudar as notas ........................................... ........................................... 3 Novas correções internas documentado em mudar as notas ........................................... .............................................. 4 Novas correções internas e correções de clientes não documentada em mudar as notas ....................................... 4 ..

3. 3.1 3.2 3.3 3.4

Nova funcionalidade / Mudado ......................................................................................................................... 4 Nova funcionalidade ...................................................................................................................................................... 4 Recursos liberados ................................................................................................................................................... 5 Restrito recursos liberados .................................................................................................................................. 8 Recursos não liberados ............................................................................................................................................ 8

4. 4.1 4.2 4.3

Características do Legacy Estado ................................................................................................................................ 9 Características do Legacy Lançado ...................................................................................................................................... 9 Restrito recursos herdados Lançado ................................................................................................................... 17 Características do Legacy não liberados .............................................................................................................................. 20

5. 6. 7.

7.1

Correções terceiro partido ................................................................................................................................... 20 Partos anteriores para a liberação .............................................................................................................. 20 Lançamentos objects......................................................................................................................................... 21

eNB lista de arquivos Software .............................................................................................................................................. 21 8. Apêndices / Reference .............................................................................................................................. 21

Contato Contacte o apoio local da Nokia Siemens Networks

Resumo das alterações

2013/05/17 2013-05-31

V1.0 V2.0

Versão aprovada Atualizado capítulo 3.1 (removido do conteúdo: CRL0799 - Addl RF-Sharing Configurações LTE-GSM para RL40)


LTE_RL40_1, 0 Resumo de correções e melhorias A Nokia Siemens Networks ©

2 (23)

1. PROPÓSITO

O objetivo deste documento é dar um breve resumo sobre as correções Atualização de entrega conteúdo.

2. CORREÇÕES

2.1 Novas correções de clientes documentados em mudar as notas

Pronto ID Título

NA05311458 NA05319825 NA05320886 NA05325301 NA05329182 NA05329849

RL30: PLMN errado em S1 TAI após S1 Entrega Problema com LTE PS Handover para WCDMA Falha na relação RP3 óptico Alarme ocorreu devido a KEEPALIVE expirou. Mudanças Site-ID em BTS Manager não visíveis no Editor de CM No PCI alarme duplicação (6307) ocorreu em TD4.1 ETR-000051875: Depois de muitas tentativas no campo e no escritório, temos as seguintes observações: - O localização para o Avanço obter resultados satisfatórios THR 55-60Mbps DL / UL 40Mbps (TCP e UDP transmissão) BT11446 AL. Wilanowska muito FSP acidente no MAC-PS (F2C1) Alinhamento Alarm 'falha de conexão da camada de transporte na interface de X2' / muitos ERAB liberar Contador Incompatibilidade Frig não pôde ser detectado (falha na interface do RP3 óptico) após eNB desceu com problemas de GPS Não pode desbloquear fôrma FSMF eNB reinicialização espontânea no modo de teste Dedicado Falta de ativação do plano no log de feedback - reiniciar parcialmente eNodeB necessário FSMF-NTP Interrupção alarmante com novo módulo HW FSMF Teste do site não é suportado com: software LN4.0_ENB_1202_689_00. "Certificado de fornecedor em falta" LTE RL30 Nenhuma chamada possível após MME interrupção recuperado FTM reiniciado devido a falha de SW (SmaAsn1is terminado) Esporadicamente FHCCs são perdidas durante a ficha do cabo ótico / teste desligue e células configuradas finalmente vai para defeituoso por 1868 em modo acoplado Falha ID 2016 Nome Solicitação de Mudança de redefinição Autónoma como ação de recuperação em vez de falha ônibus Baseband Falha na relação RP3 alarme óptico 'foi visto por FRIE-3 após a atualização para 1202_689_00 Inter-Vendor HO falha com habilitado RoHC Vazamento de memória BTSOM ocorreu quando o módulo RF é bloqueado e desbloqueado repetidamente. eNB autónoma reinicialização devido ao 'EFaultId_NoConnectionToUnitAl' (ID: 10) para FSPD observada num sítio descarte de pacotes devido a protocolo não suportado contado como ifInErrors15 DR E-RAB (LTE_5025C) e UEs RRC Conectado (LTE_1076A) aumentaram após a atualização RL40 P8 PM arquivos não são compactados em eNB e por isso não coletados em IOMS DL LTE rendimento com RL40 menor do que o esperado RACH SSR KPI é '0 'após o upgrade MP3.1.4 SW RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente. BTS reset é necessário FSMF Precoce Projeto :: 1 +1 +1 com RF Módulo FRHA 20 Mht BW, terceiro setor não está funcionando FXEB relata alarme 'Módulo RF detectou nenhum poder TX em bloco filtro interno' Pantech móvel Volte ROHC CRC falhar FSMF projeto cedo: LTE83: FSMF - Teste Negativo (alarme Fan) - teste falhou RF Módulo Bloquear falha ocorreu em BTS Site Manager para a recuperação de RP3 10 após RL40 0.0.2 SW Atualizado Alarme de interface X2 (6203), não sendo apagada, porém verdadeira ligação X2 está disponível Samsung Galluxy S3 que apoiou Único Band (5) inter-Frequency HO de 2,1 g de 850M Failure FHCAs ficou inicialização falhar depois de atualização de software do MP3.1.4 para MP3.1.5 (SW 4.0.711) Configuração incompleta que incompatibilidade de Recursos celular comissionamento arquivo logo após a eliminação de células Células deficientes são causados por alto tráfego - FSP colidiu com falhas 418 Falha Tx incorreta no MIMO visto em alguns RL40 0.0.3 eNBs Problema com o contadores M8013C6, -7, - 8, -27) Insucesso do RET antena relatados com alarme errado Partilha RF cabeamento pode bloquear eNB RL40 Aceitação - X2 Atualização da Huawei eliminado Vizinho Relacionamento RL40 LTE FOA - FALHA NA RP3 OPTICAL INTERFACE

NA05331292 NA05331783 NA05331811 NA05332612 NA05332769 NA05335948 NA05336271 NA05336319 NA05338227 NA05338446 NA05338687 NA05338815 NA05338860

NA05338922 NA05339343 NA05340039 NA05341814 NA05342285 NA05342354 NA05342431 NA05344350 NA05346724 NA05347970 NA05348549 NA05348560 NA05349186 NA05352288 NA05353417 NA05353538 NA05353720 NA05355368 NA05356052 NA05356669 NA05356792 NA05360584 NA05354601 NA05341112 NA05356261 NA05366479 NA05334838



3 (23)

2.2 Novas correções internas documentados em mudar as notas

Pronto ID Título

122788ESPE02 38487ESPE07 39845ESPE05 40184ESPE05 40503ESPE05 41295ESPE05 90110ESPE01 90367ESPE01 92204ESPE01

125929ESPE02 92663ESPE01

[LNT3.0] 1232 fatal quando fazer a entrega por muito tempo FSMr3-LTE1432-eNB queda observada em permitir que o tráfego de recurso de espelhamento. FSMr3 última FHCC (1.6.1) e / ou juntamente FXEB (1.6.2) não detectado Falha na relação RP3 óptico Alarme devido a FPGA pino de reset capacitância parasítica Alta perda de desempenho de rádio na configuração de alta velocidade Multicélula. [+ FSMr2 FSMr3] [LN4.0] AutoReboot após OnAir FLDA (MHA) não é encomendado após o bloqueio BTS / desbloquear [LNT3.0] detecção FSP3 falhou quando BTS startup Alarm 'Falha na interface do RP3 óptica (0010) "é acionado usando FSM eIF2 para a interface RP3 e FTIF eIF3, 4 Sametime. Após MME restart eNB é preso em estado configure setup pedido S1 não enviou ao MME [LN3.1] status operacional da célula torna-se eNodeB disable devido ao BCN nenhuma resposta 200UE depois anexada com modelo de tráfego 11 e configuração 7 para 15 minutos

2.3 Novas correções internas e correções de clientes não documentada em Mudança Notas

Pronto ID Título

NA05312256 NA05257421 NA05190578 124914ESPE02

Falha no módulo LTE RL30 Mp3.1.1 RF (1907) para cerca de 1 segundo presente Falha do módulo RF (1907) RL20: repetição da falha no módulo RF Alarm FSM3: FSMF A.102 uboot rebaixamento não é possível

Para informações mais detalhadas sobre os relatórios de falhas abertas e corrigidos consulte LGF-relatório em "LGF-LTE-RL40-2013-w20.pdf".

3. NEW / funcionalidade alterada

3.1 A nova funcionalidade

Pronto ID Título

CRL0822 CRL0822 CN5391 CRL0896 CRL0767 CN5408 CRL0823 CN5551 CN5394 LBT1758

Atribuição flexível de links X2 - C-Plane perfil de desempenho Atribuição flexível de links X2 - otimização de desempenho C-Plane Recuperação para sincronismo Corrupted Air Depois de perder OBSAI Mensagens Permitir LTE979 IRC também sem sincronia GPS Mirroring Integrado de tráfego para FSMr3 Reno RRH Antena Trocar para LTE, WCDMA e GSM CR Supervisão Memória AWS 4X4 RRH HW atualização diferença para ver1.3 Atribuição de certificados CVendor em fase de testes bordo e fase de testes do módulo para FSMr3 Suporte para colocação manual dos FLDA dupla MHA dual band EU800/900



4 (23)

3.2 Características Lançado

ID

46

48

179

440

494

495

496

497

519

524

Nome do recurso

Scheduler Canal-aware (UL)

Suporte de Usuários alta velocidade

Band Dual com um módulo do Sistema

Manipulação S1 Overload

Comercial Sistema de Alerta Móvel

OTDOA

Suporte de QCI 2, 3 e 4

Admission Control Inteligente

ERAB Modificação

Gerenciamento de certificados para IOMS

Área Solution

Cobertura, capacidade e taxas de pico Básico gestão de chamadas e LTE interoperação BTS Solution Site

Básico gestão de chamadas e LTE interoperação QoS, serviços e usuários finais experiência QoS serviços e usuário final experiência QoS, serviços e usuários finais experiência QoS, serviços e usuários finais experiência QoS, serviços e usuários finais experiência OMS características específicas

Operador Hint

Operador dica para IOMS:

Implantação 1.Remote de endereço IP CA / 's CR, IP-porta, URL e CA Assunto-nome na OMS retorna errado errorReply, embora estes parâmetros de cliente CMP foram definindo com sucesso. por exemplo: [Omc1 @ CS-1 ~] $ n3factmx-flt PLMN- CERTH PLMN/OMS-44 fragmento set-baseId N3MD-OMS-44-localMOIDs DN: NULL-0-u Nemuadmin-p-nemuuser cmpRecipient 'C = FI, O = NSN, CN = MRTAmpereNewRootCA ' ... [Text = 'errorReply' obtido a partir do mediador: N3MD-OMS-44 Id Task: Código de erro 0: 99 LocalMOID: DN: NULL-0 Erro: ESPECÍFICA ERROR] [Detalhes = não é possível definir parâmetros OMS CertMan] ...

Pls verificar IOMS as alterações de parâmetros com # omscertificate show-cmp-config e ignorar o acima errado errorReply enviado por IOMS para NetAct. Operador dica: Portador de Controle Combinação (BCC) restringe sem máximo de DRBs a 6 por UE. Quando 7 DRB (E-RAB) - que é preempção capaz e tem maior prioridade que alguns dos de preferência ao portador vulnerável / s existentes - é estabelecida, provoca UE libertação contexto iniciada pela eNB. Este problema não pode ser observada quando o No. de portadores existentes + Número de a ser portadores de configuração <= 6

534 Controle de Admissão à base de ARP para o E- RAB

QoS, serviços e usuários finais experiência

587

593

612

Vários GBR EPS Portadores por UE

Segurança para portas Ethernet

Hub Sincronização

QoS, serviços e usuários finais experiência O & M Segurança

Transmissão Operador Dicas para FSMF: 1. O sinal de saída fornecido utiliza como 2.048MHz interface de um sinal eléctrico LVTTL, ao mesmo tempo que deve ser um Sinal ITU G.703. O cabo de sincronização FTSK atualmente disponível

o sinal 2.048MHz.

2. Uma CR está em preparação, que deve mudar o 2.048MHz interface elétrica de LVTTL para ITU G.703



5 (23)

ID Nome do recurso Área Solution Operador Hint

compliant. Assim que isso for implementado, pode mudar a pinagem. Cabo de sincronização atual FTSK será, então, ok,

FMSF HDMI IN) precisa de uma mudança. 1 sinal PPS não é afetado.

3 Em caso.: 1) eNB está configurado na sincronização mode = fase sincronização 2) eNB está entrando no modo controlado (1 PPS IN sinal é gone) 3) um restart eNB é realizada faz o eNB não fornecer mais tempo um sinal PPS OUT eventhough ext1ppsClkOutOn é definido como verdadeiro. Uma vez eNB está deixando modo controlado (1 PPS IN sinal é volta novamente) o 1 PPS OUT é fornecido novamente.

621

622

623

628

646

736

763

843

872

877

947

949

950

953

Flexi 10BTS Configurações Básicas

Local Link Layer Segurança

Crypto Agent

FTIF Transporte PDH / Ethernet

Extensão Monitoramento SW com PM Contadores CS Fallback para UTRAN

FXFA Flexi Módulo RF 3 do setor 1900

ETWS transmissão

SRVCC para WCDMA

Ajustável Carregar Desempenho

10 Sistema FSMF Flexi Multiradio Módulo FPFD Flexi Distribuição de Energia Sub- módulo Módulo de Distribuição de Energia FPFC Flexi

MDT (Minimização de Test Drive)

BTS Solution Site

O & M Segurança

O & M Segurança

Transmissão

Gerenciamento da Configuração

Mobilidade

BTS Solution Site

QoS, serviços e usuários finais experiência Mobilidade

Monitoramento de desempenho

BTS Solution Site

BTS Solution Site

BTS Solution Site

Operacionalidade Por favor, consulte também ohs e restrições previstas traço célula característica LTE644 básica!

Operador dica: Criação de mais de um MDT com traça perfil: MDT_mon_quality é possível, mas só um é recomendado.

979

984

1014

1019

IRC para 2 RX Caminhos

GSM Redirect com informações do sistema

Update Configuration X2 eNB

FILHO Relatórios

Cobertura, capacidade e taxas de pico Mobilidade

Básico gestão de chamadas e LTE interoperação Gerenciamento da Configuração Dica operador comum a implementação atual:

CM história mostra todas as alterações dos parâmetros da rede. FILHO relatórios são especialmente entradas marcado em CM História para alterações de parâmetros relacionados com características Filho. FILHO solução de relatórios em RL40 funciona apenas para SON Central recursos (consulte a CRL0640). FILHO Reports para de-centro ANR recursos fazem parte de um recurso separado previsto para lançamentos futuros.

Nota: Função de pesquisa em História CM com a seleção em uma



6 (23)


região de manutenção no maior topologia da rede pode ser muito lento.

1040

1045

FXEB Flexi Módulo RF 3 do setor 1800

Suporte FILHO completa para sites distribuídos

BTS Solution Site

Gerenciamento da Configuração Operador Dica: Geo-localização são obrigatórios para ser configurado em NetAct para cada antena para sites distribuídos. Além disso, todos eNBs precisa de um Objeto-site atribuído a um objeto-LNBTS. Caso contrário, as funções FILHO abortar.

1073

1078

Medição baseada em Redirecionar para UTRAN Atualização do Sistema

Mobilidade

Gerenciamento da Configuração Dicas Operadora:

NetAct: 1. Sob condição especial que os números de instância de LNADJW não começam com zero no arquivo de configuração eNB: NetAct Configurador / CM Editor de mostrar após a atualização de eNB de RL30 para RL40 eo primeiro carregamento CM ainda Objetos LNRELW de RL30 e duplicado adicional Objetos LNRELW. Portanto, qualquer provisionamento CM faria falhar. Solução alternativa: Execute um segundo carregamento de CM NetAct antes de provisionamento CM.

2. Não é possível criar uma nova MO em RL40 quando ainda um arquivo de plano de RL30 existe que cria / deleta / modifica o mesmo MO ID e mudanças em PDDB para esta classe de objeto foram feitas em RL40 em comparação com RL30. Solução: Excluir arquivos de plano RL30 já não são necessários antes de começar a criar / modificar / apagar MOs com o mesmo ID no arquivo de plano de RL40.

eNB: 3. RL40 Depois de fallback para RL30 eNB é esporadicamente não comissionado, esta questão só foi observada quando em operação CM paralelo foi feito. Preventivo ação / Solução: Não execute outras operações de CM quando fallback é necessária.

Para mais soluções e dicas de operação referem-se também a documento LTE_RL40 Lançamento Atualização Instructions.doc.

1148

1201

1222

1261

1306

1340

1387

1457

FRIG Flexi RRH 4TX 1.7/2.1

LTE IOMS HW, HP Lâmina Gen8

Modos de automação FILHO

FHDB Flexi RRH 2TX 900

FRMD Flexi Módulo RF 3 do setor 800

Trace-base Monitoramento em Tempo Real

Intra-eNB Inter-freqüência de carga Equilibrar Configuração celular de rastreamento via CM

BTS Solution Site

Complementar O & M recursos Gerenciamento da Configuração

BTS Solution Site

BTS Solution Site


Cobertura, capacidade e taxas de pico O & M



Dicas Operadora: 1. É possível criar duas MTRACEs com a mesma traçar ID. A ativação do segundo traço celular irá falhar eo TraceFailure mensagem é enviada. Também um transiente alarme é disparado. Como a mensagem é traceFailure apenas visível no wireshark eo alarme é transitória apuradas depois de alguns segundos, o operador faz mal notar que a ativação do rastreamento de celular falhou. 2. O parâmetro "referência sessão de gravação Traço" é um parâmetro obrigatório, embora não seja necessário. É estabelecido pelo sistema de identificação de cada chamada em uma célula e

7 (23)


está escrito em Relatório de rastreamento para a célula. Assim, qualquer valor entre 0 e 65535 podem ser inseridos. 3. Quando o operador entra em um identificador de célula errada a CM operação será bem sucedida eo mtrace será criado. Não há alarme e nenhum indício de que o traço é não ativado. 4. Com operação CM é possível alterar o parâmetro "celular Trace Mode". Isto não tem efeito para o traço célula atual.

CR L0617 CR L0632 CR L0650 CR L0661 CR L0678 CR L0679 CR L0703 CR L0725 CR L0728 CR L766

Aumento gama CQI

Modo de Espera balanceamento de carga mobilidade Suporte LTE externa da pilha em NetAct (RL40) Aumentar a quantidade de células eNB vizinho 12 Limite ANR vizinho adições RL40.

Ferramenta de apoio para NetAct vizinho limpeza relação RIU Básica O & M apoio V1

Redirecionar com Round Robin

RIU para 1800/2100

A remoção de PM contadores para PRB uso


Radio Resource Gestão / Telecom O & M

O & M

O & M

O & M

BTS Solution Site

Radio Resource Gestão / Telecom BTS Solution Site

O & M

3.3 restritos recursos liberados

ID

873

CR L0590

Nome do recurso

SRVCC para GSM

Limite máximo TWAMP configurável tamanho do pacote para 1400 bytes

Área Solution

Mobilidade

Restrição

Rádio só recurso. Não testado end-to-end.

Não tem autorização para FSMF

Pronto ID Correção Plano

RL50

3.4 Não Lançado Features

ID

162

Nome do recurso

Rastreamento celular com IMSI

Área Solution

Rede de Monitoramento e Manutenção

Observação

Devido a solicitações de vários clientes o recurso foi desativado por padrão. Os MME existentes da maioria dos vendedores fazer não suportar esta função e tem que lidar com mensagens S1 adicionais, que produz carga desnecessária ao MME. Para fins de teste esse recurso pode ser ativado por um suporte técnico procedimento.

Correção Plano



8 (23)

ID

940

1263

CR L0653

Nome do recurso

SW Verificação Agent

FRGV Flexi RRH 2TX 2100

De compartilhamento de LTE-GSM-RF configuração com RRH1800 FHEA

Área Solution

O & M Segurança

BTS Solution Site

BTS Solution Site

Observação Correção Plano

CARACTERÍSTICAS 4. STATUS LEGACY

4.1 Lançado recursos herdados

ID

1

2

3

4

5

7

9

10

11

13

20

22

27

28

30

31

37

38

39

40

Nome do recurso

Gestão de caminho de dados S1/X2

S1 Flex

S1, X2 e RRC sinalização comum

Multi-Operador de Core Network

Portador Rádio e S1 portador estabelecimento e liberação Suporte de múltiplas EPS portador

Diferenciação de serviço

Portadores de EPS para a voz de conversação

Compressão de cabeçalho robusta

Taxa de nivelamento

Controle de admissão

Atendimento de chamadas de emergência Abrir controle de potência de loop UL e DL ajuste de potência Controle de potência UL circuito fechado

CQI adaptação (DL)

Ligação adaptação pela AMC (UL / DL)

Cifra

Proteção da integridade

Transmissão de informações do Sistema

Canais físicos e de transporte

Área Solution

Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom

Operador Hint



9 (23)

ID

41

42

Nome do recurso

Apoio PDCP, RLC e MAC

DRX em RRC modo conectado

Área Solution

Radio Resource Gestão / Telecom Radio Resource Gestão e Telecom

Operador Hint

Operador dica: Por padrão drxProfile2 é usado para todas QCIs GBR relacionados (QCI1-4). Para todos os QCIs não-relacionados (GBR QCI5-9) por drxProfile3 padrão é usado. O cliente é livre para alterar as configurações (em uma faixa específica) para os drxProfiles relevantes (configurações DRX também estendidos para os não-GBR QCIs). Mas, portanto, ele tem que ter em importa que os serviços devem ser usados com um QCI especial e definir os temporizadores para os drxProfiles relevantes de acordo aos requisitos de tempo estes serviços teve que cumprir.

43

45

49

50

51

53

54

55

Suporte de 64 QAM em DL

Agendador Fair (UL / DL)

Paging

Gerenciamento de estado UE

Seleção celular e re-selecção

Intra e inter entrega eNB com X2

Entrega de Intra-LTE via S1

Transferência Inter-freqüência

Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom

Operador dica para a criação da "lista negra para celular lista intra e inter freq HO ": Os elementos desta lista, composta por PCI e PCI início alcance, devem ser concebidos de forma que o máximo Valor PCI 503 não seja ultrapassada. Caso contrário UEs com chipset mais comuns não são capazes para configurar uma conexão.

56

68

69

70

71

74

75

76

78

79

80

81

82

Inter entrega RAT para WCDMA

Suporte de célula com base serviço de localização

Transmitir diversidade para duas antenas

Downlink adaptativo MIMO malha aberta para duas antenas 2-way RX diversidade (MRC)

Flexi Sistema Módulo FSMD

Até 3 células por Flexi BTS LTE

Flexi BTS legado MHA Suporte

Flexi AC / DC com energia da bateria Módulo Armários Flexi Indoor e Outdoor

Sincronização GPS

Intervalo de células até 13 km

Alta Capacidade Flexi Módulo do Sistema FSME

Radio Resource Gestão e Telecom Radio Resource Gestão e Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

Lançado como característica só de rádio.

GPS comprimento do cabo pode ser no máximo 100m.



10 (23)

ID

85

86

87

89

91

Nome do recurso

Flexi 3-setor Módulo RF 2600


Flexi Módulo RF 3 do setor 850

Flexi RRH 2TX 2600

Flexi RRH 2TX 850

Área Solution

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

Operador Hint

Dicas Operadora: 1. FHCA não suportado para RET / MHA. 2. FHCA 472169A.103 produto (FPGA) deve ser utilizado no máx. 2 * 20W de potência DL. Este firmware só deve ser utilizado nas seguintes condições: modo 20W -40 a 50 graus.

94

96

97

99

101

103

104

106

112

113

114

115

118

119

129

131

132

134

138

140

Feederless site

Configuração MIMO 2TX com 3-setor Módulo de RF Raio da célula max 77 km

Flexi Módulo RF 3-setor 1.7/2.1


FRLB Flexi RRH 2TX 730 (comercial versão) Flexi RRH 2TX 1800

6 apoio celular com um Módulo do Sistema

Largura de banda celular - 20 MHz




Fast Ethernet (FE) / Gigabit Ethernet (GE) interface elétrica Gigabit Ethernet (GE) interface óptica

Priorização de tráfego na camada Ethernet

Priorização de tráfego na camada IP (Diffserv) Diferenciação de tráfego com base VLAN

Cronometragem sobre Packet

Traffic shaping (UL)

OAM Ethernet

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

Transmissão

Transmissão

Transmissão

Transmissão

Transmissão

Transmissão

Transmissão

Transmissão Dicas Operadora: FSME: Geração AIS OAM serviço não é suportado por eNB. FSMF: OAM Ethernet não é suportado.

144 Controle de admissão de Transporte Transmissão



11 (23)

ID

147

150

Nome do recurso

Gestão LTE Hardware

LTE OAM Transport Layer Security Support (TLS)

LTE BTS Site Manager

FILHO LTE BTS Auto Conectividade

Flexi BTS 3rd party Suporte MHA

NTP relógio sincronização de tempo

Tilt Suporte Flexi BTS 3GPP Antena

Única modalidade caminho TX

Liberação conexão RRC com redirecionamento

Correlação de alarme automático de interface

DL poder impulsionar para canais de controle

Interrupção celular Detecção

Flexi 3-setor RF Módulo 800EU

Rede Mudança de Célula Assistida para GSM

MME alteração do valor da capacidade

Flexi RRH 2TX 2100

Gestão PCI

Configurações DRX estendida

Área Solution


O & M Segurança

Operador Hint

Operador Dica: Solução para atualização Trust Anchor ver Técnico Apoio Nota TS-LTE-SW-0001.

153

154

155

158

160

187

423

424

430

432

437

442

450

452

468

473

Administração de Rede


BTS Solution Site

Complementar O & M recursos BTS Solution Site

Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Rede de Monitoramento e Manutenção Radio Resource Gestão e Telecom Rede de Monitoramento e Manutenção BTS Solution Site

Radio Resource Gestão e Telecom Radio Resource Gestão e Telecom BTS Solution Site


Radio Resource Gestão e Telecom

Operador dica: Por padrão drxProfile2 é usado para todas QCIs GBR relacionados (QCI1-4). Para todos os QCIs não-relacionados (GBR QCI5-9) por drxProfile3 padrão é usado. O cliente é livre para alterar as configurações (em uma faixa específica) para os drxProfiles relevantes (configurações DRX também estendidos para os não-GBR QCIs). Mas, portanto, ele tem que ter em importa que os serviços devem ser usados com um QCI especial e definir os temporizadores para os drxProfiles relevantes de acordo aos requisitos de tempo estes serviços teve que cumprir.

Característica conectado a LTE502 Interrupção celular acionado Repor, consulte estado lá.


475

482

490

491

492

502

510

Resiliência automática IOMS

Apoio DNS para exame de certificação

Mobilidade perfil de assinante com

FlexiPacket Rádio Conectividade

ANR

Interrupção celular desencadeada redefinir Sincronização de neigbhors InterRAT

O & M

Complementar O & M recursos Radio Resource Gestão e Telecom Transmissão

O & M

O & M




12 (23)

ID

518

521

522

533

Nome do recurso

Operador QCI específico

Segurança para portas Ethernet FCM/FSM2 S1 restauração parcial

Mobilidade Robustez

Área Solution


O & M Segurança Radio Resource Gestão e Telecom Gerenciamento da Configuração

Operador Hint

539 ANR Central Gerenciamento da Configuração

Operador Dica: No caso de haver um problema com o NE em NetAct e NE tem a ser eliminado em NetAct e integrado novamente, o PM dados Optimizer não pode ser atribuído ao NE porque o ID interno NetAct alterado durante a reintegração. Dica Operador para Optimizer: Tarefas Optimizer iniciado a partir Configurator falhar se SITE sem altitude é atribuído a eNB.

547

559

562

564

Flexi RRH 2TX 800 UE

Módulo de Monitoramento de SW para LTE

CSFB para UTRAN ou GSM via redirecionamento

IPSec em FTIB

BTS Solution Site

Rede de Monitoramento e Manutenção Radio Resource Gestão / Telecom Transmissão

Veja o status de LTE646 SW Extensão Monitoramento com PM Contadores.

Operador Dica: 1 Para FTIB e FTLB:. Durante IKEv2 recodificação eNB não toma novos valores SPI imediatamente em conta, assim SEC-GW pode soltar alguns poucos pacotes.

2. O módulo de transporte eNB não suporta a fragmentação e remontagem de IPSec criptografados IP pacotes. Portanto a) a fragmentação do IPSec pacotes IP criptografados ou tem de ser evitado por usando tamanhos MTU menores nas laterais de pares, ou b) o IPsec GW precisa de fazer a fragmentação em primeiro lugar e, em seguida, a criptografia. Para b) o que normalmente só é possível se o DF Bit (não fragmentar) não está definido pelo ponto. Isto não não devem ser considerados apenas para o utilizador plano (SAE-GW), mas, por exemplo, também para os M-avião (OMS, CA-Server, ..).

570

571

572

574

Medições periódicas UE

Controlado segmentação de pacotes uplink

Sessões de emergência do IMS

Medição Rede de Transporte IP

Radio Resource Gestão e Telecom Radio Resource Gestão e Telecom Radio Resource Gestão e Telecom Transmissão


Operador Dica: FSMF: Transporte de rede IP não Measurement suportada.

581

592

602

614

Gestão PRACH

Ligação de supervisão com BFD

Gestão de Desempenho Administração Site distribuído


Transmissão

Rede de Monitoramento e Manutenção BTS Solution Site

Veja o status de LTE657 LTE Gestão de Desempenho.

Operador Dica: As fibras paralelas ao módulo de rádio deve estar de mesmo cabo. Isto assegura que as duas fibras são mesmo comprimento e o sistema funciona. O sistema agora permite max. 5 metros diferença de comprimento entre as fibras principais e secundárias.

616

619

Uso baseado adaptação PDCCH

Interferência consciente agendamento UL

Radio Resource Gestão e Telecom Radio Resource Gestão e Telecom



13 (23)

ID

630

649

Nome do recurso

Flexi dupla MHA 800

QoS switching Ethernet consciente

Área Solution

BTS Solution Site

Transmissão

Operador Hint

Dicas Operadora: 1) Os contadores de desempenho para o TRS FTLB para 'Descartado recebido pacotes Ethernet devido transbordamento para AF *, BE e EF " em caso de pacotes descartados devido à formação egresso são nomeado enganosa, uma vez que a classe de tráfego, representado por Valor DSCP, tem nenhuma solução relação a fila de prioridade escolhido e leva a má interpretação dos valores apresentados.

2) Em RL20 e RL30, a configuração de uma VLAN-ID com valor zero (0) foi possível, violando os padrões IEEE. Em Caso um operador usado esse valor na rede de transportes projetos, é necessário alterar esta rede configuração padrão para conformar os valores (ou seja, a VLAN ID 1 ... 4094) antes de migrar para LTE RL40. Veja o status de LTE657 LTE Gestão de Desempenho.

651

653

655

657

Monitoramento de desempenho de I

LTE Operacionalidade Arquitetura

Gestão LTE Software

Gestão de Desempenho LTE


Administração de Rede


Rede de Monitoramento e Manutenção

Operador Dicas válido para FSME: 1. No caso de servidor NTP falha e eNB for reinicializado, mas Receptor de GPS está disponível, não há dados de medição PM é produzido como FTM é resetted a 1.1.2004 e não alinhados com FSM já que tem data e hora ainda correto. Nenhum alarme é gerado, todas as marcas de tempo para alarmes e notificações são feitas por FSM e estão corretos, pois o usuário não consegue detectar qualquer problema. 2. Além disso, deve ser assegurado que o servidor NTP oferece ao mesmo tempo a FTM como o receptor GPS EFM, de modo que ambas as unidades realmente funcionar com o mesmo tempo. Caso contrário, medidas de desempenho pode ser perturbado como o tempo de início e fim da medição intervalos é diferente para BTS PM (FSM) e TRS PM (FTM). Intervalos de medição TRS PM são, então, deslocou para que eles se encaixam no correspondente BTS PM intervalos de medição. Este efeito não pode ser detectada pelo utilizador.

Operador Dica válida para FSME e FSMF: 3. Contadores M8001C149, M8001C150, M8001C151 são não relatar corretamente. 4. Contadores M8016C27, M8016C28, M8019C1 e M8019C2 não estão informando corretamente.

663

664

666

667

679

681

689

Localização GPS e tempo de recuperação

Pilha de protocolos de transporte LTE

LTE Gestão de Conta de Usuário

LTE Usuário Event Log Gestão

LTE local Gerenciamento de Conta de Usuário

Windows 7 Suporte para Elemento Software Client Manager Suporte LTE IPsec

Complementar O & M recursos Transmissão

O & M Segurança

O & M

O & M Segurança

O & M

Transmissão Dicas Operadora: 1. Em caso de aplicação de endereço e endereço de interface são os mesmos (local_ip), o teste de conectividade ignorando o túnel IPSec com seguinte combinação de

Solução para atualização Trust Anchor ver Técnico Apoio Nota TS-LTE-SW-0001.



14 (23)


regra de bypass / proteger não funciona: desvio localIpAddress local_ip remoteIpAddress Qualquer proteger = localIpAddress Qualquer remoteIpAddress Any.

2 Para FTIB e FTLB:. Durante IKEv2 recodificação eNB não toma novos valores SPI imediatamente em conta, assim SEC-GW pode soltar alguns poucos pacotes.

3. O módulo de transporte eNB não suporta a fragmentação e remontagem de IPSec criptografados IP pacotes. Portanto a) a fragmentação do IPSec pacotes IP criptografados ou tem de ser evitado por usando tamanhos MTU menores nas laterais de pares, ou b) o IPsec GW precisa de fazer a fragmentação em primeiro lugar e, em seguida, a criptografia. Para b) o que normalmente só é possível se o DF Bit (não fragmentar) não está definido pelo ponto. Isto não não devem ser considerados apenas para o utilizador plano (SAE-GW), mas por exemplo também para os M-avião (OMS, CA-Server, ..).

692

703

707

710

711

713

720

Suporte LTE Firewall

Adaptativo DL fechado MIMO laço para dois antenas Flexi Transporte sub-módulo FTIB

A sincronização de interface de PDH

A sincronização de sinal 2.048MHz

Synchronous Ethernet

FILHO LTE BTS Auto Configuration

O & M Segurança

Radio Resource Gestão / Telecom Transmissão

Transmissão

Transmissão

Transmissão

Gerenciamento da Configuração Operador Dica: CEI de WCDMA-FSME com fábrica SW WN6.0MP4.07 viola a BTS O & M interface de especificação e não recebe responder da OMS. Ao iniciar auto-conexão de WCDMA BTSID não deve ser maior do que 65535. Resolvido em WN7.0 1,0 P8 (LE para a nova fábrica SW Q3/2013).

724

735

746

747

749

761

Vizinho celular LTE automática Configuração RRC Conexão restabelecimento

Filtragem baseada em IP de Apoio BTS site Equipamento Apoio às capacidades de rádio UE

Ligação adaptação para PDCCH

Seleção de célula-alvo Avançado e nova tentativa de entrega para a freqüência intra entrega Mobilidade modo de Espera de LTE para WCDMA, GSM ou outras bandas LTE Suporte de aperiódico CQI relata

Coleção contador de desempenho básico II Otimização da Intra-LTE vizinho relações


Radio Resource Gestão e Telecom O & M Segurança

Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom

Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom Monitoramento de desempenho


762

767

770

771


Operador Dica: No caso de haver um problema com o NE em NetAct e NE tem a ser eliminado em NetAct e integrado novamente, o PM dados Optimizer não pode ser atribuído ao NE porque o ID interno NetAct alterado durante a reintegração.



15 (23)

ID

775

783

784

788

793

796

797

798

800

805

806

807

810

819

829

830

866

870

875

899

900

901

902

903

904

905

913

914

Nome do recurso

SCTP multi-homing (MME)

ANR InterRAT UTRAN

ANR InterRAT GERAN

Suporte de 16 QAM (UL)

Suporte de 16 QAM (DL)

aumento conectividade IOMS

PM Contra Entrega I

PM Contador histogramas I

Flexi Transporte sub-módulo FTLB

PM Contador Capacidade I

PM Contador de Transporte I

Ocioso modo mobilidade LTE para CDMA/1xRTT Flexi dupla MHA 2600

Geração de interferência entre as células DL

O aumento da faixa de uplink MCS

LTE Bloqueio Automático

Rápido IP Rerouting

Mobilidade modo de Espera de LTE para CDMA / eHRPD Endereços IP diferentes para U/C/M/S- avião Antena de supervisão de linha

Power Support Flexi BTS LTE 40W

Suporte Flexi BTS LTE 8W de potência

Suporte Flexi BTS AISG MHA

Power Support Flexi BTS LTE 60W

Flexi BTS LTE Filial Ativação

Não GBR QCI 5, 6, 7, 8 e 9

LTE compatível com NEBS OMS

Célula Graciosa desligado

Área Solution

Transmissão



Radio Resource Gestão / Telecom Radio Resource Gestão / Telecom O & M



Transmissão



Radio Resource Gestão e Telecom BTS Solution Site

Radio Resource Gestão / Telecom Radio Resource Gestão e Telecom O & M

Transmissão

Radio Resource Gestão / Telecom Transmissão

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

BTS Solution Site

Radio Resource Gestão / Telecom Complementar O & M recursos Radio Resource Gestão / Telecom

Operador Hint






Operador Dica: Celular Graciosa Desligar obras apenas para UEs em Conectado Mode.



16 (23)

ID

921

931

971

977

1034

1035

1106

1195

Nome do recurso

Flexi Módulo RF 3 do setor 760

Jumbo Frames Ethernet

Intra-LTE offsets de mobilidade

Encadeamento de RF

Prolongado Uplink Ligação Adaptação

Outer adaptação ligação de loop para PDCCH

Flexi baixa potência RRH 850 2TX para interface de repetidor ótico FHCC Flexi interface 850 Repetidor Unit (RIU)

Área Solution

BTS Solution Site

Transmissão

Radio Resource Gestão e Telecom BTS Solution Site

Radio Resource Gestão e Telecom Radio Resource Gestão e Telecom BTS Solution Site

BTS Solution Site

Operador Hint

4.2 restritos recursos herdados Lançado

ID

163

Nome do recurso

Assinante e Equipamentos Traço

Área Solution

O & M

Restrição

Funcionalidade principal trabalhando ao lado abaixo restrições: 1. TraceFailure não é exibido no Trace Viewer 2. Causa da falha não é exibido no caso de erro de ativação 3. Dados de rastreio do Assinante é perdido durante NWI3 ligação interrupção e não mostrado em TraceViewer.

Operador Dica: Não X2 mensagens de handover são rastreada se NSN MME está ligado a eNB. FSMF: Com FSMF, em vez do sistema é SIB8 não transmitiu o tempo suficiente depois GPS está desligado porque resquício dura apenas 5 horas 40 minutos em vez de exigido 8 horas.

Operador Dica: GPS comprimento do cabo pode ser o máximo 100m. Recurso substituído por LTE644 Conteúdo traço celular configurável. Estado vê lá. Para apoiou a partilha de RF configurações, consulte "Flexi Multiradio BTS Sharing RF Configurações suportadas ", DN09123381, última edição em NOLS.

RF-Sharing com FSMF com 15 MHz largura de banda não é suportado.

Restrições: 1. Alarmes são levantadas por GSM para o módulo RF compartilhado sem adicional info "compartilhada". 2. Na parâmetro NetAct FTM


Veja NetAct Plano de Correção

426 Transmissão em tempo Sistema de SIB8


433 Rastreamento celular O & M

447 Apoio SW para compartilhamento RF GSM-LTE

BTS site Solução

1. 96841ESPE02 2. 119650ESPE02 3. 68724ESPE03 4. 70097ESPE03 5. 100308ESPE04

RL50



17 (23)

ID Nome do recurso Área Solution Restrição

enableRP301Interface recebe padrão valor atribuído pelo modelo de sistema mesmo para FSME. 3. Desbloquear de FXEB não é possível, reposição do site é necessária. Solução: FSMF deve ser conectado ao optIF1 de RFMS e ESMB deve ser ligado a optIF2 de RFMS (não vice-versa). 4 FSMF:. Esporadicamente após reposição do site Células LTE estão desativados. eNB executa BTS redefinição autônoma como a recuperação ação em caso de 40W por célula LTE. 5. Falha 4039 (link RP3 conflito) não é apuradas em LTE se o problema está resolvido. 6. Depois RM trocar o número de série não é atualizada no 'Backup comissionamento de arquivo. 7. RF-Sharing com GSM não suporte para configuração de A-tipo.

Dicas Operadora: 1. Diferente para BTSSM, NetAct faz não impede o operador altere o número de série do mestre tecnologia (LTE) com um plano de CM baixar operação. Quando a ativação será executado, a eNB reinicia e define seu número de série automaticamente volta para o original valor como o número de série é autodetectada durante a inicialização eNB. 2. HW redefinir para o módulo RF compartilhado possível de GSM gerente elemento mestre LTE perturbador. 3. GSM Element Manager não aceitar configuração ethernet de LTE. Mensagem de aviso pode ser ignorado. Restrição: Subseqüente avanço de timing comandos com o mesmo valor. Veja o status de LTE654 LTE Gerenciamento da Configuração.

Restrição: 1. Em caso de traço célula traçado desligada dados durante a interrupção NWI3 obter perdida.

Restrição em TraceViewer: 2. Em caso de interface do traço esporadicamente TraceViewer mostra chamadas com CallStartTime que é mais tarde do que Não CallEndTime e chamada não contêm quaisquer mensagens rastreadas.

Operador dica: Traço de pilha para a mudança IOMS por exemplo desencadeado por característica resiliência IOMS não é suportado. Solução: IOMS mudar necessidades eNB repor no caso de um rastreamento estiver ativo antes. Restrição: O consumo de memória de BTSOM aumenta.


459 LTE Cronometragem Adiantamento Avaliação Parâmetro Radio online mutável

Traço celular configurável conteúdo

550

644

Rede Monitoramento e Manutenção O & M

Rede Monitoramento e Manutenção

101340ESPE04 RL50

1. Veja NetAct Plano de Correção

654 Configuração LTE Gestão

Configuração Gestão



18 (23)

Dicas Operadora: 1. Um erro de validação durante o plano de CM provisionamento de trabalho a partir de NetAct poderia ser causada por uma inconsistência na NetAct configuração. Neste caso, executar um plano de CM fazer upload para o BTS afetadas e repetir o trabalho de provisionamento plano CM. 2. Seguintes caracteres não são suportado por BTSSM: <> '"& 3. UnitNumber para FSMF deve ser especificado quando clockProtocol = clkToP Restrição NetAct Monitor: 1. Alarmes duplas após o upload de alarme.

Restrição FSMF: 2. LMT Quando está ligado ao local Porto de Manutenção (LMP), alarme alterações do estado de backup de bateria Unidade alarma FaultID_1412 Mains corte de energia e FaultID_1413 Falha no módulo de potência. Solução para atualização Trust Anchor consulte Suporte Nota Técnica TS-LTE- SW-0001.

Restrições: 1. Ocasionalmente eNB deixa de verificar a certificado OMS revogada contra o CRL e estabelece uma TLS segura conexão, quando o seu próprio BTS certificado também está presente no LCR. A função de suporte é CRL não confiável neste cenário (BTS possuir certificado revogado). 2. Seqüência 'Key update' trabalha com Servidor CMP compatível 3GPP, 'init' seqüência não é suportado.

Operador Dica: Para FSMF até módulo A.101, operador registro de certificado contra whitelist (Lista de FSMF módulo do sistema de série números) não é suportado, pois Número de série FCT é usado como Nome Assunto no fornecedor certificado. Veja o status de LTE665 Certificado LTE Management.


656 LTE Gerenciamento de Falhas Rede Monitoramento e Manutenção

2. 118572ESPE02

665 LTE Certificado Gestão

O & M Segurança 1. 90386ESPE01 RL50

685

782

Infra-estruturas para Autoridade de Certificação (CA) e Autoridade de Registro (AR) ANR totalmente baseado UE

O & M Segurança

Configuração Gestão

Restrição: Quando o provisionamento planos que incluir LNADJ / LNADJL / LNREL objectos, recomenda-se a interruptor ANR fora de ambas as funcionalidades com Extensão OAM '(LTE492) e "UE- ANR baseado '(LTE782), a fim de evitar possíveis colisões entre o vizinho objetos automaticamente criado via C-Plane por ANR ea os fornecidos via M-Plane de NetAct.

Dicas Operadora: 1. ANR baseado totalmente UE não é trabalhando em caso UE torna os dados

118708ESPE02



19 (23)


transferência (por exemplo, ping) eo pró-ativa recurso de agendamento (LTE815) é activadas com periodicidade predefinida de 1,5 s (parâmetro celular ilReactimerUl = 1500 ms), porque UE não vai no modo Sleep DRX e, portanto, não é capaz de descodificar o CGI de uma célula vizinha desconhecida.

2. Recomenda-se, a fim de reduzir o número de automaticamente LNREL objectos criados, por exemplo, para investigar um valor optimizado da Parâmetro LNCEL anrThresNbCell em um representante do eNB implantação urbana e para o qual o todo PLMN é X2 na lista negra, assim que apenas o melhores vizinhos ENB são obtidos sem instalação X2 (células vizinhas relatadas com poder seguir anrThresNbCell limite não são resolvidos por ANR). Começando por exemplo a partir de um valor de 90 (Correspondendo a -50 dBm e maior do que o valor atual padrão 40 corresponde a -100 dBm), o parâmetro anrThresNbCell poderia ser baixou gradualmente em 5 dB por hora, e depois de cada passo pode ser verificado quantos são LNRELs adicionado. Até cerca de 20 por LNRELs celular parece ser um realista número.


4.3 Não Lançado recursos herdados

n / D

CORREÇÕES 5. 3 ª parte

n / D

6. Partos anteriores para a liberação

Entrega de atualização SW LN4.0

Tipo de entrega Lançamento

data de entrega 2013/12/02



20 (23)

OBJETOS 7. LIBERADAS

Lista de arquivos 7.1 Software eNB

Software item eNB

BTS Site Manager

Ouro SCF

Nome do Software Arquivo LN4.0_ENB_1202_780_10_release_BTSSM_do wnloadable.zip BTS_Site_Manager_LN4.0_BTSSM_1202_765_ 00.zip Golden_SCF-FB1202_6xy_P8 em diante-update- - 2013-02-26.zip

Soma de verificação SHA1 C27464AF62ACA4323BD8C27A71235CDAB DAF3F42 AD6220CF7B317550688E0B761BA7D236430 96FF5 6E4DEA86562D25DA3489D4CC5BC0B3A93 E9892ED

Conteúdo da Embalagem BTS_Site_Manager_LN4.0_BTSSM_1202_765_00.zip

BTSSiteEM-LTE40-1202_765_00.bin

BTSSiteEM-LTE40-1202_765_00.exe

BTSSiteEM-LTE40-1202_765_00_x64.bin

BTSSMReleaseNote.html

BTSSMReleaseNote.xml

SiteEM_LTE.xml

Conteúdo da Embalagem Golden_SCF-FB1202_6xy_P8 em diante-update --- 2013-02-26.zip comparar-GMC - LN4.0-FB1202_6xy_P8_onwards-2013-02-14 - a --- LN4.0-FB1202_6xy_P8 --- 2013-01-28 - 10Mhz.zip comparar-GMC - LN4.0-FB1202_6xy_P8_onwards-2013-02-14 - a --- LN4.0-FB1202_6xy_P8 --- 2013-01-28 - 20Mhz.zip comparar-GMC - LN4.0-FB1202_6xy_P8_onwards-2013-02-26 - a --- LN4.0-FB1202_6xy_P8_onwards-2013-02-14-- 10Mhz.zip comparar-GMC - LN4.0-FB1202_6xy_P8_onwards-2013-02-26 - a --- LN4.0-FB1202_6xy_P8_onwards-2013-02-14-- 20Mhz.zip

Golden_SCF-FB1202_6xy_P8 diante --- 2013-02-26.xml

Golden_SCF-FB1202_6xy_P8 diante --- 2013-02-26.xmlexample05MHz.xml.sorted.xml




8. ANEXOS / REFERÊNCIA

O software para os produtos lançados está disponível em NOLS.

O software recém-lançado pode ser baixado a partir dos links diretos:

• Flexi Multiradio BTS LTE:

https://online.portal.nokiasiemensnetworks.com/SWD/?access_key=OTYzNTM% 3D



21 (23)

Depois de baixar o software é importante para gerar soma SH1 para arquivos e comparar com o previsto no Resumo das correções e aprimoramentos documento, essa vontade garantir que os arquivos não foram corrompidos durante a transferência.



22 (23)

Renúncia

As informações contidas neste documento estão sujeitas a alterações sem aviso prévio e descreve apenas o produto definido na introdução desta documentação. Esta documentação é destinado ao uso de clientes da Nokia Siemens Networks para os fins de o acordo sob o qual o documento é enviado, e nenhuma parte dela pode ser usado, reproduzidos, modificados ou transmitida por qualquer forma ou meio, sem a prévia e por escrito permissão da Nokia Siemens Networks. A documentação foi preparado para ser usado por profissionais e pessoal devidamente treinado, eo cliente assume total responsabilidade ao usá-lo. Nokia Siemens Networks recebe comentários de clientes como parte do processo de desenvolvimento e melhoria contínua da documentação.

As informações ou declarações dadas nesta documentação relativa à adequação, capacidade ou desempenho dos produtos de hardware ou software mencionado são dadas "Como é" e qualquer responsabilidade decorrente em conexão com tal hardware ou produtos de software será definida de forma conclusiva e, finalmente, em um acordo separado entre a Nokia Siemens Networks eo cliente. No entanto, a Nokia Siemens Networks fez todos os esforços razoáveis para assegurar que as instruções contidas no documento são adequada e livre de erros materiais e omissões. Nokia Siemens Networks vai, se considerado necessário pela Nokia Siemens Networks, explicar as questões que não podem ser abrangido pelo documento.

Nokia Siemens Networks vai corrigir erros nesta documentação o mais rápido possível. EM HIPÓTESE ALGUMA A Nokia Siemens Networks SERÁ RESPONSÁVEL POR ERROS ESTA DOCUMENTAÇÃO OU POR QUAISQUER DANOS, INCLUINDO, SEM LIMITAÇÃO PARA ESPECIAIS, DIRETA, INDIRETA, INCIDENTAL OU CONSEQUENTE OU QUALQUER PERDAS, COMO MAS NÃO LIMITADO A PERDA DE LUCROS, RECEITAS, INTERRUPÇÃO DE NEGÓCIOS, OPORTUNIDADE DE NEGÓCIO OU DE DADOS, que podem Advir da utilização deste documento ou informações nele contidas.

Esta documentação eo produto que ele descreve são considerados protegidos pelo direitos autorais e outros direitos de propriedade intelectual de acordo com as leis aplicáveis.

O logotipo da onda é uma marca registrada da Nokia Siemens Networks Oy. Nokia é uma marca registrada marca registrada da Nokia Corporation. A Siemens é uma marca registrada da Siemens AG. Outros nomes de produtos mencionados neste documento podem ser marcas comerciais de seus respectivos proprietários e são mencionados apenas para fins de identificação. Copyright © Nokia Siemens Networks 2013. Todos os direitos reservados.



23 (23)

Mudança Nota Formas


LTE_RL40_1.0

RL40 1,0

Estações Base


LN4.0 1.0

Data de Aprovação: 31-May-2013

LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0 Página 1

CN-id: CN5391

Título: Recuperação para sincronismo Corrupted Air Depois de perder OBSAI Mensagens

Versão do SW-build: LN4.0_ENB_1202_780_10

Válido para Produto (s): Flexi Base Station LTE

Referências:

Razão para a mudança Nota:

Em MAIA e MERA FRM HW (FRM Rel. 2.2 e FRM Rel. 2.3) RFSW baseado vai implementar um mecanismo de auto-recuperação para sincronismo Corrupted Air Depois de perder OBSAI Mensagens. Isso deve reduzir o risco de problemas de tempo DL (visíveis como alarmes de alta ATA, DL aleatória sincronismo e anexar falhas), causada por degradação ocasional qualidade do link óptico. Este mecanismo de auto recuperação faz com que uma pequena pausa na transmissão DL (normalmente menos de 10 ms). Esta ação de recuperação já é usado para alarme 1955 (aumento da BER detectado no a conexão óptica para Radio Module), que é desencadeada por alta contagem de LCV. Consulte LBT1534 "Melhoria na recuperação módulo RF autônoma em caso de erros graves na ligação RP3 (CRL0686 extensão) ". Infelizmente contagem LCV não é uma qualidade do link óptico confiável Indicador de algumas configurações (por exemplo, quando LCV são convertidos em código K30.7). O mudar aqui é outro gatilho para o mesmo processo de recuperação.

Relatórios anomalia corrigida: N / D

Componentes de modificação: N / D

Efeitos da mudança:

Efeitos sobre o usuário final N / D

Efeitos sobre Operador N / D

Outros efeitos N / D

Nova funcionalidade N / D

Impacto para o Cliente N / D

Page 2

LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0

CN-id: CRL0767


Título: Mirroring Integrado de tráfego para FSMr3



Referências:

Razão para a mudança Nota: Resumo: Implementar uma funcionalidade em FSMr3 para fornecer uma possibilidade de local capturar o tráfego IP sem interromper o serviço em andamento: •Para capturar e analisar C-avião, M-plano (no caso de não TLS criptografados), S-avião ou tráfego IPSec / IKE. •U-plane espelhamento de tráfego é excluído para reduzir a carga de tráfego para BTS Fast Ethernet LMP. •Sem interrupção, configurável pelo usuário on-the-fly, sem necessidade de reiniciar ou desligar •Ingresso e egresso espelhamento de tráfego na Camada 3. •No caso de IPsec é ativado, o tráfego é gravada sem criptografia, ou seja, depois de decodificação em direção a entrada resp. antes de criptografia em direção egresso. •No caso de IPsec é habilitado, o tráfego IKE é gravado. Tráfego IKE é sempre criptografado logo após IKE início da negociação. •No caso de tráfego IPsec não está habilitado é espelhado no mesmo ponto que com habilitado IPSec. •Se M-avião é criptografada com TLS, TLS tem de ser desativado para que a captura de M- tráfego avião pode ser analisado. Caso contrário, o tráfego M-avião ainda é capturado, mas é, em seguida, encriptada e, portanto, não pode ser analisada •Segurança para porta Ethernet (LTE593): necessidade de ser desativado em primeiro lugar porque o tráfego é espelhado a um porto local. •Permite o armazenamento direto de fluxo de dados (com posterior análise), através de BTS LMP em PC conectado localmente, com dispositivo de armazenamento •Equivalente a traço ETP em FSMr2 WCDMA e LTE

• Implementação do Lean: otimizada de conteúdo, apenas como ferramenta de R & D, com base CLI





Página 4


Efeitos sobre Operador Redirecionar com Round Robin, em caso de CSFB foi implementado




LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL

CN-id: CRL0822

Page 5 APROVADO 2.0

Título: Atribuição flexível de links X2



Referências:


Este CR está solicitando mudanças seguintes no que diz respeito ao manuseio relação vizinho: • Tenha em RL40 o montante global máximo de 64 LNADJ (consistindo de eNB controlado e OAM controlado LNADJ) • Permitir uma atribuição flexível da LNADJ 64 a eNB controlada e OAM controlado • Aumentar os objetos máximo permitido de LNADJ eNB controlada a 64 (= 64 SCTP associação) • Aumente a quantidade máxima permitida de oamControlled LNADJ a 64 • Para evitar o impacto mais amplo: Sem alterações a serem considerados para características centrais ANR em NetAct • Nenhuma alteração para a quantidade máxima de LNADJL com este CR

Consequências quando alterações solicitadas acima são feitas: - ANR LTE782 pode atribuir até 64 ligações X2 - Operador não precisa se preocupar com re-atribuição de links X2 aprendeu a OAM controlada a um manter a ligação X2 trabalhando - Comportamento de inicialização eNB permanece a mesma de antes (quando LTE782 ou LTE492 ligado on): eNB controlado e controlado OAM são configurados quando eNB reinicia.

Raciocinando por isso que é feito para ser capaz de ser feito em RL40: - Atualmente todos os testes de desempenho RL40 já estavam considerando o máximo quantidade de 64 LNADJ - O impacto de ser flexível na atribuição de objetos como OAM controlada ou eNB controlada não está impactando OAM. - A atribuição de mais ENB controlada ligações X2 tem que ser considerada em C-plano.

Fundo Desde RL30 LTE782 seguintes números foram suportados: max 32 ligações X2 e 32 do tipo oamControlled LNADJ e até 64 LNADJ

Relatórios anomalia corrigida: Nenhum. Esta é uma nova funcionalidade.










CN-id: CN5394

Página 7 APROVADO 2.0

Título: Atribuição de certificados de fornecedor em fase de testes bordo e fase de testes do módulo para FSMr3



Referências:


Com a implementação atual uma placa FCT recebe um certificado NSN Fábrica CA assinado em a fase de testes bordo. Este CA NSN fábrica certificado assinado é usado mais tarde como vendedor certificado. Desde que foi criado já em fase de testes a bordo do certificado inclui o número de série do FCTx e não o número de série do HW RELEASE3 SM: FSMF, FSMG / L. À medida que a geração do número de lista branca, que é entregue ao cliente NSN só pode ser feito com HW RELEASE3 SM: FSMF, números de série FSMG / L um certificado adicional em que o módulo é necessário fase de testes. Para Operações atualmente não é possível escrever os números de série FCTx ao entregues lista branca. As placas FCTx entregues após esta CN ainda tem uma CA Fábrica assinado certificado após a fase de testes do módulo para que módulos antigos ainda podem autenticar Placas FCTx. Não existem problemas de compatibilidade.









Page 8


CN-id: CN5408

LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0 Page 9

Título: Reno RRH Antena Trocar para LTE, WCDMA e GSM



Referências:


SITUAÇÃO ACTUAL Do atual HW exigência baseada implementação, SW restringe apoio AISG / MHA em anyother antena diferente ANT2. FHEB / FHDB tentou detectar automaticamente os dispositivos de ALD ANT2

Alteração solicitada As restrições SW precisa ser mudado a partir de ANT2 volta para ANT1 ie Asig / MHA apoio em RENO RRH será em ANT1 apenas e não deve ser apoiado em qualquer outro Antena.

RAZÃO DA MUDANÇA Variante Reno RRH WMV foi atualizado no HW arquitetura especificação para corrigir o diagrama de blocos (HW mudança arquitetura de ANT2 ao uso ANT1). Isto é necessário para ser alterado para uma volta rápida em torno da entrega desta funcionalidade que anteriormente o Projeto HW declarou de forma diferente.

Relatórios anomalia corrigida: Nenhum.









CN-id: CN5551 LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0 Página 11

Título: AWS 4X4 RRH HW atualização diferença para ver1.3



Referências:


AWS 4X4 RRH HW atualização diferença para ver1.3 O configure MERA SERDES interface configuração foi alterado que leva a MERA relógio de referência de entrada é atribuído a interna.

Este é melhorar RP3 questão erro LCV.

Relatórios anomalia corrigida: Nenhum.








CN-id: CRL0823


Título: Supervisão Memória



Referências:


Este CR está solicitando ações preventivas mínimas na eNB SW para evitar eNB cai devido a alto uso da memória.

Seguintes ações são planejadas para ser incluído: -Supervisionar em eNB quanto margem de memória é deixada -Elevar um alarme com indicação de que o uso total de memória é muito alta -O valor limite para elevar o alarme deve ser reutilizado a partir de um interno existente Culpa BTS -O alarme deve ser limpo novamente quando o uso de memória está acontecendo abaixo da valor limiar

- Possíveis ações "reparação", que pode ser feito pelo operador e que serão indicado para operador com alarme: reduzir a configuração, desativar recursos ANR, fazer um reset de eNB, .. outra ação para descrever a cliente








Página 13



CN-id: CRL0841


Título: Prolongado comprimento mensagem BTS-OM Interface para CCN



Referências:

Razão para a mudança Nota: Resumo: Para reduzir o tempo de transmissão quando o tamanho da mensagem é muito grande, o limite de divisão CCN mensagem é alterada de 64KB a 256KB (60KB para segurança e 250KB em uso). Para ter mais informações no cabeçalho da mensagem de ASN.1, o cabeçalho estendido é definido. Atualmente, o cabeçalho estendido é utilizado quando o tamanho da carga é maior do que 64KB. O cabeçalho original e formato de cabeçalho estendido é como abaixo. Estrutura Legado:

offset (octeto)

campo

0

messageType

1 2 3 ... 3 + messageLength

messageLength BER mensagem codificada

Estrutura estendida:

offset (octeto)

campo

0

0xFF

1

VersionMajor

2

VersionMin ou

3 4 5 6 7 8 9 10 11

reservado messageType messageLength

12 ... 12 + messageLength

BER mensagem codificada





Efeitos sobre o usuário final

Page 15 APROVADO 2.0

N / D





CN-id: CRL0896


Título: Permitir LTE979 IRC também sem sincronia GPS



Referências:

Razão para a mudança Nota: Resumo: Atualmente uma verificação de consistência permite LTE979 apenas quando o GPS está disponível para synchronizat esquema de íons. A verificação de consistência é removido para permitir LTE979 também com outro sincronizador esquemas nização, tais como Top (Timing over Packet) com sincronização de freqüência. O Flexi Multiradio BTS suporta um receptor MMSE-IRC por 2 caminhos RX por célula. A operação sincronizada da rede é recomendado para explorar o ganho total de IRC. A funcionalidade de IRC pode ser ativado / desativado por célula por configurações de O & M.


.









CN-id: LBT1758

Título: Suporte para colocação manual dos FLDA dupla MHA dual band EU800/900



Referências:

Razão para a mudança Nota: Resumo: Implementar um novo modelo de MHA (fornecedor Mobi), que é apoiado pela OAM. O eNB OAM aceitar este modelo FLDA dupla MHA (determinado código do produto) para ser encomendado e ganho de MHA para ser levado em uso. Definições de falha estão alinhados com os critérios de aceitação para os recursos especificados no HW WBTS_HWMGT_17981 como se segue:

• • •

RETs são sempre aceitos sem validação (eles nunca estão listados na BPF) MHAS são aceitas com ou sem validação de acordo com a sua presença em BPF Tratamento de outros recursos de HW não muda





Efeitos sobre Operador FLDA MHA é detectado e comissionados para BTS corretamente





CN-id: LN40_00012

Título: FSMr3 última FHCC (1.6.1) e / ou juntamente FXEB (1.6.2) não detectado



Referências:

Razão para a mudança Nota: Resumo do problema original:

Após a sincronização na principal RP3-01 link é perdido a sincronização no secundário Ligação RP3-01 não pode ser estabelecida. Isso afeta o encadeamento de configuração.

Como usuário final / operador podia detectar o problema:

A comunicação com outras unidades RFM em seguida, o primeiro da cadeia está perdido e não pode ser estabelecida. A culpa só poderia acontecer em uma fase inicial de arranque RFM enquanto não há transmissão de rádio e antes de Ethernet está configurado.

Descrição da falha:

A falha pode ocorrer quando a sincronização na principal RP3-01 link na RFM foi perdido antes Ethernet foi configurada. Em tal caso RFM não for reiniciado mas ressincronização é realizada. No entanto, mesmo se a sincronização no link primário foi estabelecido que não pode ser estabelecido com ligações secundárias (devido a ações de software em falta). Só reinício do primeiro RFM em cadeia poderia se recuperar, então a configuração do encadeamento de todo. Solução: Bloqueio / Desbloqueio de FHCC

Impacto de Operador: FSMF última FHCC e / ou FXEB acoplada não detectado.

Restart da primeira unidade RFM em cadeia.

Descrição da correção (análise de risco incluído): Foram adicionadas as ações de software desaparecidas. Eles estão fazendo com que a sincronização em ligações secundárias serão estabelecidos após a sincronização no link principal for alcançado.

Restrições: Em caso de configurações usando módulo FSMF SM FTIF FEI 1 ou 3 deve não ser usado para a interface S1. Em vez FTIP FEI 2 ou 4 deve ser utilizada para a interface S1

Impacto de Operador: FSMF última FHCC e / ou FXEB acoplada não detectado.


Relatórios anomalia corrigida:


39845ESPE05 FSMr3 última FHCC (1.6.1) e / ou juntamente FXEB (1.6.2) não detectado

Componentes de modificação:

Componente RIM23.02.R01

Versão * elemento Net RIM23.02.R - 01

* SW-type -

* Unidade -






Impacto para o Cliente Operação e Manutenção

Testando Instruções para a mudança

Pré-requisitos: - Mudança de ligação S1 FTIF EIF1 -> FTIF eIF2

A execução do teste: - Redefinição de site com S1 em FTIF EIF1 De mudança de ligação de S1 FTIF EIF1 -> FTIF eIF2 e reconfigure S! e fonte SyncE em TRS - Fazer 9 sites de reset

Resultados esperados: Após cada repor todas as FR detectado também 1.6.1 e 1.6.2 e as células vai ao ar

Resultados inesperados: 1.6.1 (FHCC) detectado; 1.6.2 (FXEB) não detectado


CN-id: LN40_00013

Título: Falha na relação RP3 óptico Alarme ocorreu devido a KEEPALIVE expirou.



Referências:

Razão para a mudança Nota: Resumo do problema original: Durante a operação normal do FHCA será reiniciado automaticamente devido a um interno Tempo limite KEEPALIVE.

Como usuário final / operador podia detectar o problema: Falhas RP3 seria observado enquanto FHCA estava para baixo.

Descrição da falha: O FHCA tem duas CPUs que executam um protocolo KEEPALIVE interna entre eles. A CPU OBSAI NIOS foi parado fazendo com que o CPU ARM ter KEEPALIVE interno tempo de espera e, em seguida, ARM CPU faria um reset do FHCA.

Relacionadas característica / funcionalidade: Nenhum

Dependência de configuração: Nenhum

Solução: Não há solução é possível.

Descrição da correção (análise de risco incluído): O erro é encontrado para ser causado pelo controlador de memória DDR2. Este controlador pode parar devido a comando incompleto ou DDR2 PLL não responder a ajustes de fase. Se o controlador de memória DDR2 pára, ele irá parar o processador NIOS OBSAI e causar interno KEEPALIVE repor. Esse problema pode ocorrer quando se utiliza ferramentas Altera 10.1. A solução é atualizar com as últimas ferramentas Altera 12.0SP2. O risco de mudança de ferramentas versão é sempre elevado, e é por extenso teste está sendo executado a MTI em DK e no NSN em Oulu e Coréia.

Efeitos sobre o usuário final: FHCA seria baixo para o tempo que leva o FHCA repor.




NA05320886 Falha na relação RP3 óptico Alarme ocorreu devido a KEEPALIVE expirou.


Componente FRRH4-SW. -







Versão 0407706

* Elemento líquida -

* SW-type -

* Unidade -


Pré-requisitos: FHCA está em OnAir

A execução do teste: Deixar FHCA após o arranque de um longo período de tempo. Garantir que não haja auto-resets ocorrer

Resultados esperados: FHCA continua a funcionar correctamente sem qualquer alarme RP3

Resultados inesperados: FHCA tem keepalive auto-reset e RP3 alarme


CN-id: LN40_00020


Título: RL30 MP3.1.4 Daegu] RACH SSR KPI é "0" após a atualização MP3.1.4 SW



Referências:

Razão para a mudança Nota: Resumo do problema original: BBC definir valor de correção delta como 0

Como usuário final / operador podia detectar o problema: SW atualizar MP3.1.3 para MP3.1.4

Descrição da falha: RACH SSR KPI é "0"

Relacionadas característica / funcionalidade: Não

Dependência de configuração: Não

Solução: Não

Descrição da correção (análise de risco incluído): Mude um código para fazer um valor de correção delta poderia ser direito inicializado. No código BBC, FR1_1_1 e FR1_1_2 vai usar a mesma variável como X para delta correção antes do início correção delta, BBC pediria RF para ele.

Valor pi atual e armazenar valor get a X, a corrente agora, quando fazer a correção delta para FR1_1_2, BBC obter o valor do pi fr1_1_2 's, mas não há erro de código em que lugar.

Porque o valor de pi obtido não salvar a X.. Poderia ser simplesmente como um resumo initialize variável errado.

Efeitos sobre o usuário final: Não

Efeitos sobre a operadora: Não

Efeitos do sistema: Não


Componente defeituoso e versão:

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): FB1103_LN3.0_3.1.5

Relatórios anomalia corrigida: NA05347970 RL30 MP3.1.4 Daegu] RACH SSR KPI é


Componente BBC_pkg.sbs






Impacto para o Cliente

Versão 207458


* SW-type -

* Unidade -


Pré-requisitos: Configure configuração encadeada

A execução do teste: Redefinição de 1 FR Verifique se o comprimento da fibra óptica medido de 2 FR está correto

Resultados esperados: Medido fibra óptica Comprimento de 2 FR está correto

Resultados inesperados: Medido fibra óptica Comprimento de 2 FR está incorreta


CN-id: LN40_00023

Título: FHCAs ficou inicialização falhar depois de atualização de software do MP3.1.4 para MP3.1.5 (SW 4.0.711)



Referências:

Razão para a mudança Nota: Resumo do problema original: FHCA que não arranca com sucesso Como usuário final / operador podia detectar o problema: A unidade não irá arrancar e ser detectado pelo BTS Descrição da falha: A atualização do componente FHCA uboot (componente SW parcial) pode acabar em um não uboot não está funcionando corretamente. O componente uboot é um passo necessário parcial da bota o processo de recuperação e se esse componente não está funcionando com sucesso, a unidade não irá arrancar e até mesmo cair para trás mecanismo pode ser prejudicada. Solução: N / D Descrição da correção (análise de risco incluído): A atualização envolvidos do uboot é considerada uma possível melhora da estabilidade FHCA mas não é uma necessidade para a operação da unidade. Portanto, a atualização foi desativada e o uboot original será usado para evitar este upgrade. Outros efeitos: Não atualizar o uboot não vai trazer a estabilidade possível aumento pretendido com este atualizar. Mas como este foi considerado uma possível melhora da estabilidade e não apenas um necessidade, o impacto deve ser limitado.

Componente defeituoso e versão: MTI SW 04.06.711

Relatórios anomalia corrigida: NA05356052 FHCAs ficou inicialização falhar depois de atualização de software do MP3.1.4 para MP3.1.5 (SW 4.0.711)


Componente FRR4-SW. -

Versão 04.07.709


* SW-type -

* Unidade -

Página 25









Pré-requisitos: Configurar 4 FHCA, L1111-Ic-XX-2TX-2RX eNB on-Air

A execução do teste: -Redefinição eNB -Reset FHCA -Power on / off FHCA

Resultados esperados: Celular é permitir com sucesso durante todos os casos de teste

Resultados inesperados: FHCA redefinir repetidamente e celular não pode ser habilitado

CN-id: LN40_00024


Título: RL40_General_FSMF: Após reposição do site, o reset autónoma de FHEA 1_6_1 desencadeada após 8 min



Referências:


Resumo do problema original: LFS fez mudança de cenário de sincronização em 4x velocidade do link. Após a mudança HWAPI envia primeiro API_OPT_SYNC_IND (Off) e, em seguida, API_OPT_SYNC_IND (Frame) para BTSOM durante o ajuste do buffer elástico. Código BTSOM (Após LTE1542 implementação característica) tentou re-sincronizar ligação com velocidade de link de 8x cenário e alarmes desnecessários foram gerados.

[Segunda questão] RP3-01 ligação por trás da interface de rádio RF6 em FSMF é resetado

Como usuário final / operador podia detectar o problema: Usando o FTM_EIF1/EIF3 e RF6 ao mesmo tempo

Descrição da falha: [Segunda edição] Interface FCTB EIF2/RF6 é a interface multiplexado entre ethernet e RP3-01. Além disso, o caminho ethernet (SGMII) do MCU pode ir tanto para esta interface compartilhada, ou para o FTIF_EIF3/FTIF_EIF1 (estes são portas combo). Este caminho é completamente configurada uma API. Esta API define ethernet a qualquer FTM ou à interface compartilhada. Se o caminho está definido para o FTM, a interface compartilhada é configurado como RP3. Se ethernet está definido para a interface compartilhada, RF6 não pode ser utilizado como portos e RP3 ethernet eIF3 / 1 em FTIF não pode ser utilizado. Quando o link S1 está em FTIF_EIF3/EIF1, TRSW (FTM) irá configurar este caminho, chamando ddal_mux_eth. Mas, se RF6 também está em uso, qualquer chamada para esta API, mesmo com o mesmo parâmetro, fará com redefinição de todos caminhos de dados incluído (RP3 para RF6, SGMII para FTM), que aconteceu neste caso. Sugestão foi TRSW ler primeiro estado deste multiplxer ethernet/rp3, depois para escrever, mas, este tinha falta desde LFS não ofereceu em seu estado API que mostra multiplexer é não configurado. Relacionadas característica / funcionalidade: LTE1542 Dependência de configuração: NÃO

Solução: Para usar FTM_EIF2/EIF4, FCT_EIF1

Descrição da correção (análise de risco incluído): LFS: rp3_link.c modificado. Ele deve fazer MURKKU2 configuração mais segura, impedindo ocasionais 2016 alarmes. [Segunda questão] LFS estendido API, TRSW começou a usá-lo

Página 27


BTSOM: Código BTSOM corrigido para que os cenários de ressincronização 4x foram adicionados de volta ao cenário de ajuste de atraso pi.

Efeitos sobre o usuário final: Sim

Efeitos sobre a operadora: Sim Há o terceiro setor não funciona se todos os três setores estão no ar. A falha em alarme Interface RP3 óptico no segundo módulo de rádio sobe.

Componente defeituoso entregue pela primeira vez em (por exemplo, lançamento, CD): FTM_LN40_MP1_334.00

Relatórios anomalia corrigida: NA05348560 FSMF Precoce Projeto :: 1 +1 +1 com RF Módulo FRHA 20 Mht BW, terceiro setor não está funcionando


Componente LN4.0

BTSPS-12234. -







Versão * elemento Net FTM_LN40_ - 324,02 -

* SW-type -

-

* Unidade -

-



Pré-requisitos: Configuração HW: FSMF + + FTIF 2xFRHA Versão SW: LN4.0_ENB_1202_692_yy

A execução do teste: Configurar eNB com 1 +1 +1 2600 20 Mhz Configuração (3 células MIMO com 20MHz Largura de banda) Utilização FTIF1 ou interface FTIF3

Resultados esperados: Sem alarme sobe, todos os setores estão funcionando, eNB está em estado de "no ar"

Resultados inesperados: "Falha na interface do RP3 opcital" no 2 º Módulo de Rádio sobe.


CN-id: LN40_00025

Título: Células deficientes são causados por alto tráfego - FSP colidiu com falhas 418

Problema com o contadores M8013C6, -7, - 8, -27)



Referências:

Razão para a mudança Nota: NA05356792: Resumo do problema original: 1. Problemas com UE atribui devido ao transbordamento de armazenamento do usuário MAC 2. Célula para baixo devido a DSP acidente na MAC. 3. Ao inatividade do usuário é detectada por um UE, pode acontecer que a liberação de conexão não foi enviado para a UE eo contexto UE só é excluído da rede. Como usuário final / operador podia detectar o problema: 1. Não Anexar possível ou muito difícil 2. Célula para baixo devido a DSP acidente 3. UE tenta reestablishments que falham. Descrição da falha: 1. Quando a UE foi eliminado na MAC, enquanto uma ordem PDCCH estava em andamento para obter a UE de volta em sincronia, pode acontecer que um contexto temporário UE indesejado foi criado para a UE no Prescheduler DL. Este contexto temporário UE depois permaneceu pendurado por um longo período de tempo, e esta levar a um excesso de armazenamento de usuário no programador DL. 2. Nesta situação com o armazenamento do usuário DL transbordante, pode acontecer que a UE foi programado pelo programador DL mesmo que ele já havia sido excluído. Se um TAC foi presente nesta alocação em PDSCH, a expiração do temporizador de guarda DL AN levaria a uma falha no prescheduler DL. 3. A situação descrita no 1. Acontece quando C-avião se prepara para lançar uma chamada devido ao usuário inactividade ser detectado para o UE. Neste caso, o C-plano envia um pedido para o UE PDCCH para verificar se ele ainda pode ser alcançado. Se a ordem PDCCH falhar, a UE é eliminado imediatamente na rede sem enviar o lançamento conexão com a UE. Mas, devido à o temporizador de guarda PDCCH no MAC PS ser muito curto, o fracasso ordem PDCCH foi detectado muito cedo, antes da UE tinha realmente transmitido seu preâmbulo, e por isso a UE foi eliminado na MAC PS antes que pudesse voltar a in-sync.

Relacionadas característica / funcionalidade: DRX estendida: LTE473 Dependência de configuração: Só ocorre quando DRX estendida estiver ativada Solução: Desativar DRX estendida

Página 30


Descrição da correção (análise de risco incluído): 1. Não agendar um preâmbulo dedicado no programador UL quando a UE já tem foi excluída. 2. a) Verificar a bandeira Stop-UE no programador DL antes de colocá-lo à lista de CS1 candidatos agendamento. b) Quando o temporizador de guarda DL AN expirar, verificar se a UE ainda existe antes de notificar o prescheduler DL sobre a expiração do temporizador c) Não agendar uma UE no programador DL quando ele já foi excluído. 3. Corrigir a duração do temporizador de guarda ordem PDCCH. Efeitos sobre o usuário final: 1. Anexar obras como esperado 2. Celular não vai para baixo. 3. Chamada está devidamente liberado quando inatividade do usuário é detectada pela UE. Efeitos sobre a operadora: KPIs ficar em bons níveis.

NA05354601:

Resumo do problema original: As células deficientes são causados por alto tráfego - FSP caiu com falhas 418

Como usuário final / operador podia detectar o problema:

Como usuário final / operador podia detectar o problema: OutOfSynchFinal relatou muito rapidamente.

Descrição da falha: Temporizador muito curta no gerenciador de DRX; repetições suficientes de Ordem PDCCH enviada. Conexões RRC estão sendo rejeitadas com baixo número de usuários conectados RRC (aprox. 20). Conexão RRC é rejeitada devido a DLSCH_UE_RECONFIG_RESP falhou devido a MAC não especificada

Solução: N / A

Descrição da correção (análise de risco incluído): Valor padrão de temporizador rdPdcchOrderExpT era muito pequeno - agora corrigida. MAC enviou uma repetição muito poucos de ordem PDCCH - agora corrigido.

Relatórios anomalia corrigida: NA05356792 Células deficientes são causados por alto tráfego - FSP colidiu com falhas 418

NA05354601 Problema com o contadores M8013C6, -7, - 8, -27)


Componente fb12.2 fb12_02. -


Versão 276082 276137

* Elemento líquida - -

* SW-type - -

* Unidade - -









Pré-requisitos: LTE 473 activada com perfil 4 ou 5 que está sendo usado. Fator de inatividade curto prazo e inatividade temporizador deve ser definido de tal forma que UE está indo de fora de sincronia antes de expirar inatividade temporizador

A execução do teste: Setup conexões RRC e deixar a UE entrar em estado de sincronia.

Resultados esperados: Quando voltar em sincronia via ordem PDCCH de eNB para liberar a conexão RRC, eNB costuma declarar UE fora de sincronia até UE tentou transmissões max preâmbulo sem sucesso

Resultados inesperados: Quando voltar em sincronia via ordem PDCCH de eNB para liberar a conexão RRC, eNB declara UE fora de sincronia antes UE foi capaz de tentar max preâmbulo transmissões sem sucesso


CN-id: LN40_00026

Título: PLMN errado em S1 TAI após S1 Entrega



Referências:

Razão para a mudança Nota: Resumo do problema original: Servindo PLMN em HONotify mensagem não foi o durante HO Prep calculado através Serving PLMN

Como usuário final / operador podia detectar o problema: Em vários rede do operador UE pode errar servindo PLMN após S1 HO

Descrição da falha: PLMN é retirado da lista HORestriction em vez de armazenados GUMMEI

Relacionadas característica / funcionalidade: S1 HO

Efeitos sobre o usuário final: Depois de usuário final S1 HO acaba com diferentes ID PLMN que antes HO

Efeitos sobre a operadora: Nenhum

Efeitos do sistema: Nenhum

Outros efeitos: Nenhum

Efeitos de interface: Nenhum

Componente defeituoso e versão: UEC

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): RL40

Relatórios anomalia corrigida: NA05311458 PLMN errado em S1 TAI após S1 Entrega

Página 33



Componente UEC. -







Versão 127113


* SW-type -

* Unidade -


Pré-requisitos: Dois eNBs configurados com a mesma PLMN Certifique-se de prestar atenção como você configura vocês são os IDs MMES e PLMN no arquivos de configuração do ENB. A SIM / assinante configurado com PLMN diferente. Configure o MME para que o MME não vai enviar uma lista de Entrega Restrição na Entrega Request. Em NS 2.2 A configuração é feita em mmetrh.ini

PLMNs equivalentes Flag para indicar se PLMNs equivalentes devem ser incluídos no Prenda / TAU Aceitar mensagem. Se a necessidade de ser incluída definir esse valor para '1 'else definido para '0'. O valor padrão é '0 ' EquivalentPlmnFlag = 0

Você tem que definir EquivalentPlmnFlag = 0 e, em seguida, o MME não será enviado HRL (Handover Lista de restrição).

A execução do teste: Realize S1 entrega e verificar a mensagem desejada Entrega da fonte eNB lado. Em seguida, verifique se não há nenhuma lista de restrição de Entrega vindo do MME, o que pode ser visto a partir da mensagem de Pedido de Transferência de que vem para o eNB alvo. Finalmente, do Handover Notificar mensagem que vem de alvo eNB, verifique o TAI e verificar o PLMN é a configurada para o SIM / assinante.


Resultados esperados: Durante uma transição S1 entre dois eNBs - o eNB é capaz de determinar a correta PLMN para o cliente

Resultados inesperados: Durante uma transição S1 entre dois NSN eNB, parece que o eNB não é capaz de determinar a PLMN correta para o cliente, para que ele simplesmente usa própria PLMN do eNB


CN-id: LN40_00027

Título: Mudanças Site-ID em BTS Manager não visíveis no Editor de CM



Referências:

Razão para a mudança Nota: Resumo do problema original: Por causa dos problemas com as condições de corrida em BTSOM alguns dados link relacionado X2 tinha sido incorretamente mostrado no Gerenciador de BTS.

Como usuário final / operador podia detectar o problema: Os dados estão errados sobre Link em GUI.

Relacionadas característica / funcionalidade: Ue Based ANR - cenários excepcionais que leva a cópia LNADJ, ou aumento de remoção possibilidade de condições de corrida em BTSOM. A manipulação cenário excepcional foi simplificada.

Dependência de configuração: Ue Based ANR habilitado. Um monte de links estabelecidos em um momento.

Solução: Desativar Ue Based ANR.1

Descrição da correção (análise de risco incluído): Em casos excepcionais simplificada. Não há novas funcionalidades adicionadas, apenas a remoção de código, risco muito baixo.

Efeitos sobre o usuário final: Operador não tem informações completas e corretas sobre o status do link X2, por isso pode ser confusa e tentar reconfigurar essas ligações, que no caso são estabelecidos os links pode levar a algumas cedências infrutíferas.

Efeitos sobre a operadora: Casos excepcionais Simplificado leva a melhor curva de aprendizado do sistema.

Efeitos do sistema: Cenários excepcionais simplificado o que leva a mais fácil análise possíveis problemas.

Componente defeituoso e versão: Rrom LN4.0


Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): LN3.0

Relatórios anomalia corrigida: NA05325301 Mudanças Site-ID em BTS Manager não visíveis no Editor de CM


Componente LTE_CP_20778. - Rrom. -







Versão 4.3 130596


* SW-type - -

* Unidade - -


Pré-requisitos: eNB ligado a NetAct

A execução do teste: Alterar parâmetro btsId via NetAct ou BTSSM. Espere 15 minutos seguintes para um reboot BTS.

Resultados esperados: O valor btsId em CM Editor é atualizado para o novo valor que foi fornecido através de plano provisionamento ou mudança BTSSM. Os objectos LNADJ que estão correlacionadas com mudado BTS também alterou os valores para um novo.

Resultados inesperados: O btsId não mudar em CM Editor para um novo valor. Os objetos são correlacionados LNADJ também inalterada.


CN-id: LN40_00028

Título: FSP acidente no MAC-PS (F2C1)



Referências:

Razão para a mudança Nota: Resumo do problema original: DSP acidente devido ao acesso à memória ilegal

Como usuário final / operador podia detectar o problema: Célula para baixo. Nenhum serviço.

Descrição da falha: O acidente foi causado por um acces memória ilegais que causou uma exceção HW seguido por um acidente de CPU. O motivo foi a falta para fora dos limites de verificação de um índice de array.



Solução: Nenhum

Descrição da correção (análise de risco incluído): A correção consiste em um novo cheque, que impede o acesso de memória ilegal. O risco é baixo, já que a correção apenas aborda o problema encontrado e não tem efeitos colaterais.

Relatórios anomalia corrigida: NA05331292 FSP acidente no MAC-PS (F2C1)



Componente fb12_02. -







Versão 274529


* SW-type -

* Unidade -


Pré-requisitos: eNB deve ser serviço contínuo ea realização de alto tráfego.

A execução do teste: N / D É quase impossível de reproduzir este acidente

Resultados esperados: Nenhum acidente na FSP durante o serviço

Resultados inesperados: Bater ocorre na FSP com 418 alarme


CN-id: LN40_00029

Título: ERAB liberar Contador Incompatibilidade



Referências:

Razão para a mudança Nota: Resumo do problema original: Para alguns casos de libertação ERAB correspondentes contadores de desempenho, onde não incrementado. Afetadas contador IDs pm: M8006C6, M8006C7 Além disso contadores erradas onde incrementados vez: IDs Afetados: M8013C9, M8013C10

Como usuário final / operador podia detectar o problema: Problema pode ser detectada através da comparação da quantidade real realizado M8006C6, M8006C7 de imprensa com os valores desses dois contadores. Problema existe se o valor da contadores é menor do que o esperado e os valores da M8013C9 e M8013C10 são maiores do que esperado.

Descrição da falha: Em um dos caminhos de execução incrementação para M8006C6, M8006C7 onde falta. M8013C9 e M8013C10 foram incrementadas em vez disso.



Solução: Nenhum

Descrição da correção (análise de risco incluído): Falta M8006C6, incrementations M8006C7 prestados. Incrementations erradas para M8013C9 e M8013C10 foram removidos. Correção não afeta qualquer outra funcionalidade.


Muito baixo risco de introdução de novos erros

Efeitos sobre a operadora: Contadores são incrementados de forma incorreta.

Relatórios anomalia corrigida: NA05331811 ERAB liberar Contador Incompatibilidade


Componente UEC. -







Versão 126912


* SW-type -

* Unidade -


Pré-requisitos: A UE deve ter mais de 2 E-RAB, Default portador e dedicado ao Portador

A execução do teste: MME enviar o S1AP: portador dedicado E-RAB LIBERAÇÃO DE COMANDO relacionada com eNB.

Resultados esperados: M8006C6. Balcão EPC_EPS_BEARER_REL_REQ_NORM deve ser atualizado.

Resultados inesperados: Não há qualquer atualização para M8006C6. EPC_EPS_BEARER_REL_REQ_NORM


CN-id: LN40_00030

Título: Frig não pôde ser detectado (falha na interface do RP3 óptico) após eNB desceu com Problemas de GPS



Referências:

Razão para a mudança Nota: Resumo do problema original: BTS não começou com sucesso

Como usuário final / operador podia detectar o problema: BTS não detectou rádio.

Descrição da falha: Houve problema com o GPS e quando que foi combinado com a leitura de SFN contra 1PPS (fornecida pelo GPS) seria preso com código de erro -22 (parâmetro inválido).

Dependência de configuração: Conexão GPS Bad

Descrição da correção (análise de risco incluído): Se tempo limite acontece durante SFN ler contra 1PPS a configuração necessária no HW está desmarcada. Isso permite que as leituras subseqüentes sem o erro -22 (parâmetro inválido).

Relatórios anomalia corrigida: NA05332612 Frig não pôde ser detectado (falha na interface do RP3 óptico) após eNB desceu com Problemas de GPS


Componente BTSPS-11744. -


Versão -


* SW-type -

* Unidade -

APROVADO 2.0 Página 42








Pré-requisitos: O eNB é comissionado com FSMF e frig. GPS está em uso e sincronização de fase é habilitado. Pelo menos uma célula é "no ar".

A execução do teste: Pressione o botão "reset local" na administrador do site para iniciar uma redefinição Cerca de um minuto após o início do reset, desconecte o cabo de sincronização GPS do FSMF. Observe o arranque eo estado da eNB após o arranque processo é longo.

Resultados esperados: Faltando na inicialização Alarm "relógio de referência PPS (id: 4153) é visto e eNB permanece em Estado integrado. Quando o cabo GPS está ligado de volta, eNB vem no ar depois de fazer uma auto zerado.

Resultados inesperados: Frig não é detectado e FSMF é preso em estado "inicializado".


CN-id: LN40_00031

Título: Não pode desbloquear fôrma



Referências:

Razão para a mudança Nota: Resumo do problema original: Módulo de rádio não conseguiu realizar Bloco / processo de desbloqueio por causa do tempo limite

Descrição da falha: Durante módulo de rádio Bloqueio / Desbloqueio está realizando reinicialização. Durante a reinicialização, houve 'flash procedimento arquivos realocação 'executado, apesar de que não deveria. A culpa foi nesse procedimento e ele impediu procedimento de cumprimento bem-sucedido (falha estava relacionada com situação específica em flash). É por isso que na próxima reinicialização foi iniciado novamente e causou tempo de espera em bloco / desbloquear.

Descrição da correção (análise de risco incluído): Melhorias no flash de dispositivo virtual, especialmente no procedimento "flash arquivos de reafectação".

Relatórios anomalia corrigida: NA05332769 Não pode desbloquear fôrma


Componente FRM23.01.R02J

Versão * elemento Net FRM23.01.R - 02J

* SW-type -

* Unidade -



Página 44







Pré-requisitos: Realocação Arquivo Flash precisa ser danificado que é quase impossível de se reproduzir

A execução do teste: Durante módulo de rádio Bloqueio / Desbloqueio está realizando reinicialização. Durante a reinicialização, houve 'flash procedimento arquivos realocação 'executado, apesar de que não deveria. A culpa foi nesse procedimento e ele impediu procedimento de cumprimento bem-sucedido (falha estava relacionada com situação específica em flash). É por isso que na próxima reinicialização foi iniciado novamente e causou tempo de espera em bloco / desbloquear.

Resultados esperados: Procedimento "arquivos Flash realocação 'é melhorada

Resultados inesperados: Módulo de rádio ainda é incapaz de executar Bloco / processo de desbloqueio


CN-id: LN40_00032

Título: FSMF eNB reinicialização espontânea no modo de teste Dedicado



Referências:

Razão para a mudança Nota: Resumo do problema original: FSMF eNB reinicialização espontânea no modo de teste Dedicado

Como usuário final / operador podia detectar o problema: Logo após reiniciar em modo de teste dedicado a eNB reinicia espontaneamente e recupera no modo operacional normal

Descrição da falha: Problema ocorreu, porque não havia inapropriado recuperação de acção para a Falha 10 em teste Modo Dedicado. Em TDM não é marcada, que começa de transporte. Mas, neste caso, depois terminar o trabalho por CReadyChecker (durante a inicialização), ocorreu falha 10 nos dizendo, que transporte não iniciar - que causou reposição do site (ação de recuperação para esta falha).


Solução: Não há solução

Descrição da correção (análise de risco incluído): Ação de recuperação Changed por culpa 10 causados pelo transporte em estado de teste dedicado. atributo isTestDedicatedEnabled adicionado ao banco de dados e mudou falha 10 em serviço FlexiFDrules. Mudanças necessárias na documentação tem sido feito.

Efeitos sobre a operadora: eNB não wiil repor no modo de teste dedicado.




NA05335948 FSMF eNB reinicialização espontânea no modo de teste Dedicado


ComponentVersion FlexiFDrules.txt206039 FORE_FDDC_Pk 206039 g.sbs FoundationModel 206039 sbs. STUP.sbs206039








-

-

* SW-type - -

-

-

* Unidade - -

-

-


Pré-requisitos: FSMF com FTIF opcional, configure LCELL / LNCEL com alguma rádio.

A execução do teste: Iniciar o modo de teste dedicado via BTS SM, Monitorar o eNB se pode com sucesso entra em modo de teste e permanecer neste estado, a menos comando do operador para sair Teste Dedicado modo.

Resultados esperados: eNB entra com sucesso o modo dedicado teste e entrar em cada modo de ensaio, sem reinicialização espontânea

Resultados inesperados: eNB fazer reinicialização espontânea, sem qualquer comando do operador


CN-id: LN40_00033

Título: Teste do site não é suportado com: software LN4.0_ENB_1202_689_00.



Referências:


Resumo do problema original: Menu de testes do site não pode ser selecionado e testes não podem ser executados a partir do Gerenciador BTS Site.

Como usuário final / operador podia detectar o problema: O item de menu testes do site não pode ser selecionado com RL eNB software - Mensagem de erro: "Corre local testa Indisponível porque BTS HW não suporta testes do site".

Descrição da falha: BTS está em estado OnAir e selecione a partir do site BTS testes de menu gerente - Testes do Site.

O item de menu testes do site não pode ser selecionado com RL eNB software - Mensagem de erro: "Corre local testa Indisponível porque BTS HW não suporta testes do site".

Relacionadas característica / funcionalidade: Testes de Gabinete / Site.

Dependência de configuração: Todas as configurações BTS contendo HW que suporta testes do Site.

Solução: Nenhum

Descrição da correção (análise de risco incluído): BPF propriedade Cab.Test.Supported mudou de protegido para Pública para todos os recursos de HW. Isso significa que atributo será também visível a BTS Site Manager no arquivo SiteConf.xml.

Efeitos sobre o usuário final: Usuário é capaz de selecionar os testes do site a partir do menu Gestor BTS site e acionar a sua execução. LTE_RL40_1.0 Mudança Nota Formas

A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0 Página 48

Efeitos sobre a operadora: Operador é capaz de selecionar os testes do site a partir do menu Gestor BTS site e acionar seu execução.

Relatórios anomalia corrigida: NA05338227 Teste do site não é suportado com: software LN4.0_ENB_1202_689_00.


Componente FDDLTEBPFReq uestExcel. - FlexiBTSProperti es.xml







Versão 567

3780


-

* SW-type -

-

* Unidade -

-


Pré-requisitos: Devidamente comissionados e eNB operacional. RET não é usado na configuração eNB.

A execução do teste: Comece BTS gerente do site A partir do menu selecione testes testes do site Press Start

Resultados esperados: É possível selecionar e executar testes do site.


Resultados inesperados: Testes do site não pode ser selecionada ou seja, a opção fica esmaecida.


CN-id: LN40_00034

Título: Quando 2 frigs foram desligados e, em seguida, de volta, um deles não veio e sua celular foi feito com defeito com id alarme: 1868.



Referências:

Razão para a mudança Nota: Resumo do problema original: Falha 10 é rehandled muitas vezes e leva muito tempo, e faz com que a manipulação culpa atraso construir-up.

Como usuário final / operador podia detectar o problema: Repetibilidade contínua de óptica ficha do cabo de teste / desligue eventualmente faz com que células configuradas para ir com defeito com 1.868 culpa

Descrição da falha: Falha 10 desnecessariamente rehandled ao cancelar culpa 4161. Além disso, culpa quando remanejamento 10, que já está armazenado para FR, saltos desnecessários são executados por todos os rulesteps em FDrule que lida com culpa 10.

Relacionadas característica / funcionalidade: FlexiFDrules


Solução: Ao manusear / remanejamento culpa 10 por causa de outras falhas e culpa 10 já está armazenado para FR, apenas alarme adequado é enviado ao componente FDAR e posterior manipulação de falha 10 está terminou. Rulestep Removido em 4161 culpa cancelar regra que rehandled falhas armazenados para FR.

Descrição da correção (análise de risco incluído): Falha 10 manipulação de speed-up, se ele é tratado / rehandled por causa de outros defeitos e falhas 10 já está armazenado para FR . Removido remanejamento desnecessário de culpa 10 ao cancelar culpa 4161.

Efeitos sobre o usuário final: Nenhum

Efeitos sobre a operadora: Manipulação múltipla óptica / contínuo plugue do cabo de teste / desligue culpa causa atraso build-up, e probabilidade de que as células vão defeituoso.

Página 51


Relatórios anomalia corrigida: NA05338860 Esporadicamente FHCCs são perdidas durante a ficha do cabo ótico / teste desligue e células configuradas finalmente vai para defeituoso com 1868 em modo acoplado


Componente FlexiFDRules. -







Versão 203453


* SW-type -

* Unidade -


Pré-requisitos: FSME / FSMF com FHCC e FXCA para formar a configuração de rádio acoplado.

A execução do teste: Realizar teste de funcionalidade básica OAM regular (# of / módulo RF desbloquear bloco, # de poder módulo RF ciclo, número de óptica rompimento de cabo como guiada com manual de operação)

Resultados esperados: O módulo de rádio em teste deve ser chegar a habilitado sem qualquer excepcional erro (RP3 - 10). Célula afetada chegar a habilitado

Resultados inesperados: Às vezes o módulo de rádio em teste se perder e se mudou para celular com defeito.


CN-id: LN40_00035

Título: Falha ID 2016 Nome Solicitação de Mudança de redefinição Autónoma como ação de recuperação em vez de Fracasso ônibus Baseband



Referências:

Razão para a mudança Nota: Resumo do problema original: Alarme errado exibido na SEM 2016 em culpa ocorrência.

Como usuário final / operador podia detectar o problema: "Falha de ônibus Baseband" em vez de "Unidade de reset autônomo" exibido na SEM em falta 2016 ocorrência.

Descrição da falha: Alarme errado enviado ao manusear falhas 2016 e execução "RestartSync" ação de recuperação.

Relacionadas característica / funcionalidade: Gerenciamento de Falhas


Solução: Alarme enviado mudou em FlexiFDrules.

Descrição da correção (análise de risco incluído): Ao executar RestartSync alarme ação de recuperação mudou de "falha de ônibus Baseband" alarmar 52 de reset Unit.


Efeitos sobre a operadora: "Falha de ônibus Baseband" em vez de "Unidade de reset autônomo" exibido na SEM em falta 2016 ocorrência.



Página 53



Componente defeituoso e versão: FlexiFDrules.txt

Evidência ação preventiva: Acionar culpa 2.016 EFaultId_Muksu_SMTimeOffAl por culpa OIC fonte adequadamente relações de banco de dados configurados. "RestartSync" ação de recuperação devem ser executados e alarme 52 "EFaultId_UnitAutonomousResetAl" visível em SEM. Testcase TEST001_SMTimeOffAl_StartAndCancel_CellStateBackToWorking disponível no porta-malas.

Relatórios anomalia corrigida: NA05338922 Falha ID 2016 Nome Solicitação de Mudança de redefinição Autónoma como ação de recuperação em vez de Fracasso ônibus Baseband


Componente FlexiFDrules.txt







Versão 202871


* SW-type -

* Unidade -


Pré-requisitos: FSME / FSMF, módulo de rádio, Node ópticos ativos fornecidos pela SolidTech ou WooriNet

A execução do teste: Conecte o nó óptico ativo entre FSME / FSMF e Rádio Módulo. Gatilho periódica byte stuffing via comando CLI no Active Optical Terminal Node. Monitorar o comportamento de FSME / FSMF como eles tentam recuperar a medição PI errado RP3-01 UL condição.


Resultados esperados: Módulo do Sistema deve fazer Optic ressincronização Recovery com alarme Texto Unit " autônoma redefinir como ação de recuperação (2016) "

Resultados inesperados: Módulo do Sistema pode fazer Optic ressincronização Recovery com alarme Texto "Baseband falha de bus (2016) "


CN-id: LN40_00036

Título: "Falha na interface do RP3 óptica" alarme foi visto por FRIE-3 após a atualização para 1202_689_00



Referências:

Razão para a mudança Nota: Resumo do problema original: Falha na relação RP3 óptica

Como usuário final / operador podia detectar o problema: Congela módulo RF e conexão solta na interface óptica.

Descrição da falha: Houve um vazamento de memória introduzido no software do módulo de rádio durante a correção implementação.

Relacionadas característica / funcionalidade: DAPD


Solução: Nenhum (atualização SW é essencial)

Descrição da correção (análise de risco incluído): Vazamento de memória Removido

Efeitos sobre o usuário final: Conectando-se a BTS é possível

Efeitos sobre a operadora: BTS está funcionando bem

Componente defeituoso e versão: Módulo de rádio versão do software FRM23.01.R02J

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): FRM23.01.R01




NA05339343 "Falha na interface do RP3 óptica" alarme foi visto por FRIE-3 após a atualização para 1202_689_00


Componente BTSRFM. -

Versão BTSRFM- 13408


* SW-type -

* Unidade -








Pré-requisitos: O eNB é comissionado com FSMF e FRIE e é "no ar".

A execução do teste: Execute a atualização SW SW de lançamento atual para o lançamento SW RL40 1.0.

Resultados esperados: Após a atualização SW e ativação, eNB é capaz de vir no ar.

Resultados inesperados: "Falha na interface do RP3 óptica" alarme é visto pela FRIE após a atualização e afins célula torna-se deficiente.


CN-id: LN40_00037

Título: Vazamento de memória BTSOM ocorreu quando o módulo RF é bloqueado e desbloqueado repetidamente.



Referências:

Razão para a mudança Nota: Resumo do problema original: Fixação de vazamento de memória em OAM: - AntennaLineAgent objeto não foi retirado após bloco de RF - Os dados lidos do banco de dados não foi lançado

Como usuário final / operador podia detectar o problema: eNB redefinição

Descrição da falha: eNBs redefinir devido a falta de memória.

Relacionadas característica / funcionalidade: Bloco de RF / desbloquear

Solução: Não


Descrição da correção (análise de risco incluído): Fixação de vazamento de memória. Risco pequeno.

Efeitos sobre o usuário final: eNB redefinição

Efeitos sobre a operadora: eNB redefinição

Relatórios anomalia corrigida: NA05341814 Vazamento de memória BTSOM ocorreu quando o módulo RF é bloqueado e desbloqueado repetidamente.

Página 58



Componente OAM. -







Versão 205131


* SW-type -

* Unidade -


Pré-requisitos: eNB on-Air, BTSSM instalado

A execução do teste: Executar Reiniciar Unidade repetidamente (mais de 20 vezes)

Resultados esperados: Não BTSOM vazamento de memória

Resultados inesperados: Aumento BTSOM memória e nunca mais voltar a memória novamente.


CN-id: LN40_00038

Título: Falta de ativação do plano no log de feedback - reiniciar parcialmente eNodeB necessário



Referências:


Resumo do problema original: Do ponto de vista técnico, C-Plane rrom ficar preso em estado especial chamado ErrorState - é devido à falta de ações de recuperação são definidos.

Como usuário final / operador podia detectar o problema: Cada comissionamento delta é encerrado com estatuto notok com informações adicionais que Plano arquivo de rede é enviar segunda vez.

Descrição da falha: Indefinido.

Relacionadas característica / funcionalidade: LTE782d

Dependência de configuração: Nenhuma dependência conhecido na configuração

Solução: Não workaraound conhecido

Descrição da correção (análise de risco incluído): Correção incluída a melhoria de registro para rastrear porque rrom está na ErrorState e atualização de informação enviar para NetAct / BTSSM aconselhando BTS reiniciar.

Efeitos sobre o usuário final: Desconhecido.

Efeitos sobre a operadora: Realimentação recomissionamento Falha sugerem BTS reiniciar.

Efeitos do sistema: Sem efeitos do sistema.


Outros efeitos: Nenhum outro efeito.

Efeitos de interface: Informações mais precisas a ser enviada como um feedback para a configuração do delta Operações de ativação / validação.

Componente defeituoso e versão: RROMexe

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): RROMexe

Relatórios anomalia corrigida: NA05336271 Falta de ativação do plano no log de feedback - reiniciar parcialmente eNodeB necessário


Componente RROMexe. -






Impacto para o Cliente NA05338403:

Versão 130176


* SW-type -

* Unidade -


Pré-requisitos: Prepare eNB Uma configuração com passos seguintes: - LTE492 está habilitado (anrOmExtEnable em LNBTS) - Criar LNADJ com objetos LNADJL - PciIpAddrMap (LNBTS) são ajustados para que ele contenha pci de LNADJL e falso IP endereço - Criar LNREL LNADJL correspondência


A execução do teste: 1. On eNB Adicione LNADJ (eNB controlada) para eNB B com endereço IP falso (para que ligação estado é indisponível) 2. On eNB B adicionar LNADJ (OAM controlada) para eNB A 3. Configuração X2 é enviar de B para A, antiga brincadeira LNADJ removido, novo criado 4. Faça uma disposição plano de NetAct

Passos 1 -. 4. Deve ser feita em 130 segundos (maxTimeSctpSetup).

Resultados esperados: Provisão Plano de sucesso. No caso de falha de provisionamento NetAct exibe MRBTS corretamente ID na mensagem de erro.

Resultados inesperados: Falha provisão Plano. Não NetAct não exibir MRBTS ID em caso de falha.


CN-id: LN40_00039

Título: eNB autónoma reinicialização devido ao "EFaultId_NoConnectionToUnitAl" (ID: 10) para FSPD observada em um site



Referências:

Razão para a mudança Nota: Resumo do problema original: Processador Cavium OCTEON produzir erros ECC espúrias sob algumas circunstâncias.

Como usuário final / operador podia detectar o problema: Sistema reinicia ocasionalmente.

Descrição da falha: A memória TLB é protegido por paridade para detectar potencialmente a ocorrência de um único bit erros na matriz de memória. Sob certas circunstâncias, é possível que uma TLB instrução para causar um erro de paridade TLB ao fogo indevidamente. As circunstâncias se relacionam com o tempo de uma pré-busca ou demanda de instrução L1 cache de encher depois de um TLBW, TLBWI, TLBWR, ou TLBR operação. O TLB irá relatar uma exceção de verificação de máquina espúria, indicando um erro de TLB paridade e registo EPC serão corrompidos, tornando o sistema não recuperável.

Solução: Definir CvmCtl [IPREF] para 1 em cada núcleo.

Descrição da correção (análise de risco incluído): Fix lançado pela Cavium no SDK 2.3 e SDK 3.0. Remendo de OCTEON SDK 3.0 aplicado.

Relatórios anomalia corrigida: NA05342285 eNB autónoma reinicialização devido ao "EFaultId_NoConnectionToUnitAl" (ID: 10) para FSPD observada em um site



Efeitos da mudança: LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL

Versão r36882


* SW-type -

* Unidade -








Pré-requisitos: eNB encomendado com FSMF está no ar.

A execução do teste: eNB está no ar e passando por atividade ou seja, as chamadas normais.

Resultados esperados: Não resets autônomos deve ser visto.

Resultados inesperados: Autónoma redefinir devido a "EFaultId_NoConnectionToUnitAl" (id: 10) para FSPD não é esperado.


CN-id: LN40_00040

Título: Packet descarte devido ao protocolo não suportado contado como ifInErrors15



Referências:

Razão para a mudança Nota: Resumo do problema original: Packet descarte devido ao protocolo não suportado contado como ifInErrors15

Como usuário final / operador podia detectar o problema: Comissão eNB. Enviar pacotes OSPF Verifique ifInErrors15 balcão

Descrição da falha: OSPF não é compatível com LTE e, portanto, esses pacotes são descartados foram contados como pacotes. A especificação não menciona explicitamente como este pacote precisa ser tratada.

Relacionadas característica / funcionalidade: PM Básico


Solução: Nenhum

Descrição da correção (análise de risco incluído): Foi acordado com especificação de que o protocolo não suportado e incompatibilidade de versão IP não será contadas neste balcão e armazenadas no D contra internas de P &.


Efeitos sobre a operadora: Erro desnecessário incremento contagem de pacotes



Página 65



Componente defeituoso e versão: LN4.0_ENB_1202_691_00

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): [EFS-SPEC] SW-Impacto = Sim Impactados-Programas = LTM4.0 Customer-Impacto = contador de erro é aumentada embora nenhuma situação de erro real existe. Provenientes = BTS-Pronto Elaborado-Change = O "protocolo não suportado" motivo de descarte é movido a partir do erro contra a BTS contra a filtragem de pacotes, onde faz mais sentido. -------------------------------------------- TRS-Esforço-Hours = 8 TRS-Responsável = Simon Schneider TRS-Eval-Date/LE = 2013/02/20 TRS-Eval-Done = Sim ======================================= [LTM4.0] SW-Responsável = Viswanathan V SW-Esforço-Hours = SW-Eval-Date = AAAA-MM-DD -------------------------------------------- SV-Responsável = Sunil Sambanni N SV-Esforço-Hours = SV-Eval-Date = AAAA-MM-DD --------------------------------------------

Relatórios anomalia corrigida: NA05342354 descarte de pacotes devido a protocolo não suportado contado como ifInErrors15


Elemento líquido ComponentVersion * lte_rla_np_na053 FTM_LN40_ - 42354_ifinerror_fi MP1_328.00 x -. 0,01





Página 66

* SW-type -

* Unidade -





Pré-requisitos: ENB com unidade FTLB

A execução do teste: Apresente VRRP, OSPF ou outros protocolos não suportados na rede de tal forma que estes alcançar eNB Observe IfInError15 (M5112xC4) Contador

Resultados esperados: IfInErrors15 contador não deve aumentar devido a esses pacotes

Resultados inesperados: IfInErrors15 conta estes protocolo não suportado como erros


CN-id: LN40_00041

Título: E-RAB DR (LTE_5025C) e RRC UEs Conectado (LTE_1076A) aumentou após RL40 P8 atualização



Referências:

Razão para a mudança Nota: Resumo do problema original: Especial temporizador QCI5 inatividade no MAC PS leva ao aumento da chamada cai na rede devido a prolongamento de chamadas com QCI5 portador.

Como usuário final / operador podia detectar o problema: Aumento no número de chamadas abandonadas KPI.

Descrição da falha: Chamadas com um QCI5 portador usar 60 segundo timer de inatividade, sob certas condições, em vez do temporizador de inatividade normal, que é definido como 10 segundos. Isto leva a uma ligação mais longo duração e, portanto, a uma maior probabilidade queda de chamada para estas chamadas.

Relacionadas característica / funcionalidade: VoLTE

Dependência de configuração: Só ocorre se portadores QCI5 são configurados para UEs.

Solução: Use R & D parâmetro rdQci5SignInactivityTimer = 0 para desativar a inatividade especial QCI5 timer.

Descrição da correção (análise de risco incluído): Desativar QCI5 inatividade temporizador por padrão, definindo rdQci5SignInactivityTimer = 0 em SW construir.

Efeitos sobre o usuário final: VoLTE usuários irão experimentar o temporizador de inatividade normal, que em 10 segundos é bastante curto para VoLTE.

Efeitos sobre a operadora: KPI de volta aos bons níveis.

Relatórios anomalia corrigida: NA05342431

Página 68


E-RAB DR (LTE_5025C) e RRC UEs Conectado (LTE_1076A) aumentou após RL40 P8 atualização


Componente LTE_UP_8700. - fb12.2







Versão 32,4 274747


* SW-type - -

* Unidade - -


Pré-requisitos: eNB instalada, em pleno funcionamento

A execução do teste: Deixe eNB em estado operacional, observe E-RAB DR e RRC UEs Conectado.

Resultados esperados: DR E-RAB (LTE_5025C) e RRC Conectado UEs (LTE_1076A) são em bons níveis (Semelhante a este antes da implantação RL40 P8 SW)

Resultados inesperados: DR E-RAB (LTE_5025C) e RRC Conectado UEs (LTE_1076A) ainda são mais elevados do que antes da implantação RL40 P8 SW


CN-id: LN40_00042

Título: No PCI alarme duplicação (6307) ocorreu em TD4.1



Referências:

Razão para a mudança Nota: Resumo do problema original: Sem alarme 'X2 vizinho inconsistência configuração de célula'

Como usuário final / operador podia detectar o problema: Só através da duplicação PCI (Cell ID Física) Informação por conta própria em Site Manager e que não provocaria qualquer alarme

Descrição da falha: Nenhuma implementação de falhas 6307 em Gerenciamento de Falhas

Descrição da correção (análise de risco incluído): Implementado manuseio de falhas 6307 em arquivo FlexiFDrules.xml

Efeitos sobre o usuário final: Handovers entre as células com o mesmo PCI em ENB de adjacentes pode não ser possível

Efeitos sobre a operadora: Não há informações sobre possíveis problemas em handovers

Componente defeituoso e versão: FlexiFDrules.xml

Relatórios anomalia corrigida: NA05329182 No PCI alarme duplicação (6307) ocorreu em TD4.1





Versão 206726


* SW-type -

* Unidade -








Pré-requisitos: Dois eNB tem LNADJ (configuração X2 conclusão) entre si. Criar LNADJs entre eNB 62 e eNB63. Configuração X2 é comleted.

A execução do teste: Definindo mesmo PCI (322) para um celular de eNB62 e uma célula de eNB63.

Resultados esperados: eNB62 e eNB63 levantada 6307 alarme.

Resultados inesperados: eNB62 e eNB63 não levantam 6307 alarme.


CN-id: LN40_00043

Título: RL40-piloto: FSMF-NTP Interrupção alarmante com novo módulo HW FSMF



Referências:

Razão para a mudança Nota: Resumo do problema original: FSMF-NTP Interrupção alarmante com novo módulo HW FSMF

Como usuário final / operador podia detectar o problema: Quando problema ocorre nenhuma configuração adicional será aceito a partir de SEM por exemplo Se o servidor NTP válido é configurado e erro, se o servidor mais tarde inválido está inscrita no SEM AaSNTP irá relatar status inválidos.

Descrição da falha: CCS (AaSNTP) permanece em estado inválido, assim, nova configuração NTP de SEM não é tomada.

Relacionadas característica / funcionalidade: N / D

Dependência de configuração: N / D

Descrição da correção (análise de risco incluído): Se o servidor NTP externo é CCS inacessíveis (AaSNTP) irá reiniciar ntpd (NTP Daemon) para acelerar o processo de mudança de NTP externo. Pode aconteceu que, neste caso CCS (AaSNTP) permanece em estado inválido, portanto, não aceitando configuração adicional ntp (se novo servidor NTP é adicionado em MEV). Esse problema é corrigido, por isso novas configurações NTP não são ignorados

Efeitos sobre o usuário final: N / D

Efeitos sobre a operadora: Nova configuração NTP não é aceito Status NTP inválidos

Efeitos do sistema: N / D


Outros efeitos: N / D

Efeitos de interface: N / D

Componente defeituoso e versão: CCS (AaSNTP)

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): N / D

Relatórios anomalia corrigida: NA05336319 RL40-piloto: FSMF-NTP Interrupção alarmante com novo módulo HW FSMF









Versão -


* SW-type -

* Unidade -


Pré-requisitos: NetAct, OMS e eNB estão funcionando com carga LTE SW eNB, OMS e NetAct são integrados O eNB é comissionado Plano de gerenciamento de NetAct, OMS e eNB está operacional A topologia NE é carregado para OMS


A execução do teste: Passo 1: Administração de eNodeB para o servidor de NTP


Acesse o painel Time System e digite o endereço IP do servidor NTP Passo 2: Configuração de errado endereço IP do servidor NTP: Passo 3: Verifique alarme na BTS Site Manager Passo 4: Verifique alarme em NetAct Alarm monitor

Resultados esperados: Passo 1: Depois de pouco tempo o estado na janela deve ficar concluída eo estado mostrado é OK, o que significa que a conexão entre o cliente eNB NTP NTP e sincronismo servidor na rede OAM é estabelecida Passo 2: Depois de pouco tempo o estado na janela deve ficar concluída eo estado apresentada não for OK, o que significa que a conexão entre o cliente eNB NTP NTP e sincronismo servidor na rede OAM não é estabelecida Passo 3: O alarme é relatada na BTS Site Manager Passo 4: Alarme é relatado na NetAct Alarm monitor

Resultados inesperados: Passo 1: Depois de pouco tempo o estado na janela não se completou eo estado apresentada não for OK, o que significa que a conexão entre o cliente eNB NTP NTP e sincronismo servidor na rede OAM não é estabelecida Passo 2: Depois de pouco tempo o estado na janela não se completou eo estado mostrado é OK, o que significa que a conexão entre o cliente eNB NTP NTP e sincronismo servidor na rede OAM é estabelecida Passo 3: Nenhum alarme é relatada na BTS Site Manager Passo 4: Sem alarme é relatada na NetAct Alarm monitor


CN-id: LN40_00044

Título: Inter-Vendor HO falha com habilitado RoHC



Referências:

Razão para a mudança Nota: Resumo do problema original: Inter-Vendor HO falha com habilitado RoHC

Como usuário final / operador podia detectar o problema: Silenciamento de chamadas VoLTE ocorrerá após a entrega devido a D / L de erro de descompressão e decodificação falhar.

Descrição da falha: Cálculo da diferença entre a configuração de origem e destino não foi devidamente implementado. O problema era que o nosso ENB não enviou PDCP-config a fonte, quando há houve diferença na configuração específica: por exemplo, ambos os eNBs, para o mesmo qci1, usado compressão de cabeçalho, mas com diferente rohcMaxCid.

Descrição da correção (análise de risco incluído): Comparação, de configuração de origem e destino da compressão de cabeçalho, leva agora em conta todos os parâmetros ROHC relacionados.

Efeitos sobre operador Depois de HO é excuted, chamada bloqueio ocorre pelo D / L de erro de descompressão e decodificação falhar.

Relatórios anomalia corrigida: NA05340039 [Inter-Vendor HO falha com habilitado RoHC


Componente UEC. -

Versão 129377


* SW-type -

* Unidade -









Pré-requisitos: VoLTE serviço está disponível. Fonte eNB & Target eNB deve ter valor diferente para o perfil RoHC e RoHC MaxCID Característica RoHC deve ser ligado a cada eNB

A execução do teste: 1.Make uma chamada VoLTE na fonte eNB (QCI1 portador será estabelecido) Função 2.RoHC será trabalhado para QCI1 portador 3.S1 ou X2 HO acionado para Alvo eNB

Resultados esperados: As informações PDCP-config (perfil RoHC & MaxCID) para QCI1 portador do alvo eNB devem ser enviadas para o eNB fonte durante a fase de execução Handover Depois de Handover, não há bloqueio de chamadas VoLTE no lado da UE.

Resultados inesperados: Após a entrega, não é silenciamento de chamadas VoLTE no lado da UE,


CN-id: LN40_00045

Título: Problema com LTE PS Handover para WCDMA



Referências:

Razão para a mudança Nota: Resumo do problema original: RAD_t304 estáticos utilizados em vez do operador T304InterRAT configurável

Como usuário final / operador podia detectar o problema: Duração do TS1RELOCOverall temporizador é calcualted erroneamente

Descrição da falha: Valor RAD de T304 (LTE) é usado para calcular TS1RELOCOverall para InterRAT Ho que é errado. Operador T304Interrat configurável é para ser utilizado para o cálculo de TS1RELOCOverall durante Interrat HO

Relacionadas característica / funcionalidade: Interrat HO para UTRAN (WCDMA / TDSCDMA)

Dependência de configuração: Duração do temporizador T304Interrat Operador configurado não mostrou qualquer efeito. Isto é corrigido agora

Solução: N / D

Descrição da correção (análise de risco incluído): TS1RELOCOverall Timer é calculado usando operador configurável temporizador T304Interrat valor. Não há risco

Efeitos sobre o usuário final: HO para UTRAN pode falhar devido de forma errada (provavelmente a muito curto), calculado TS1RELOCOverall cronômetro

Efeitos sobre a operadora: Interrat HO KPI pode ir para baixo


Componente defeituoso e versão: UEC

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): RL40

Relatórios anomalia corrigida: NA05319825 Problema com LTE PS Handover para WCDMA


Componente UEC. -







Versão 130348


* SW-type -

* Unidade -


Pré-requisitos: TS1RELOCOverall = T304interat + T301 + T311 + tS1RelOvDeltU ENB configurado para Entrega PS ativa para 3G Configure todos estes temporizadores para os menores valores e realizar HO e verifique se o HO vai falhou devido a TS1RELOCOverall expira Em seguida, aumente o valor dos T304interat = 5000ms ou mais

A execução do teste: Realize PS HO para 3G

Resultados esperados: Verificar que o HO será bem sucedida

Resultados inesperados: INTERAT HO vai falhou devido a expiração TS1RELOCOverall


CN-id: LN40_00046

Título: FSMr3-LTE1432-eNB queda observada em permitir que o tráfego de recurso de espelhamento.



Referências:

Razão para a mudança Nota: Resumo do problema original: Assim recurso foi ficando habilitar o eNB ia para reinicialização após alguns minutos.

Como usuário final / operador podia detectar o problema: Se o operador ativar esse recurso, então eNB irá falhar.

Descrição da falha: Tampão Kernel é acessado por ambos o original eo pacote copiado também.

Relacionadas característica / funcionalidade: LTE1432


Solução: Não

Descrição da correção (análise de risco incluído): Como parte da correcção fizemos bit 0 para o pacote copiados, de modo que ele não iria ler o mesmo a memória do kernel do pacote original.

Efeitos sobre o usuário final: No acidente será visível e recurso vai funcionar bem.

Efeitos sobre a operadora: No acidente será visível e recurso vai funcionar bem.

Efeitos do sistema: Não


Outros efeitos: Não

Efeitos de interface: Não

Componente defeituoso e versão: LN4.0 1,0 LN4.0_ENB_1202_753_00

Relatórios anomalia corrigida: 38487ESPE07 FSMr3-LTE1432-eNB queda observada em permitir que o tráfego de recurso de espelhamento.


Elemento líquido ComponentVersion * ltm_np_sikrishn_t FTM_LN40_ - rafficcrash.-MP1_334.00 .03







* SW-type -

* Unidade -


Pré-requisitos: O MAS apoia o espelhamento de sua entrada e saída IP tráfego, exceto avião usuário o tráfego na camada IP. O ponto de medição deve ser localizado após IPSec descriptografia (ingresso) resp. antes Criptografia IPSec (saída), ou seja, o tráfego espelhado é criptografado. O NE transmitirá os pacotes espelhados através da porta de Gestão Local. O avião usuário é excluído do tráfego integrado espelhamento devido ao desempenho restrições e considerações de segurança. O cabeçalho IP é mantida, mas os pacotes espelhados são encapsulados em novo Ethernet quadros. - A fonte MAC deve ser o endereço MAC da entidade LMP MEthernet MAC

Página 80


- O destino MAC deve ser configurável via comando CLI em secure shell Deve ser possível para executar simultaneamente uma sessão BTSSEM e tráfego integrado espelhamento através da BTS local Gestão Portuária. O espelhamento de tráfego integrado deve ser configurado através do comando CLI em shell seguro. As credenciais de acesso à shell seguro deve ser operador configurável. Operador tem permissão para configurar os parâmetros abaixo • Como ativar / desativar o espelhamento de tráfego • Destino endereço MAC • Timeout Timeout vai específico o tempo quanto tempo as necessidades de espelhamento de tráfego a ser feito

A execução do teste: 1.Instale o DUT como mostrado na configuração de teste. Estabeleça uma sessão de SEM para DUT. 2.Run o comando ". / Secfg_test iptest_enable_traffic_mirror_feature <DEST MAC endereço> <timeout em min> no DUT 3.Ligar a interface Ethernet do DUT para o IXIA ao lado TRS 4.Trigger o tráfego SCTP Downlink de IXIA e observar os logs de tubarão fio no PC / Laptop usando a interface LMP 5.Verify o endereço do pacote espelhado Fonte e Dest MAC 6.Check a ligação EM 7.Verify o tráfego 8.Repeat os passos 3-6 para o uplink SCTP, M-plano UL e DL tráfego e S- avião UL e DL 9.Try possibilitando a mirrioring tráfego com endereço mac inválido e tempo de espera 10.Configure o valor de timeout no 1m intervalo para 14 dias [1 .. 20160m] 11.Check a ordem dos pacotes de espelho 12.Disable o espelhamento de tráfego usando "/ Secfg_test iptest_disable_traffic_mirror_feature". 13.Send o tráfego GTP-u e verificar se o tráfego está espelhando 14.Repita os passos de 3 a 13 15.Repeat os passos de 3 a 13 16.Repeat os passos de 3 a 13 17.Send os pacotes de erro da UL e DL com inválido IP de destino ou porto de destino ou protocolo inválido 18.Send os pacotes SCTP 2000 + / -100 por segundo 19.Send a pacotes SCTP mais que 2000 + /-100per sec 20.Repeat os passos 14 a 16 com outro tráfego com limitação de taxa 21.Repeat todos os passos acima com IPsec 22.Repeat todos os passos acima, enviando todo o tipo de tráfego (SCTP.GTP, Mplane ...) a um tempo. 23.Repeat todos os passos acima por enviar o tráfego com todas as interfaces (FSM1.FSM2.FTIF1 4 e PDH as interfaces) 24.Send os pacotes fragmentados para DUT

Resultados esperados: 1.DUT está instalado e funcionando. 2.Command deve ser executado com sucesso e os valores devem ficar configurado com sucesso e não deve haver qualquer reposição exigida após a ativação O valor 00-00-00-00-00-00 não está autorizado a ser configurado. 3.n / a 4.Traffic deve ser espelhado com sucesso

5.Source deve ser o endereço LMP Mac e destino pode ser qualquer Mac abordar outro que 00-00-00-00-00-00 Conexão 6.EM não deve ter afetado 7.There não deve haver qualquer impacto sobre o tráfego 8.Results conforme as etapas 9.Should ser permitido 10.Traffic espelhamento deve ficar parado valor de tempo limite após configurado 11.Order dos pacotes espelhados deve ser o mesmo que os pacotes reais 12.No tráfego deve ser espelhado. E reinicialização não é necessária depois de desativar Tráfego 13.GTP-u não deve ser espelhado 14.Results de acordo com as etapas 15.Results de acordo com as etapas 16.Results de acordo com as etapas 17.O pacotes não deve ser espelhado 18.All os pacotes devem ser espelhado 19.Only os pacotes de 2000 + / -100 por segundo deve se espelhado (identificação utilização bandeira para a contagem) 20.Results de acordo com as etapas 21.Results de acordo com as etapas e os pacotes IPsec deve ser espelhado depois / antes descriptografia / criptografia. 22.Results de acordo com as etapas 23.Results de acordo com as etapas 24.Packets deve se espelhado depois remontar. Se o tamanho do pacote após a remontagem excede o tamanho MTU LMP, em seguida, a fragmentação deve ser realizada para pacote espelhado

Resultados inesperados: 1.DUT não está instalado e funcionando. Não 2.Command não executar com êxito e os valores não se configurou com sucesso 3.n / a 4.Traffic não é espelhado com sucesso 5.Source não é endereço LMP Mac 6.EM conexão é afetado 7.There é o impacto sobre o tráfego 8.Results conforme as etapas 9.it não permitidos 10.Traffic espelhamento não ficar parado valor de tempo limite após configurado 11.Order dos pacotes espelhados não são os mesmos que os pacotes reais 12.Traffic é espelhado. Tráfego 13.GTP-u é espelhado 14.Results de acordo com as etapas 15.Results de acordo com as etapas 16.Results de acordo com as etapas 17.O pacotes são espelhados 18.All os pacotes não precisam ser espelhado Resultados Esperados 19.See 20.Results de acordo com as etapas 21.Results de acordo com as etapas e os pacotes IPSEC não são espelhados depois / antes descriptografia / criptografia. 22.Results de acordo com as etapas 23.Results de acordo com as etapas 24.Packets não são espelhados depois remontar.


CN-id: LN40_00047

Título: [+ FSMr2 FSMr3] [LN4.0] AutoReboot após OnAir



Referências:

Razão para a mudança Nota: Resumo do problema original: AutoReboot após OnAir

Como usuário final / operador podia detectar o problema: Uma vez eNB veio Air, TRS foi para reset

Descrição da falha: CCN mensagem enviada no novo formato estendido foi manuseado incorretamente.

Relacionadas característica / funcionalidade: Conexão ASN.1


Solução: Nenhum

Descrição da correção (análise de risco incluído): Uso incorreto de ntohs e ntohl. Como resultado, a estrutura MesaageInfo era povoada com msglen incorretas. Corrigido com esse recurso.

Efeitos sobre o usuário final: Site irá repor

Relatórios anomalia corrigida: 41295ESPE05 [+ FSMr2 FSMr3] [LN4.0] AutoReboot após OnAir

Componentes de modificação: LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0 Página 83

Elemento líquido ComponentVersion * sma_ngo_41295FTM_LN40_ - espe05_asn1cras MP1_335.00 h_fix_ln40mp1 -. 0,02







* SW-type -

* Unidade -


Pré-requisitos: BTS está operando (OnAir).

A execução do teste: Download de Software com ativação por BTS Site Manager para nova construção (por exemplo LN4.0_ENB_1202_749_00).

Resultados esperados: Startup correta após o procedimento de download de software, eNB entra em estado OnAir, e é não caiu após 2 ou 3 minutos.

Resultados inesperados: Reinicialização automática do eNB após 2 ou 3 minutos da entrada em estado OnAir (PR 41295ESPE05).


CN-id: LN40_00048

Título: Alarme "Falha na interface do RP3 óptica (0010)" é acionado usando FSM eIF2 para RP3 interface e FTIF eIF3, 4 Sametime.



Referências:

Razão para a mudança Nota: Resumo do problema original: Este problema é semelhante ao PR NA05348560 que diz que LFS fez mudança cenário de sincronização de velocidade do link de 4x. Após a mudança HWAPI envia primeiro API_OPT_SYNC_IND (Off) e depois API_OPT_SYNC_IND (Frame) para BTSOM durante ajuste de tampão elástica. Código BTSOM (após LTE1542 implementação característica) tentou ligação re-sincronizar com cenário velocidade do link de 8x e alarmes desnecessários foram gerados. [Segunda questão] RP3-01 ligação por trás da interface de rádio RF6 em FSMF é resetado

Como usuário final / operador podia detectar o problema: Ao utilizar o FTM_EIF1/EIF3 e RF6 ao mesmo tempo

Descrição da falha: [Segunda edição] Interface FCTB EIF2/RF6 é a interface multiplexado entre ethernet e RP3-01. Além disso, o caminho ethernet (SGMII) do MCU pode ir tanto para esta interface compartilhada, ou para o FTIF_EIF3/FTIF_EIF1 (estes são portas combo). Este caminho é completamente configurada uma API. Esta API define ethernet a qualquer FTM ou à interface compartilhada. Se o caminho está definido para o FTM, a interface compartilhada é configurado como RP3. Se ethernet está definido para a interface compartilhada, RF6 não pode ser utilizado como portos e RP3 ethernet eIF3 / 1 em FTIF não pode ser utilizado. Quando o link S1 está em FTIF_EIF3/EIF1, TRSW (FTM) irá configurar este caminho, chamando ddal_mux_eth. Mas, se RF6 também está em uso, qualquer chamada para esta API, mesmo com o mesmo parâmetro, fará com redefinição de todos caminhos de dados incluído (RP3 para RF6, SGMII para FTM), que aconteceu neste caso. Sugestão foi TRSW ler primeiro estado deste multiplxer ethernet/rp3, depois para escrever, mas, este tinha falta desde LFS não ofereceu em seu estado API que mostra multiplexer não está configurado. Relacionadas característica / funcionalidade: LTE_RL40_1.0 Mudança Nota Formas

A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0 Página 85

LTE1542

Dependência de configuração: NÃO

Solução: Para usar FTM_EIF2/EIF4, FCT_EIF1

Descrição da correção (análise de risco incluído): LFS: rp3_link.c modificado. Ele deve fazer a configuração MURKKU2 mais segura, impedindo ocasionais 2016 alarmes. [Segunda questão] LFS estendido API, TRSW começou a usá-lo

BTSOM: Código BTSOM corrigido para que os cenários de ressincronização 4x foram adicionados de volta ao cenário de ajuste de atraso pi.

Evidência ação preventiva: 1.trunk/C_Test/OM_K3/src/host_tests/testcases/LBT1542-Ba casos de teste para ajuste de atraso pi com a velocidade de conexão 4x precisam ser atualizados quando BTSOM correção para o tronco é entregue ao SVN.

Efeitos sobre o usuário final: Sim

Efeitos sobre a operadora: Sim

Efeitos do sistema: Sim

Outros efeitos: Não

Efeitos de interface: Não

Componente defeituoso e versão: Não

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): FTM_LN40_MP1_334.00

Relatórios anomalia corrigida: 92204ESPE01 Alarme "Falha na interface do RP3 óptica (0010)" é acionado usando FSM eIF2 para RP3 interface e FTIF eIF3, 4 Sametime.


Elemento líquido ComponentVersion * FTM_LN40_ aricent_r3_na_dd - al.-MP1_334.00

* SW-type -

* Unidade -









Pré-requisitos: Ele testei com reencaminhamento IP rápido habilitado.

A execução do teste: Configurado o eNB com 1 FSMF +1 FTIF. Ativar FSM eIF2 como interface de RP3-01. Configure o IP rápido reencaminhamento em eNB. O PR (router primário) está ligado ao FSM EIF1. AR (Alternativa Router) está ligado a FTIF eIF3. 1.1 eNB está no ar. 1.2 desconectou o PR por desligamento da interface no roteador Cisco. O encaminhamento será comutada para AR. O celular ainda está no ar. 1.3 Ative a interface em FTIF EF4. 1.4 Desligue a AR em eIF3 e reconectá-lo para eIF4 rapidamente.

Resultados esperados: 1.No alarme PR3 é acionado. 2. Ao eNB alternado entre PA e AR, o eNB deve ser o ar e nenhum serviço foi impactados. (Passo 2) 3. The eNB pode ser restaurado quando ambos AR e PR desligado e ligado novamente. (step4)

Resultados inesperados: 1. Alarme RP3 foi desencadeada antes desta pronto foi corrigido. 2. Às vezes, o status do eNB ainda está em "BTS configurados" depois que o alarme foi RP3 apuradas antes desta pronto foi fixado, mas podemos fazer chamadas nesta célula.


CN-id: LN40_00049

Título: PM arquivos não são compactados em eNB e por isso não coletados em IOMS



Referências:

Razão para a mudança Nota: Resumo do problema original: Operador notado PM FTP conexão falhou alarme e esporadicamente falta de PM contadores.

Como usuário final / operador podia detectar o problema: Falta de PM contadores em IOMS / NetAct, 7100 (ligação PM FTP falhou) alarme IOMS / NetAct.

Descrição da falha: Se BTSOM está comprimindo arquivos PM durante o tempo, quando outro processo estava escrevendo para flash-lo teve que esperar até esta operação estiver concluída. Em alguns casos (por exemplo, arquivos grandes SCF ou atualização SW) escrita levou mais de 30 segundos, o que leva ao tempo limite em BTSOM.

Solução: Comprimir PM arquivos manualmente em eNB.

Descrição da correção (análise de risco incluído): BTSOM vai escrever PM arquivos diretamente para a memória RAM usando método diferente, por isso não vai ter que esperar se a escrita simultânea de flash está em curso.

Efeitos sobre a operadora: Contadores PM pode ser esporadicamente perdido.

Relatórios anomalia corrigida: NA05344350 PM arquivos não são compactados em eNB e por isso não coletados em IOMS



Componente PM.sbs Makefile. -







Versão 209406 209406


* SW-type - -

* Unidade - -


Pré-requisitos: eNB instalado e funcionando com grande arquivo SCF (mais de 600KB)

A execução do teste: BTS contínuos recolocar operação.

Resultados esperados: Todos os arquivos são compactados PM.

Resultados inesperados: Nem todos os arquivos são compactados PM.


CN-id: LN40_00050

Título: [LNT3.0] detecção FSP3 falhou quando BTS startup



Referências:

Razão para a mudança Nota: Resumo do problema original: Inicialização RapidIO durante a inicialização falha. Unidade directio / campainha não será habilitado. Download de software para placas FSP falhar.

Como usuário final / operador podia detectar o problema: O FSP não iniciar.

Descrição da falha: Questão inicialização RapidIO. Silicon às vezes não é rdy e precisa reiniitialization faltando com o novo sincronismo.

Relacionadas característica / funcionalidade: LFS - Linux de kernel (src-kernelsources)


Solução: Nenhum

Descrição da correção (análise de risco incluído): Questão ainda pode ocorrer em outras tábuas.

Efeitos sobre o usuário final: Precisa atualizar sistema


Relatórios anomalia corrigida: 90367ESPE01 [LNT3.0] detecção FSP3 falhou quando BTS startup








Impacto para o Cliente 90367ESPE01: Manutenção Operação e Inicialização BTS falhar devido a FSP redefinição

Versão -


* SW-type -

* Unidade -


Pré-requisitos: Não há caso de teste para isso, apenas durante a inicialização do FSP inicialização falhou

A execução do teste: BTS reinicialização a frio

Resultados esperados: FSP detectado

Resultados inesperados: O FSP não começar


CN-id: LN40_00051

Título: ETR-000051875: Depois de muitas tentativas no campo e no escritório, temos o seguinte observações: - O local para o Avanço obter resultados satisfatórios THR 55 - 60Mbps DL / UL 40Mbps (UDP e transmissão TCP) BT11446 Versão do SW-build: LN4.0_ENB_1202_780_10


Referências:

Razão para a mudança Nota: Resumo do problema original: Os usuários finais se queixou de baixo rendimento DL (cerca de 5 milhões); UL não sofreu. Uma vez que sítio foi redefinir o problema foi cancelado e não aparecer por algum tempo. Quando a fragmentação estava desligado, ajustando o MTU o problema não ocorreu. A situação era provocada pelo envio de tráfego UDP tempestade, com alta taxa de cerca de 190 M para eNB.

Como usuário final / operador podia detectar o problema: Configure eNB com unidade FTLB MTU configurado em 1500 em toda a rede (provoca pacotes DL a ser fragmentado) Enviar UDP Storm (~ 200 Mbps ou mais) para eNB Execute o teste de transferência TCP, observar rendimento TCP

Descrição da falha: A tabela a remontagem não foi liberado completamente, causando queda de rendimento devido ao TCP falha remontagem. Isto resultou em retransmissões de TCP e, eventualmente devido ao fluxo TCP controle, a vazão reduzida.

Relacionadas característica / funcionalidade: Fragmentação

Dependência de configuração: Problema só com unidade FTLB e tráfego DL GTPU fragmentado

Solução: Turn of fragmentação ajustando MTU

Descrição da correção (análise de risco incluído):


Devido ao uso inconsistente do tamanho da tabela hash na OCTEON SDK, a compensação de tabela hash foram não concluído. A entrada alocados em tabela hash estava usando 16K como o tamanho eo uso bitmap estava usando 64K tamanho que resultou em entradas não sendo apagada que eventualmente resultou em gotas em FTLB. O tamanho de hash é definida para 64K e da implementação é feita consistente para usar um único macro em vez de valores rígidos codificados em OCTEON SDK.

Efeitos sobre o usuário final: Baixo rendimento DL

Efeitos sobre a operadora: Não pode atender SLA


Componente defeituoso e versão: LN3.0_ENB_1103_930_39

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD):

Relatórios anomalia corrigida: NA05329849 ETR-000051875: Depois de muitas tentativas no campo e no escritório, temos o seguinte observações: - O local para o Avanço obter resultados satisfatórios THR 55 - 60Mbps DL / UL 40Mbps (UDP e transmissão TCP) BT11446 AL. Wilanowska muito


Elemento líquido ComponentVersion * lte_rla_np_na053 FTM_LN40_ - 29849_oct_reass MP1_330.00 _hash_size_fix_ln .02 40_mp1. -






Impacto para o Cliente Usuário Qualidade Plane

* SW-type -

* Unidade -


Pré-requisitos: 1. ENodeB no ar 2 .. S1 MTU 1500 -> forçando fragmentação no S1 3. UE ligado

A execução do teste: . * 1 iniciar a transferência de dados TCP (resultado esperado: nenhuma degradação do tráfego, taxa de transferência limitada apenas pela capacidade de interface aérea) 2. Parar a transferência de dados TCP 3. Iniciar iperf tempestade UDP (iperf-c 10.34.185.182-P 1-u-l 1500-I 1-fk-b1000m-t 60 - T 1) 4. Manter tempestade ativa por 1 min 5. Parar tempestade UDP . 6 iniciar a transferência de dados TCP -> resultado esperado deve corresponder ao valor antes da tempestade TCP

Resultados esperados: Resultado esperado deve corresponder ao valor antes da tempestade TCP

Resultados inesperados: TCP estrangulada significativamente a <10 Mbit / s -> recuperação apenas através de reset eNodeB

CN-id: LN40_00052

Título: FTM reiniciado devido a falha de SW (SmaAsn1is terminado)



Referências:

Razão para a mudança Nota: Resumo do problema original: - Processo SmaAsn1 rescindido resultando em unidade de reinício.

Como usuário final / operador podia detectar o problema: - Redefinição de unidade autônoma

Descrição da falha: - FTM reiniciado devido a falha de SW (processo SmaFileTransfer é encerrada) com diferentes causa

Relacionadas característica / funcionalidade: - Interface para ASN1 OMS. - Restart Unit


Solução: Nenhum

Descrição da correção (análise de risco incluído):

Codificação e decodificação funções de bibliotecas AsnGeneric não foram thred resultante seguro em ths cenário. Como parte da solução, ambas as funções de codificação e decodificação são protegidos com semáforo como eles usam variáveis globais.

Efeitos sobre o usuário final: eNB sai do ar devido a unidade de reset

Efeitos sobre a operadora: eNB sai do ar devido a unidade de reset

Efeitos do sistema: eNB sai do ar devido a unidade de reset


Outros efeitos: n / a

Efeitos de interface: Conectividade de Gestão é perdido devido à unidade de reset

Relatórios anomalia corrigida: NA05338815 FTM reiniciado devido a falha de SW (SmaAsn1is terminado)


Elemento líquido ComponentVersion * lte_sribandi_na05 FTM_LN40_ - 338815_smaasn1 MP1_332.00 _fix -. 0,02







* SW-type -

* Unidade -


Pré-requisitos: Integrar o eNB a alguma execução NetAct / IOMS

A execução do teste: Tente iniciar algumas operações OAM relacionados em paralelo (SWM, CM, FM, PM, HWM) para o alvo eNB

Resultados esperados: eNB funcionando sem qualquer 71058 - NE alarme falha OAM de IOMS

Resultados inesperados: eNB foi redefinida com a ação de recuperação para a perda de módulo FTM com causa intitulado.


CN-id: LN40_00053

Título: Nenhuma chamada possível após MME interrupção recuperado



Referências:

Razão para a mudança Nota: Resumo do problema original: Após acidente de um dos MME em uma rede eNBs NSN ter perdido a capacidade de se comunicar em todos os links S1 permanentemente (até eNB Reset).

Como usuário final / operador podia detectar o problema: Inoperáveis NSN eNBs após a restauração caiu MME.

Descrição da falha: Devido ao bug no módulo SCTP kernel do Linux em determinadas condições (falta de dados confirmação do outro lado) soquete para tampão poderia ter sido completamente preenchido bloquear indefinidamente todo o tráfego na tomada e tornar impossível para fechar com defeito associação graciosamente. Camada superior (TUPc SW) nunca foi informado sobre descrito problema desde SCTP estava considerando todas as associações no soquete como vivo (SCTP dados de controlo são enviados sem usar o tampão). Além disso, esse ponto deve ser revisto e atualizado pelo IFT.

Dependência de configuração: Nenhum.

Solução: Redefinir de preso eNB.

Descrição da correção (análise de risco incluído): Soluções em software de controle: - Em caso de detecção de sintomas do problema na comunicação S1 depois de algum tempo tudo Comunicação S1 é ungracefully redefinir, - No caso de o outro lado da ligação não reconhece uma tentativa de ligação desligamento durante um certo tempo de ligação é fechada com força


Relatórios anomalia corrigida: NA05338687 Nenhuma chamada possível após MME interrupção recuperado



Componente TUPc. -







Versão r132788


* SW-type -

* Unidade -


Pré-requisitos: eNB configurado para usar dois MME diferentes.

A execução do teste: Shutdown uma MME e manter viva a segunda.

Resultados esperados: As chamadas podem ser feitas via restante MME.

Resultados inesperados: As chamadas são caiu com tanto MME. eNB e MME precisa ser reiniciado, a fim de manter o processamento de chamadas novamente.


LTE IOMS

CN-id: LN40_00054

Título: Alinhamento de alarme "falha de conexão da camada de transporte na interface do X2" / muitos



Referências:

Razão para a mudança Nota: Resumo do problema original: Falhas foram desnecessariamente elevado para SCTP pares abort cenários de colegas X2 Como usuário final / operador podia detectar o problema: Há dois casos de alternar os alarmes: O alarme com seqüências alternando distâncias de tempo de 130 e O alarme com seqüências alternando distâncias de tempo de 9s Ambos os casos aparecem durante a instalação SCTP associação para um estabelecimento de conexão X2. Dois temporizadores são para ser considerados neste contexto - ambos são iniciados ao mesmo tempo, no início do processo de instalação associação SCTP: o procedimento endpoint SCTP temporizador (parâmetro codificado): - valor Hardcoded = 121s - Start: SCTP assoc. Iniciar a configuração - Stop: procedimento de configuração SCTP concluída - Validade: indica que o procedimento de configuração SCTP não foi concluída e alarme e X2 é levantado o maxTimeSctpSetup temporizador (parâmetro configurável) - Valor padrão = 130 - Start: SCTP assoc. Iniciar a configuração - Stop: SCTP conclusão configuração com bom resultado (ou compensação do contexto SCTP desencadeado por outros eventos) - Validade: desencadeia a exclusão do contexto SCTP e, portanto, a compensação de todos os alarmes associada a este contexto

Descrição da falha: Explicação: 9s alarme alternando caso: o Ocorre no caso de a instalação associação SCTP não recebe qualquer resposta do alvo eNB (isto é, sem abortar recebido). o Sequência de eventos é a seguinte:


- MaxTimeSctpSetup temporizador e SCTP procedimento endpoint temporizador são iniciados ao mesmo tempo - Sem resposta recebida do endpoint SCTP remoto - Endpoint SCTP proc. timer expirar após 121s -> alarme X2 é levantada - 9s mais tarde os 130S temporizador maxTimeSctpSetup expira -> alarme X2 está desmarcada (como SCTP contexto é excluído) Explicação: 130 alarme alternando caso: o Ocorre no caso de a instalação associação SCTP é encerrado com um ABORT SCTP de o alvo eNB. o Sequência de eventos é a seguinte: - MaxTimeSctpSetup temporizador e SCTP procedimento endpoint temporizador são iniciados ao mesmo tempo - SCTP ABORT recebeu imediatamente (<1s depois) de eNB alvo -> endpoint SCTP procedimento cronômetro é parado -> nenhum alarme X2 é levantada - 9s mais tarde os 130S temporizador maxTimeSctpSetup expira -> alarme X2 está desmarcada (como SCTP contexto é excluído) - Alarme persiste até maxTimeSctpSetup 130 temporizador de validade e é então apagado no termo (Temporizador não é relevante para OAM controlado associação SCTP!). (121s temporizador também é iniciado mas é eliminado no recebimento do ABORT) Solução: Mude temporizador maxTimeSctpSetup a 100s (solução para 9s alternando caso apenas) Aplique alternando a prevenção como solução (para 130 apenas alternando caso)

Descrição da correção (análise de risco incluído): Modificação SW que remove o alarme X2 completamente para o caso SCTP ANULAR Efeitos sobre a operadora: Alarme levantou para SCTP pares abort

Relatórios anomalia corrigida: NA05331783 Alinhamento de alarme "falha de conexão da camada de transporte na interface do X2" / muitos


Componente LTE_CP_3360. - LTE_CP_7115. - LTE_CP_2480. - LTE_CP_7376. - TUPc. -






Versão 14,3 4.1 6.5 6.1 132087

* Elemento líquida - - - - -

* SW-type - - - - -

* Unidade - - - - -




Pré-requisitos:

Nota: A correção fornecido só pode ser testada quando SW instalado no campo.

ANR recurso base totalmente UE vez na origem e destino eNB. Destino eNB já atingiu o número máximo de conexões X2 ativos autorizados a vizinho eNB do. Origem e destino eNB não têm relações X2.

A execução do teste: Faça totalmente UE entrega ANR de base da origem ao destino eNB

Resultados esperados: Porque o número máximo de relações X2 ativas no destino eNB já foi excedido, não é possível estabelecer nova relação. SCTP abort é enviado do destino para a fonte eNB. "Falha de conexão da camada de transporte na interface do X2" alarme não deve ser visível na fonte eNB

Resultados inesperados: "Falha de conexão da camada de transporte na interface do X2" alarme deve estar visível na fonte eNB


CN-id: LN40_00055

Título: "Certificado Vendedor falta"



Referências:

Razão para a mudança Nota: Resumo do problema original: FILHO com unidade FTLB não foi bem sucedido como o pedido do CMP não conseguiu receber do operador certificado.

Como usuário final / operador podia detectar o problema: No julgamento do cliente, FILHO com unidade FTLB falhou devido a chave vendedor era corrupto.

Descrição da falha: FILHO não foi bem sucedido como o pedido do CMP não conseguiu receber certificado de operador. A razão para a falha de certificado de operador atraente era que a chave privada fornecedor foi corrompido devido pedido de inicialização que não era bem sucedida.

Relacionadas característica / funcionalidade: Gerenciamento de Certificados Solução: N / A

Descrição da correção (análise de risco incluído): Melhoria é feito para extrair as credenciais do fornecedor dos arquivo PKCS # 12 e verificação da mesma por várias vezes, se não para a primeira vez. se a extração de PKCS # 12 arquivo ou verificação de fornecedor credencial falhou por duas vezes o arquivo PKCS # 12 é mantida por renomear o arquivo para vendorcertkeyFaulty.p12 em / var / log dir. Também as entradas de log de P & D para cenários de erro são feitas.

Efeitos sobre a operadora: O operador pode resolver se algum erro acontecer como o arquivo PKCS # 12 é renomeado e retidos.

Componente defeituoso e versão: FTM_LN40_MP1_330.00

Relatórios anomalia corrigida: NA05338446 "Certificado Vendedor falta"




Elemento líquido ComponentVersion * WBTS_SEC_468 3 - 25. - lte_ssu_na05338 FTM_LN40_ - 446_vendor_cred MP1_334.00 ential_parse_mp1 .02 . -

* SW-type -

-

* Unidade -

-








Pré-requisitos: Armazenado a imagem flash de uma unidade que nunca foi afirmado com CSW.

A execução do teste: A) inicializar a unidade e, a mensagem "Task Manager: O cartão está pronto" Desliguei o poder B) reiniciar o aparelho e verifique a cert C) reiniciar o aparelho e começar pTSW para colocar o Imageon produção armazenada na unidade. D) à partir de A)

Resultados esperados: FILHO com unidade FTLB foi bem sucedido como CMP pedido sucesso para receber operador certificado.

Resultados inesperados: FILHO com unidade FTLB falhou devido a chave do fornecedor é corrupto.


CN-id: LN40_00056

Título: Celular Volte ROHC CRC falhar



Referências:

Razão para a mudança Nota: Resumo do problema original: Quando RoHC está habilitado e pacotes IP contêm bandeira DF definir o Ue vai descartar pacotes de VoIP como a descompressão falha.

Descrição da falha A razão direta do problema foi uma maneira incorreta em que eNB verificada a bandeira DF durante a geração do pacote UOR2-ext3 (Bit incorreto do cabeçalho do pacote IP foi marcada). Isso levou a uma situação que eNB pensou que a bandeira DF no pacote IP é OFF e definir o bandeira correspondente no pacote UOR2-ext3 também como 0. Mas a bandeira DF no pacote IP foi realmente definir ON e isso se refletiu em UOR2-ext3 packet CRC. Em resultado, a UE viu um cabeçalho do pacote IP incorreto após a descompressão (sem DF bit definido) e verificação CRC falhou. Como usuário final / operador podia detectar o problema: O efeito foi visível quando o pacote IP original tinha o 'DF' set ON. No caso quando o bandeira era OFF e o campo fragment_offset no cabeçalho IP é 0 então bug não manifesto.

Relacionadas característica / funcionalidade: RoHC Dependência de configuração: RoHC habilitado Solução: RoHC desativado, não usando a bandeira DF em gerador de dados de teste em direção DL. Descrição da correção (análise de risco incluído): Manuseio bandeira DF. Risco Marginal. Efeitos sobre o usuário final: Pior ou nenhuma transmissão de Voip. Efeitos sobre a operadora: Pior ou nenhuma transmissão de Voip. Efeitos do sistema: N / D

Página 104


Outros efeitos: Sem efeitos. Efeitos de interface: Sem efeitos.

Relatórios anomalia corrigida: NA05352288 Celular Volte ROHC CRC falhar


Componente Tupu. -







Versão 29473


* SW-type -

* Unidade -


Pré-requisitos: 1.O serviço VoLTE está disponível na parte de rádio e Núcleo parte 2.Both UE e eNB suportam a função RoHC para a chamada VoLTE (QCI1 portador) 3.A função RoHC deve seguir a especificação RFC3095.

A execução do teste: 4.Make uma chamada VoLTE e verifique se a função RoHC funciona corretamente no QCI1 portador ou não 5.Create um pacote UOR-2-Ext3 comprimido no lado do eNB na direcção descendente. : A criação de UOR-2-Ext3 é muito difícil de criar, manualmente, ele é raramente aconteceu no caso do processo Handover ou caso Restabelecimento

Resultados esperados: Este pacote UOR-2-Ext3 serão descompactados corretamente e não descartados por falha CRC no lado do UE.


Resultados inesperados: Existe um pacote de erro no lado do UE para este pacote UOR-2-Ext3 devido cálculo CRC falha no lado da UE.


CN-id: LN40_00057

Título: DL LTE rendimento com RL40 menor do que o esperado



Referências:

Razão para a mudança Nota: Resumo do problema original: Rendimento DL FTP é degradada devido a atrasos no retorno UL TCP. Como usuário final / operador podia detectar o problema: reduziu o rendimento DL FTP Descrição da falha: O recurso LTE815 proativa agendamento UL deve agendar uma UE em cada TTI em um células de outro modo vazio para melhorar a latência de tráfego UL, neste caso esp para RLC e TCP feedback para o tráfego DL FTP. Em certos casos, quando o estado do buffer UL do UE mudou de cheia para esvaziar isso não funcionar, correcty e as lacunas de alguns ms ocorreram no Agendamento UL. Isso levou a atrasar no retorno para o tráfego TCP DL FTP, que reduziu o rendimento DL. Relacionadas característica / funcionalidade: LTE815 proativa agendamento UL Dependência de configuração: Só ocorre quando LTE815 proativa agendamento UL está habilitado Solução: Nenhum Descrição da correção (análise de risco incluído): Altere a condição quando uma UE serão agendadas de forma proativa em PUSCH para que UEs para que todos os dados conhecidos no buffer foi agendada, mas não BSR = 0 foi recebido, não estão excluídas. Efeitos sobre o usuário final: Melhor rendimento DL FTP.

Relatórios anomalia corrigida: NA05346724 DL LTE rendimento com RL40 menor do que o esperado


Componente fb12.2


Versão r275999


* SW-type -

* Unidade -

APROVADO 2.0 Page 107








Pré-requisitos: PC com windows7 está conectado via LTE UE para NSN eNB.

A execução do teste: Os arquivos são transferidos em DL para o PC via NSN LTE eNB.

Resultados esperados: A taxa de transferência DL FTP é melhor ou, pelo menos, o mesmo que antes desta correção.

Resultados inesperados: A taxa de transferência DL FTP é pior do que antes desta correção.


CN-id: LN40_00058

Título: Samsung Galluxy S3 que apoiou Banda Single (5) inter-Frequency HO de 2,1 g de Fracasso 850M



Referências:

Razão para a mudança Nota: Resumo do problema original: No caso de Samsung Galluxy S3 que apoiou Único Band (5) inter-Frequency HO de 2,1 g de 850M Failure.

Patch foi feito para resolver uma falha na implementação UE. Existem alguns UE de uma firmware corrompido e estes UE são capazes de entrar em uma célula, o que configurou banda foi realmente não suportado mas estes UE de. Se tal UE introduzir um celular e rádio não é suportado condições pioraram e UE informa sobre um InterFreq vizinho começa eNodeB procedimento de entrega de celular relatados. Mas UE não poderia realizar tal transferência e vai dormir por um longo tempo.

Como usuário final / operador podia detectar o problema: Banda Single (5) inter-Frequency HO de 2,1 g de 850M Failure

Descrição da falha: Uma avaria eNodeB. Falha é original ao lado UE, mas de patching UE pede interação com o usuário e assim por CPlane deve fornecer uma solução para remendar essa falha UE. Motivo da falha é que UE introduzir em uma cela com um earfcn configurados, que não é suportado de UE e gatilho depois de um InterFreq / interband entrega, que é abortada

Solução: n / a

Descrição da correção (análise de risco incluído):. Correção funciona dessa forma para desativar para tal da UE a possibilidade de InterFreq / interband e InterRat entrega. Patch funciona dessa forma, se entrar em tal UE em uma célula, medições adicionais (InterFreq, WCDMA e Geran) não será ativado em condições de rádio de casos tornam-se pior. Tal UE puderam ser identificados, se a banda de earfcn celular não é suportado no ue capacidades de rádio eutra.

Efeitos sobre o usuário final: InterFreq / interband entrega é abortada

Relatórios anomalia corrigida: NA05355368


Samsung Galluxy S3 que apoiou Banda Single (5) inter-Frequency HO de 2,1 g de Fracasso 850M


ComponentVersion UecUeContextDa 135921 ta.hpp UecMeasConfigu 135921 rator.cpp








Pré-requisitos: 1.O carrinho UE (Samsung Gallaxy S3) suporta apenas Band5 frequência, mas esta UE é também capaz de adido e configurar a chamada no Band1 devido a um bug de UE. 2.O eNB & EPC estão funcionando corretamente


-

* SW-type -

-

* Unidade -

-

A execução do teste: 1.Attaché este UE sobre a Banda 5 de celular eNB, depois de expirado de inatividade do usuário timer, e este UE irá selecionar a Banda 1 celular. 2.Make Chamada na Banda 1 celular 3.Please verificar se este UE envia o relatório de medição do evento A2 para a inter- Frequência HO quando Banda 1 celular e Banda 5 Atenuação celular é alterada

Resultados esperados: A UE não deve enviar o relatório de medição para o evento A2 para a inter-frequência HO. assim Inter-freqüência HO não aconteceu para este UE buggy.

Resultados inesperados: A UE envia o relatório de medição para a A2 evento para o inter-freqüência e HO Inter-freqüência HO será aconteceu.


CN-id: LN40_00059

Título: Configuração incompleta que Resource celular arquivo incompatibilidade comissionamento logo após célula eliminação



Referências:

Razão para a mudança Nota: Resumo do problema original: configuração incompleta que Resource celular incompatibilidade comissionamento arquivo logo após a eliminação de células Como usuário final / operador podia detectar o problema: Configuração incompleta que Resource celular arquivo incompatibilidade comissionamento logo após célula eliminação quando o cliente remover um módulo de rádio, e fazer recomissionamento. Descrição da falha: A célula correta em SCF (célula 5) está em falta no comissionamento assistente-Local Resource celular página. Relacionadas característica / funcionalidade: Comissionamento-Local Resource celular Dependência de configuração: Qualquer configuração Solução: Se o usuário não usa recomissionamento, mas use comissionamento manual ou usuário não remover o módulo de rádio. Descrição da correção (análise de risco incluído): Correção na nossa SEM ler SCF codeSee forma de correção pronto

Relatórios anomalia corrigida: NA05356669 Configuração incompleta que Resource celular arquivo incompatibilidade comissionamento logo após célula eliminação


Componente fdltebtsmanager.j ar


Versão LN4.0


* SW-type -

* Unidade -









Pré-requisitos: Configure eNB com alguns módulos de RF (seria melhor usar FSME RP3-01 1/2/3/5) e configurar células

A execução do teste: Desligue o porta óptica para RP3-01 2 Tente modificar algum parâmetro célula relacionada via BTSSM

Resultados esperados: BTSSM poderia preservou os parâmetros de configuração / operação para módulos de RF ligado a RP3-01 3/5

Resultados inesperados: BTSSM pode pode perder os parâmetros de configuração / operação para módulos de RF ligado a RP3-01 3/5


CN-id: LN40_00060

Título: Falha na relação RP3 óptico Alarme devido a FPGA pino de reset capacitância parasítica



Referências:

Razão para a mudança Nota: Resumo do problema original: Suspeitou-se que keepalive reinicialização ocorre na Coreia foi causada por OBSAI FPGA repostas.

Como usuário final / operador podia detectar o problema: Se a suspeita estava correta este problema poderia maiúsculas resets Keepalive.

Descrição da falha: O pino de reset para OBSAI FPGA era suspeito de ser instável.

Relacionadas característica / funcionalidade: Dependência de configuração: Solução: Descrição da correção (análise de risco incluído): Um pull-up foi feito em OBSAI FPGA para garantir pino de reset não causou resets inesperados de OBSAI FPGA. O risco é baixo, não há nenhuma mudança na funcionalidade OBSAI FPGA.

Relatórios anomalia corrigida: 40184ESPE05 Falha na relação RP3 óptico Alarme devido a FPGA pino de reset capacitância parasítica


Componente FRRH4-SW. -





Versão 0407707


* SW-type -

* Unidade -






Pré-requisitos: FHCA está em OnAir

A execução do teste: Deixar FHCA após o arranque de um longo período de tempo. Garantir que não haja auto-resets ocorrer.

Resultados esperados: FHCA continua a funcionar correctamente sem qualquer alarme RP3

Resultados inesperados: FHCA tem keepalive auto-reset e RP3 alarme


CN-id: LN40_00061

Título: FLDA (MHA) não é encomendado após o bloqueio BTS / desbloquear



Referências:

Razão para a mudança Nota: Resumo do problema original: FLDA (Mha) dados adicionais foi modificado durante a re-comissionamento e BTS reiniciado devido para isso. Após o arranque BTS FLDA MHA não foi encomendado mais, porque FLDA número ProductCode foi alterado e BTS O & M detectado FLDA depois como MHA novo. Como usuário final / operador podia detectar o problema: FLDA MHA não foi encomendado. Descrição da falha: FLDA MHA sw permitida a modificação do código do produto que nunca deve ser acontecer. Solução: N / D Descrição da correção (análise de risco incluído): Nova FLDA sw firmware, informações de código do produto é protegido e não pode ser alterado no quaisquer circunstâncias. Efeitos sobre a operadora: MHA não está a ser utilizada pelo sistema.

Relatórios anomalia corrigida: 90110ESPE01 FLDA (MHA) não é encomendado após o bloqueio BTS / desbloquear


Componente FLDA. -



Efeitos sobre Operador LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL

Versão 101


* SW-type -

* Unidade -


N / D





Pré-requisitos: BTS é comissionado com FLDA MHA

A execução do teste: Re-comissionamento está started.MHA dados adicionais são alteradas. (Número do modelo da antena, antena número de série)

Resultados esperados: Após reiniciar BTS MHA é comissionado e funcionando corretamente

Resultados inesperados: Após BTS redefinir MHA é detectado como um novo MHA. E tem de ser encomendado novamente para BTS


CN-id: LN40_00062

Título: Falha Tx incorreta no MIMO visto em alguns RL40 0.0.3 eNBs



Referências:

Razão para a mudança Nota: Resumo do problema original: 0x7655 alarme desnecessário para falhas em 4003 Bloqueio / Desbloqueio de FR com celular que tem todos os recursos nele Como usuário final / operador podia detectar o problema: fazendo bloqueio / desbloqueio de FR em configuração onde célula é apenas neste FR Descrição da falha: o tempo de filtragem por culpa 4003 Iniciar na seção FddC em FlexiFDrules.xml, não funcionou tão Iniciar 4003 foi enviado para Site Manager de imediato, mas em vez disso, deve esperar causa, nesta situação, deve ser cancelado em 4003 por FM Cancelar Recurso relacionado / funcionalidade: a funcionalidade MIMO Dependência de configuração: a dependência de configuração MIMO Solução alternativa: nenhum Descrição da correção (análise de risco incluído): tempo de filtragem passou de FddC (onde não funcionou) para a seção FDU em FlexiFDrules.xml Efeitos sobre o usuário final: nenhum Efeitos sobre a operadora: 0x7655 alarme desnecessário para falhas 4003, bloqueando o FR Componente defeituoso e versão: FlexiFDrules.xml

Relatórios anomalia corrigida: NA05360584 Falha Tx incorreta no MIMO visto em alguns RL40 0.0.3 eNBs






Outros efeitos LTE_RL40_1.0 Mudança Nota Formas A Nokia Siemens Networks © CONFIDENCIAL

Versão 212415


* SW-type -

* Unidade -


N / D




Pré-requisitos: Configure o modo de eNB com o G-Type, módulos de rádio I-Tipo, autônomo e acorrentado

A execução do teste: Bloqueio / Desbloqueio alguns Módulo Rádio, ciclo de energia alguns Módulo Rádio, Disrupt óptica cabo em direção a algum módulo de rádio

Resultados esperados: Não observamos nenhum 4.003 falhas de módulos de rádio I-Type G-Type e interrompendo os serviços prestados

Resultados inesperados: Podemos observar algumas falhas de 4003 G-Type e I-Tipo de módulos de rádio por interromper os serviços prestados


CN-id: LN40_00063

Título: FSMF projeto cedo: LTE83: FSMF - Teste Negativo (alarme Fan) - teste falhou



Referências:

Razão para a mudança Nota: Resumo do problema original: Alarme 4073 não apaga mesmo que não há mais condição defeituosa. Como usuário final / operador podia detectar o problema: Alarme 4073 ainda visíveis em MEV após condição de falha foi removida. Descrição da falha: Alarme não pode ser cancelado por causa de falhas 4073 foi levantada durante a partida e teve texto culpa adicional, que não estava presente em caso de falha 4073 cancelar. Por causa da falha correspondência, alarme cancelar não pôde ser enviada.

Relacionadas característica / funcionalidade: FDAR Dependência de configuração: nenhum Solução: nenhum Descrição da correção (análise de risco incluído): Ao cancelar o alarme que se originou de culpa grupo 3050, exceção é adicionado não comparar texto de alarme quando se tenta encontrar combinando uma.

Efeitos sobre o usuário final: nenhum Efeitos sobre a operadora: Alarme 4073 ainda visíveis em MEV após condição de falha foi removida.




Relatórios anomalia corrigida: NA05353417 FSMF projeto cedo: LTE83: FSMF - Teste Negativo (alarme Fan) - teste falhou

Página 119



ComponentVersion CFansManager.cl 211311 s CFansDetector.cl 211311 s AlarmNormal.cpp 212681








-

-

* SW-type -

-

-

* Unidade -

-

-


Pré-requisitos: HW: FSMF

A execução do teste: 1.Power fora das BTS 2.Block fãs 3.Power na BTS (alarme ventilador (4073) vai subir) 4.Unblock fãs 5.Wait 1 hora

Resultados esperados: 60 minutos após o desbloqueio dos alarmes fãs são cessado

Resultados inesperados: 60 minutos após o desbloqueio fãs alarmes ainda são visíveis


CN-id: LN40_00064

Título: RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente. BTS reset é necessário



Referências:

Razão para a mudança Nota: Resumo do problema original: Problema ocorreu em determinados cenários, quando o pedido de instalação X2 vinha eNB que foi marcado como indisponível. Este erro causado em eNB que foi levando à insuficiência durante provisão plano.

Como usuário final / operador podia detectar o problema: Provisioning falhou com o seguinte erro na NetAct: PLMN-PLMN/MRBTS-100776 NY1069_Hofheim-1_63100776_C Ativação do plano de operação Plano failed.RNW falhou devido a um problema interno e BTS é estado inconsistente.

Descrição da falha: Do ponto de vista técnico, C-Plane rrom ficar preso em estado especial chamado ErrorState (rrom não terminou reconfiguração). Em CPlane rrom construir uma mensagem com o conteúdo errado ENBC que bloqueou a todo eNB

Relacionadas característica / funcionalidade: LTE782d

Dependência de configuração: Nenhuma dependência conhecido na configuração

Solução: Não workaraound conhecido

Descrição da correção (análise de risco incluído): Quando exclusão LNADJ linha ocorrer, rrom atualiza corretamente os dados internos que são utilizados construir mensagem para ENBC. Registros adicionais foram criar para fornecer informações aos NetAct sobre o reinício da BTS e razão por trás estado de erro de rrom que pode ser dirigida apenas por restart


Efeitos sobre a operadora:


RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente.

Efeitos do sistema: Sem efeitos do sistema.

Outros efeitos: Nenhum outro efeito.

Efeitos de interface: Informações mais precisas a ser enviada como um feedback para a configuração do delta Operações de ativação / validação.

Componente defeituoso e versão: RROMexe

Relatórios anomalia corrigida: NA05348549 RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente. BTS reset é necessário


Componente Rrom. -







Versão 131670


* SW-type -

* Unidade -



Pré-requisitos: Prepare eNB Uma configuração com passos seguintes: - LTE492 está habilitado (anrOmExtEnable em LNBTS) - Criar LNADJ com objetos LNADJL - PciIpAddrMap (LNBTS) são ajustados para que ele contenha pci de LNADJL e falso IP endereço - Criar LNREL LNADJL correspondência

A execução do teste: 1. On eNB Adicione LNADJ (eNB controlada) para eNB B com endereço IP falso (para que ligação estado é indisponível) 2. On eNB B adicionar LNADJ (OAM controlada) para eNB A 3. Configuração X2 é enviar de B para A, antiga brincadeira LNADJ removido, novo criado 4. Faça uma disposição plano de NetAct

Passos 1 -. 4. Deve ser feita em 130 segundos (maxTimeSctpSetup).

Resultados esperados: Provisão Plano de sucesso.

Resultados inesperados: Falha provisão Plano. BTS reset é necessário para fazer novamente as mudanças na configuração eNB.


CN-id: LN40_00065

Título: Alta perda de desempenho de rádio na configuração de alta velocidade Multicélula.



Referências:

Razão para a mudança Nota: Resumo do problema original: Escala valores entre as células são misturadas e isso faz com que a volatilidade no poder medições e tem grande impacto sobre o desempenho do rádio. Issue está presente apenas em multicell configuração de alta velocidade.

Como usuário final / operador podia detectar o problema: a degradação do desempenho de RF. Se várias células são configurados em modo de alta velocidade, em seguida, a segunda célula não funciona corretamente e pode sofrer em alta perda de desempenho.

Descrição da falha: GetChAdaptMultipliers função misturado scalers entre as células que levam à má rádio desempenho.

Relacionadas característica / funcionalidade: Trem de alta velocidade

Dependência de configuração: Várias células por piscina deve estar em uso.

Solução:

Descrição da correção (análise de risco incluído): Correção fornecido (indexação corrigido dentro algoritmo). Correção feita apenas em alta algoritmos de velocidade. Sem impacto na configuração normal.

Efeitos sobre a operadora: impacto degradation.No desempenho de RF sobre a configuração normal.

Componente defeituoso e versão: UL PHY - receptor Pusch

Relatórios anomalia corrigida: 40503ESPE05 Alta perda de desempenho de rádio na configuração de alta velocidade Multicélula.



ComponentVersion LN4.0_PHY_RX_ 53273 FSM3_1202_184 _00








* SW-type -

* Unidade -


Pré-requisitos: Várias células por piscina deve estar em uso.

A execução do teste: Configuração 2 células HIGHSPEED Em uma piscina e depois ues configuração só a segunda célula.

Resultados esperados: Problema apagada.

Resultados inesperados: Os problemas podem ser observados em medições de energia que foram relatório de MAC (por exemplo, no TTI vestigiais).


CN-id: LN40_00066

Título: Falha RF Módulo Bloquear ocorreu em BTS Site Manager para a recuperação de RP3 10 após RL40 0.0.2 SW Atualizado



Referências:

Razão para a mudança Nota: NA05353538: Resumo do problema original: Alguns BTS não pode bloquear Módulo RF para a recuperação de RL30 10 após RL40 0.0.2 Atualização SW

Como usuário final / operador podia detectar o problema: Falha na relação RP3 óptica (0010), Unidade bloqueado (0048)

Descrição da falha: circuito de falhas 4003 Cancela estava enchendo buffer de falha FM e novo falhas não pode ser tratada por isso não havia atualizações no Site Manager sobre o estado real do BTS.

Dependência de configuração: modo FHCC acoplado

Solução: local eNB redefinição

Descrição da correção (análise de risco incluído): Correcção relativa ao tratamento da falha 4003 eNB é fornecido.

Efeitos sobre o usuário final: Actividade de Manutenção errado Efeitos sobre a operadora: Actividade de Manutenção errado

Efeitos do sistema: eNB conseguiram cancelar o alarme anterior

NA05353720: Resumo do problema original: Alarme de interface X2 (6203), não sendo apagada, porém verdadeira ligação X2 está disponível Como usuário final / operador podia detectar o problema: O estado de alarme eo status operacional para o link X2 não corresponde.

Descrição da falha: Falha "falha de conexão da camada de transporte na interface de X2 (6203)" ainda visto em SM, que é alarme falso porque tudo ligação X2 estão disponíveis


Relacionadas característica / funcionalidade: modo FHCC acoplada


Dependência de configuração: modo FHCC acoplado

Solução: Redefinir o eNB

Descrição da correção (análise de risco incluído): Com a configuração RIM acrescentou o check-in FM se culpa 4003 está ativo e se é e deve ser limpo depois limpá-lo.

Efeitos sobre o usuário final: Actividade de Manutenção errado Efeitos sobre a operadora: Actividade de Manutenção errado

Efeitos do sistema: eNB conseguiram cancelar o alarme anterior

Relatórios anomalia corrigida: NA05353538 Falha RF Módulo Bloquear ocorreu em BTS Site Manager para a recuperação de RP3 10 após RL40 0.0.2 SW Atualizado

NA05353720 Alarme de interface X2 (6203), não sendo apagada, porém verdadeira ligação X2 está disponível


Componente Cell.cpp FORE_FDFC_Pk g.sbs







Versão 209156 209987


* SW-type - -

* Unidade - -


Testando Instruções para o NA05353538 mudança

Pré-requisitos: Configure eNB com FHCC juntamente modo e provisão alguns LNADJs fictícios para que o verdadeiro vizinho não existe

A execução do teste: Deixe o eNB execução de algumas horas (6 horas pode ser seguro) Interromper algumas rádios que constituem o modo FHCC acoplado Tente bloquear qualquer módulo de rádio

Resultados esperados: Bloco de Operação do módulo de RF será feita com sucesso, apesar de todo o contínuo próximos falhas sendo tratado pelo eNB

Resultados inesperados: Bloco de Operação do módulo de RF não pode ser feita com a razão do tempo limite devido a algum falhas inundadas sendo tratado pelo eNB

Testando Instruções para o NA05353538 mudança

Pré-requisitos: Configure eNB com células modo FHCC acopladas e muitas configurações vizinhos

A execução do teste: Gatilho óptica interromper ou bloquear / desbloquear a RFM que constituem FHCC modo acoplado um algumas vezes e deixar o eNB envelhecido um par de horas Redefinição de alguns dos eNBs vizinhos para estimular a mudança do status do link X2

Resultados esperados: A informação de alarme eo status do link será comparado (6203 e X2 ligação desconectada ou Não Alarme e X2 ligação conectado)

Resultados inesperados: A informação de alarme eo estado da ligação não poderia ser igualada (6203 e X2 ligação ligado)


CN-id: LN40_00067

Título: [LNT3.0] 1232 fatal quando fazer a entrega por muito tempo



Referências:

Razão para a mudança Nota: Resumo do problema original: Falhas de aplicação tupu durante a transmissão de pacotes SRB em direção DL.

Como usuário final / operador podia detectar o problema: eNB FSP redefinição de recuperação é realizada

Descrição da falha: Tarefa UL lançado memória e ainda usá-lo para o tempo. Às vezes, tarefa DL reservados exatamente essa memória. Nos resultados da tarefa UL tem valores indevidos e tivemos acidente.

Relacionadas característica / funcionalidade: transmissão SRB comum

Dependência de configuração: nenhum Solução alternativa: nenhum Correção: UL libera memória da tarefa apenas se essa memória em não mais necessários. Efeitos sobre o usuário final: Gota chamada Efeitos sobre a operadora: a diminuição da capacidade eNB por um período de tempo de recuperação Efeitos do sistema: as chamadas alocados em determinado FSP será descartado Outros efeitos: nenhum Efeitos de interface: nenhum Componente defeituoso e versão: tupu Componente defeituoso entregue pela primeira vez em (por exemplo, lançamento, CD): tupu (do primeiro release)

Relatórios anomalia corrigida: 122788ESPE02 1232 fatal quando fazer a entrega por muito tempo


Componente tupu. -


Versão * elemento Net LN4.0_TUP_ - 1108_048_0

* SW-type -

* Unidade -


0








Pré-requisitos: Celular é onair e UE pode pesquisar o celular

Resultados inesperados: quando o caso correr por cerca de 3 horas, 1.232 acontece fatal

A execução do teste: Anexar transferência para célula vizinha: 5 operações por segundo ? UE transferência para eNB do vizinho eNB destacar: três operações por segundo (Dois cenários acima correr juntos)

Resultados esperados: Corra por 12 horas ea taxa de sucesso é mais do que 99,5%

Resultados inesperados: Quando caso funcionar por cerca de 3 horas, 1.232 acontece fatal


CN-id: LN40_00068

Título: Insucesso do RET antena relatados com alarme errado



Referências:

Razão para a mudança Nota: Resumo do problema original: Insucesso do RET antena relatados com alarme errado

Como usuário final / operador podia detectar o problema: Alterar a configuração de RET para possuir e Outros BTS. Jam RET

Descrição da falha: Falha de controle de antena RET relatados com alarme errado.

Descrição da correção (análise de risco incluído): Este RET deve estabelecer a relação com cell1 e número do alarme deve ser 7654 (Funcionamento da célula local degradado), a alteração do processo de criação de tal relação.

Efeitos sobre o usuário final: alarme errado está presente para usuário

Efeitos sobre a operadora: alarme errado está presente para usuário

Relatórios anomalia corrigida: NA05341112 Insucesso do RET antena relatados com alarme errado


ComponentVersion RelationsManage 213534 r.cls


* SW-type -

* Unidade -









Pré-requisitos: RET associado a uma célula

A execução do teste: Modificado o ângulo RET e verificar se eles RET está girando. Modifique o RET novamente, mas desta vez evitar o RET de girar.

Resultados esperados: Quando o RET é jam o seguinte alarme deve aparecer. 7654 operação célula local degradante

Resultados inesperados: Alarme 7651 não deve aparecer.


CN-id: LN40_00069

Título: eNB não pode estar no ar após seguinte procedimento: desligue a alimentação RF, reposição do site eNB , Ligar fonte de alimentação RF



Referências:

Razão para a mudança Nota: Resumo do problema original: eNB não pode estar no ar após seguinte procedimento: desligue a alimentação RF, reposição do site eNB , Ligar fonte de alimentação RF Como usuário final / operador podia detectar o problema: desligue a alimentação RF, reposição do site eNB, ligar fonte de alimentação RF Descrição da falha: FSP não foi totalmente instalado e funcionando ainda BTSOM embora relatado como disponível.

Solução: N / A

Descrição da correção (análise de risco incluído): BTSOM relatou FSP como disponíveis pelo menos quando SWState da FSP é configued. Efeitos sobre o usuário final:

Efeitos sobre a operadora: Actividade de Manutenção errado

Efeitos do sistema: Atividade Manutenção errado

Relatórios anomalia corrigida: NA05356261 Partilha RF cabeamento pode bloquear eNB


ComponentVersion RROM_adapter.s 211082 bs


* SW-type -

* Unidade -









Pré-requisitos: Nenhum

A execução do teste: Passado

Resultados esperados: Problema apuradas

Resultados inesperados: Nenhum


CN-id: LN40_00070

Título: RL40 Aceitação - X2 Atualização de eNB eliminado Vizinho Relacionamento



Referências:

Razão para a mudança Nota: Resumo do problema original: Ao testar o LTE Característica 1014 eu encontrei um problema de interoperabilidade ao testar X2 interface Como usuário final / operador podia detectar o problema: Depois de receber Update Configuration X2, rrom estava atualizando LNADJLs no caminho errado

Descrição da falha: Depois de alterar a frequência de outro celular eNB 4 a LNADJL-6 objeto anterior com Celular 0 foi substituído com as informações de cerca de outro celular ENB 4 (de LNADJL-7, que depois foi eliminado). No entanto, o celular 0 inteiro que estavam anteriormente em LNADJL-6 não foram recriados com outro ID, mas simplesmente desapareceu. Depois, mudou novamente outras configurações em outro eNB e todo o tempo as mudanças que estão afetando a 2 ou superior objeto LNADJL, eles substituem a primeira entrada. Se uma mudança em um celular que falta é feita, essa entrada é recriado.

Depois de receber RROM_AdjacentCellConfigReq com o modo Delta rrom tinha errado mapeamento de FreeInstance lnadjl ids

Relacionadas característica / funcionalidade: LTE1014 Dependência de configuração: LNADJ-0 com LNADJL-9, LNADJL-10 e LNADJL-11 Solução: Descrição da correção (análise de risco incluído): Manuseio adequado de atualização de configuração X2


Relatórios anomalia corrigida: NA05366479 RL40 Aceitação - X2 Atualização de eNB eliminado eNB Relacionamento



Componente Rrom. -






Impacto para o Cliente Novo recurso / funcionalidade

Versão 136378


* SW-type -

* Unidade -


Pré-requisitos: Vizinho relação ao fornecedor externo (no nosso caso: eNB com 6 células / LNADJL) criado Status da conexão X2: disponível

A execução do teste: Alterar parâmetro célula relacionado no local fornecedor externo

Resultados esperados: Informações atualizadas em celular informações relação vizinho para esta célula dedicada (LNADJL informação actualizada)

Resultados inesperados: LNADJL objeto para a célula que foi alterada em fornecedor externo está sendo excluída por X2 procedimento de atualização


CN-id: LN40_00072

Título: RL40-piloto: FXEB relata alarme "Módulo RF detectou nenhum poder TX em filtro interno block "



Referências:

Razão para a mudança Nota: Resumo do problema original: Após BTS reset (gerente de BTS) Alarme de "Módulo RF detectou nenhum poder TX em bloco filtro interno "foram relatados a partir de FXEB em gerente BTS. Medidor de potência de energia não confirmou saída nos tubos problemáticos da FXEB.

Como usuário final / operador podia detectar o problema: Na frente das BTS, não é visto de alarme (LED piscando em vermelho) em vez de FXDB FXEB. Além disso alarmes não são relatados para BSC, mas só vi no gerenciador de BTS

Descrição da falha: Novos valores do parâmetro (MIN_VALID_VSWR_SAMPLES = 300, MIN_VALID_FWD_PWR_SAMPLES = 500) usado no arquivo de propriedades do filtro. Estes valores têm não foi utilizado na fase de desenvolvimento de SW. Eles foram introduzidos pela fábrica.

Solução: HW BTS reset (gerente de BTS) resolveu o problema.

Descrição da correção (análise de risco incluído): MIN_VALID_VSWR_SAMPLES e Valores MIN_VALID_FWD_PWR_SAMPLES dentro do arquivo propriedade de filtro foi mudado de volta a partir de 300 a 500 a 20 e 20

Efeitos sobre a operadora: A RFM módulo Bloqueio / Desbloqueio é feito de Site Manager. Após a desbloquear todos os módulos e as células devem se recuperar bem, no entanto, ocasionalmente, alguns se o GSM TRX pode falhar e uma alarme 'TRX defeituosa: Módulo RF detectou nenhum poder TX.


Relatórios anomalia corrigida: NA05349186 RL40-piloto: FXEB relata alarme "Módulo RF detectou nenhum poder TX em filtro interno block "



ComponentVersion BTSRFM-13948 -. BTSRFM- 13948








* SW-type -

* Unidade -


Pré-requisitos: Nenhum

A execução do teste: Erro, que apareceu no site do cliente não pode ser reproduzido em testlab. Portanto, apenas regressão básica foi executada com sucesso com carga correção LN4.0_ENB_1202_780_10.

Resultados esperados: Problema apuradas

Resultados inesperados: Nenhum


CN-id: LN40_00073

Título: RL40 MP1 cinco: eNB fica configurada após S1 pausa



Referências:

Razão para a mudança Nota: 125102ESPE02: Após o envio ENBC_LinkStateChangeReq, rrom estava esperando por ENBC_LinkStateChangeResp ignorando TUP_LinkStateInd. Agora TUP_LinkStateInd serão armazenados e manipulados após ENBC_LinkStateChangeResp ou timeout.

125929ESPE02: Resumo do problema original: Após o envio ENBC_LinkStateChangeReq, rrom estava esperando por ENBC_LinkStateChangeResp ignorando TUP_LinkStateInd.

Como usuário final / operador podia detectar o problema: eNB viu S1 Link como indisponível após S1Link mudou de status para OUTOFSERVICE e em breve após a InService, como mensagem InService foi ignorado.

Descrição da falha: consulte "Resumo do problema original" como uma referência /

Relacionadas característica / funcionalidade: LTE2

Dependência de configuração: Sem dependência de configuração

Solução: Não há solução

Descrição da correção (análise de risco incluído): TUP_LinkStateInd é armazenado e manuseado após receber ENBC_LinkStateChangeResp ou timeout.


Efeitos sobre o usuário final: Ligação S1 são vistos corretamente eNB

Efeitos sobre a operadora: Ligação S1 são vistos corretamente eNB

Efeitos do sistema: Ligação S1 são vistos corretamente eNB

Componente defeituoso e versão: componente: RROMexe

Relatórios anomalia corrigida: 125102ESPE02 RL40 MP1 cinco: eNB fica configurada após S1 pausa

125929ESPE02 Após MME restart eNB é preso em estado configure setup pedido S1 não enviou ao MME


Componente Rrom. -






Impacto para o Cliente 125102ESPE02

Versão 139000


* SW-type -

* Unidade -



Pré-requisitos: Após MME restart eNB é preso em Configurar estado, pedido de instalação S1 não enviou ao MME.

A execução do teste: a. eNB é OnAir b. MME reiniciado c. eNB mostra falha connecgtion camada de transporte na interface de S1 d. eNB continuar a enviar mensagem INIT e. MME está agora totalmente operacional, o MME enviar INIT_ACK e eNB envia COOKIE_ECHO MME e reconhece f. eNB nunca enviar pedido de configuração S1 g. Há batimentos cardíacos SCTP entre eNB e MME. h. O rádio não está transmitindo. Então, sem as chamadas podem ser feitas.

Resultados esperados: Ligação S1 são vistos corretamente eNB

Resultados inesperados: Ligação S1 são vistos de forma incorrecta eNB


CN-id: LN40_00074

Título: status operacional da célula torna-se eNodeB disable devido a BCN nenhuma resposta depois anexada 200UE com modelo de tráfego 11 e configuração 7 para 15 minutos



Referências:

Razão para a mudança Nota: Resumo do problema original: Faltando valores SERDES no ramo de software

Como usuário final / operador podia detectar o problema: Conexão SRIO instável entre a FCT ea FSP vai levar a quedas de pacotes.

Descrição da falha: Uso de ramos é a raiz do mal.

Relacionadas característica / funcionalidade: SERDES - IN004


Solução: Nenhum

Descrição da correção (análise de risco incluído): Merge Característica

Efeitos sobre o usuário final: Desconhecido

Efeitos sobre a operadora: Desconhecido

Efeitos do sistema: Desconhecido

Outros efeitos: Desconhecido

Efeitos de interface: Desconhecido

Página 142


Componente defeituoso e versão: LFS

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): Todos os ramos são afetados

Relatórios anomalia corrigida: 92663ESPE01 [LN3.1] status operacional da célula torna-se eNodeB disable devido ao BCN nenhuma resposta após 200UE anexada com modelo de tráfego 11 e configuração 7 para 15 minutos

92745ESPE01 [LNT3.1] FSP auto reset, API_RESET_RESP_MSG não recebeu de HWAPI

41702ESPE05 [LNT3.1] célula eNB auto disable devido a CCS fatal erro (EAaErrorFatality_NonFatal, Aplicação morreu inesperadamente) depois de 200UE com o tráfego por 10 minutos








Impacto para o Cliente 92663ESPE01:

Versão -


* SW-type -

* Unidade -



Pré-requisitos: 1. O local está equipado com FSMF & AFBB com dispositivo relógio IDT Versão A, porque Hardware versão B tem alguns bugs. 2. O site é OnAir e status célula é normal. 3. 200UE está pronto para teste

A execução do teste: Grupo UE = 1 Número UE = 50 Anexar duração (s) = 600 Retire duração (s) = 60 Tipo de aplicação = FTP download Tráfego ON (s) = 60 Tráfego OFF (s) = 30 Caso duração = 8 horas Tipo desaparecendo = UL / DL desvanecimento Faixa de movimento Ue (m) = 30-3000 Ue mover velocidade (m / s) = 30

Grupo UE = 2 Número UE = 50 Anexar duração (s) = 600 Retire duração (s) = 60 Tipo de aplicação = FTP upload Tráfego ON (s) = 60 Tráfego OFF (s) = 30 Caso duração = 8 horas Tipo desaparecendo = UL / DL desvanecimento Faixa de movimento Ue (m) = 30-3000 Ue mover velocidade (m / s) = 30

Grupo UE = 3 Número UE = 50 Anexar duração (s) = 1200 Retire duração (s) = 60 Tipo de aplicação = FTP download e de upload Tráfego ON (s) = Sempre Tráfego OFF (s) = N / D Caso duração = 8 horas Tipo desaparecendo = UL / DL desvanecimento Faixa de movimento Ue (m) = 30-3000 Ue mover velocidade (m / s) = 15

Grupo UE = 4 Número UE = 50 Anexar duração (s) = 1200 Retire duração (s) = 60 Tipo de aplicação = FTP download e de upload Tráfego ON (s) = Sempre Tráfego OFF (s) = N / D Caso duração = 8 horas Tipo desaparecendo = UL / DL desvanecimento

Página 144


Faixa de movimento Ue (m) = 30-3000 Ue mover velocidade (m / s) = 15

Grupo UE = 5 Número UE = 50 Anexar duração (s) = 120 Retire duração (s) = 10 Tipo de aplicação = FTP download Tráfego ON (s) = 8 Tráfego OFF (s) = 5 Caso duração = 8 horas Tipo desaparecendo = UL / DL desvanecimento Faixa de movimento Ue (m) = 30-3000 Ue mover velocidade (m / s) = 3

Grupo UE = 6 Número UE = 50 Anexar duração (s) = 120 Retire duração (s) = 10 Tipo de aplicação = FTP upload Tráfego ON (s) = Sempre Tráfego OFF (s) = N / D Caso duração = 8 horas Tipo desaparecendo = UL / DL desvanecimento Faixa de movimento Ue (m) = 30-3000 Ue mover velocidade (m / s) = 3

Resultados esperados: Em todo o caso, correndo por 8 horas, 1. UEs não são liberados 2. O site está funcionando sem nenhum fatal. 3. Nenhum log de erro como "não BCN resposta 'em BTSlog

Resultados inesperados: 1. BTS imprime muitos logs de erro como "BCN ... sem resposta" 2. Todos os UEs são liberados e não pode acessar o celular mais. 3. Celular ficam indisponíveis.


CN-id: LN40_00075

Título: RL40 LTE FOA - FALHA NA RP3 OPTICAL INTERFACE



Referências:

Razão para a mudança Nota: Resumo do problema original: O alarme "7653 CELL Failure FAULTY in interface RP3 óptica" é ocasionalmente olhando e cancelar de forma aleatória e eNB de Frig do

Como usuário final / operador podia detectar o problema: O alarme "7653 CELL Failure FAULTY in interface RP3 óptica" não é iniciado e cancelar aleatoriamente para diferentes ENB de e frig de dentro de 20-90 seg.

Descrição da falha: Questão RP3 sincronia entre o chip e chip MERA Murkku2 dentro Frig.

Dependência de configuração: O problema tem sido visto apenas com FSMF + Frig HW com fibra óptica monomodo conexão

Solução: Nenhum

Efeitos sobre o usuário final: Chamada pode cair durante a falha e UE não é capaz de acessar à célula afetada.

Efeitos sobre a operadora: É difícil ver qualquer impacto para KPIs, uma vez que o problema ocorreu muito raramente no rede (2-3 vezes por semana) e queda de célula é bastante curta

Componente defeituoso primeiro entregue em (por exemplo, lançamento, CD): RL40 1,0

Relatórios anomalia corrigida: NA05334838 RL40 LTE FOA - FALHA NA RP3 OPTICAL INTERFACE



Componente VEG23.01.R07H

Versão * elemento Net VEG23.01.R - 07H

* SW-type -

* Unidade -








Pré-requisitos: Vários ENB de operacionais com FSMF, Frig + SFP única e modo único óptica fibra entre FSMF e Frig do

A execução do teste: ENB está em uso real, em rede ao vivo, sem resets ENB Monitorar o "7653 CELL Failure FAULTY em interfaces ópticas RP3" alarmes durante uma semana.

Resultados esperados: O alarme "7653 CELL Failure FAULTY in interface RP3 óptica" não é iniciado e cancelar aleatoriamente para qualquer FRIG de dentro de 20-90 segundos, devido à questão de erro LCV RP3 (módulo RF toros precisam analisados).

Resultados inesperados: O alarme "7653 CELL Failure FAULTY em interface de RP3 óptica" começa e cancelar aleatoriamente para qualquer FRIG de dentro de 20-90 segundos, devido à questão de erro LCV RP3 (módulo RF toros precisam analisados).


Documento de Impacto



LTE_RL40_1.0

RL40 1,0

Estações Base


LN4.0 1,0,

17-May-2013

CONFIDENCIAL APROVADO 1,0

Documento LTE_RL40_1.0 Impacto A Nokia Siemens Networks ©

1 (7)

Índice

1. 2.

2.1

Propósito ......................................................................................................................................................... 3 Lançamento entrega effect.................................................................................................................................. 3

Visão global .................................................................................................................................................................. 3 3.

3.1 3.2

Efeitos sobre o usuário final ....................................................................................................................................... 4 Rádio Destaques ....................................................................................................................................................... 4 Rádio Notas Destaque .............................................................................................................................................. 6

4. 5.

Outro effects.................................................................................................................................................. 6 Apêndices / Referências .............................................................................................................................. 6

Contato: Contacte o apoio local da Nokia Siemens Networks


2013/05/17 V1.0 Versão aprovada



2 (7)

1. PROPÓSITO

A finalidade deste documento é descrever os efeitos de entrega de liberação no relevante partes, funcionalidades novas e alteradas que instalar este Entrega Lançamento trazer para a rede do cliente.

2. EFEITO LIBERAÇÃO DE ENTREGA

2.1 Visão Geral

RL40 é um lançamento da Nokia Siemens Networks para o acesso de rádio LTE (modo FDD). É um mundo lançamento no mercado e aumenta as capacidades da versão anterior RL30.

LTE página web internet http://www.nokiasiemensnetworks.com/portfolio/products/mobile-broadband/long-term- evolution-LTE

LTE Documentação do Cliente Nokia Siemens Networks Long Term Evolution Centro de Informações



3 (7)

3. EFEITOS SOBRE O USUÁRIO FINAL 3.1 Rádio Destaques

• Áreas principal melhoria

RL40 .. Melhora a experiência do usuário LTE

.. É a primeira versão para apoiar Flexi Multiradio 10 BTS

.. Permite novas opções de implantação e otimiza a operacionalidade

.. É baseado em 3GPP Rel.9 (Dezembro de 2010)

• Conteúdo Principal

Experiência aprimorada do usuário

o

o

o

o

o

o

o

QoS: apoio das classes portador GBR para vídeo e jogos em tempo real

QoS avançado para GBR com controle de admissão de previsão com preempção

Suporte de 3 portadores simultâneos GBR por UE

QoS avançadas para não-GBR por QCI up-/downgrade

Desempenho otimizado com UL Canal Ciente inteligente Scheduler e Interferência Rejeição Combinando (IRC)

Mobilidade de voz uniforme, com SRVCC para WCDMA e GSM

Alta velocidade de mobilidade até 350 kmh



4 (7)

Opções de novas e mais eficientes de implantação e Soluções do Site

o

o

o

o

o

o

o

Flexi Multiradio Módulo System (FSMF) para sites multirádio alta capacidade

RF 4-pipe (4x30W) com Frig para a banda AWS

Potência de saída 3x80W, banda larga Flexi Triplo módulo RF (FXEB) para 1800MHz

Flexi Triplo módulo RF (FXFA) para 1900MHz

2x60W Flexi RRH (FHDB) para 900MHz

Operação Band Dual com um módulo de sistema (10 +10 MHz)

Balanceamento de carga entre diferentes faixas, também no modo de Espera

Operacionalidade

o

o

o

Coordenação com SON SON relatórios para maior controle do operador

Minimização de unidade Testes: coleta de dados abrangente traço permite detalhada análise com FILHO Suíte

Segurança reforçada com agentes de criptografia e SW-verificação

• Nova configuração suportada

• Operação de banda dupla com 10 MHz de largura de banda de até 6 células.

• Nova Apoiado Flexi Rádio HW

3 liberação de FlexiSystem Módulo de base para Flexi Multiradio 10 BTS

•

•

•

•

FSMF Flexi Módulo do Sistema Multimodal de 3 ª geração

FTIF

FPFD

FPFC

Flexi Transporte sub-módulo de 3 ª geração

Distribuição de energia Flexi sub-módulo FPFD

Distribuição de energia Flexi módulo FPFC, independente

Novas variantes de RF

•

•

•

•

•

•

FXFA Flexi 3-setor Módulo RF 1900

FXEB Flexi 3RF Rádio Módulo 1800 MHz, 90W

Frig Flexi RRH 1,7 / 2,1, AWS

FRGV Flexi RRH 2100 nova geração

FHDB Flexi RRH 900MHz, FHDB

FRMD Flexi Módulo RF 3 do setor 800 da UE (A-bloco)



5 (7)

3.2 Rádio Notas Destaque

Restrições: 2 recursos não liberados •LTE1263 FRGV Flexi RRH 2TX 2100. Alternativa é LTE452 FRGQ Flexi RRH 2TX 2100. •LTE940 SW Verificação Agent. A implementação está concluída, mas ativação global está pendente alinhamento MultiRAT como RL40 é também fab-SW para novo FSMF HW.

FSMF piloto foi feito em ambiente de baixo tráfego.

4. OUTROS EFEITOS

N.d.

5. APÊNDICES / Referências

N.d.



6 (7)

Renúncia








7 (7)

Instruções de instalação



LTE_RL40_1.0

RL40 1,0

Estações Base


LN4.0 1.0

03-Julho-2013


Instruções de instalação LTE_RL40_1.0 A Nokia Siemens Networks ©

1 (19)

Índice

1. 2.

2.1

Propósito ......................................................................................................................................................... 3 Visão global ....................................................................................................................................................... 3

Outras instalações de Relevante Instructions.................................................................................................................... 3 3. 4. 5.

5.1 5.2 5.3 5.4

Preparativos .................................................................................................................................................. 3 SW instruções de download ........................................................................................................................ 4 Condições especiais ......................................................................................................................................... 5

Flexi Multiradio BTS LTE ......................................................................................................................................... 5 Matriz de compatibilidade .................................................................................................................................................. 5 Compartilhamento de RF ............................................................................................................................................................... 5 LTE IOMS ................................................................................................................................................................ 6

6. 7.

A migração de dados ............................................................................................................................................... 6 Instruções de atualização entrega Lançamento .......................................................................................................... 6

7.1 7.1.1 7.1.2 7.2

Flexi Multiradio BTS LTE ......................................................................................................................................... 6 Primeira instalação e commissioning......................................................................................................................... 6 Atualização / Update para RL40 1,0 ................................................................................................................................... 6 FILHO ......................................................................................................................................................................... 9

8. 9.

9.1 9.2

Sugestões e recomendações operacionais ...................................................................................................... 9 Verificando a consistência do pacote ........................................................................................................ 17

Flexi Multiradio BTS LTE ....................................................................................................................................... 17 LTE IOMS .............................................................................................................................................................. 17

10. 11.

Reserva ....................................................................................................................................................... 17 Apêndices / Referências ............................................................................................................................ 18

Contato:

Contacte o apoio local da Nokia Siemens Networks


2013/05/17 2013/07/03

V1.0 V2.0

Versão aprovada Atualizações: •LTE RL40 fábrica SW adicionado no capítulo 7.1 como testado e suportado atualização caminho, •restrição quanto fallback para RL40 fábrica SW (LN4.0_ENB_1202_696_00) para FSMF A.102 adicionado no capítulo 10.



2 (19)

1. PROPÓSITO

O objetivo deste documento é descrever as ações necessárias para a instalação e ou melhoria Esta entrega Lançamento em rede do cliente.

2. PANORAMA

Este documento abrange instruções de instalação Flexi Multiradio BTS LTE (ENB) e LTE IOMS. Instruções de instalação padrão estão disponíveis na biblioteca de documentação do cliente acessível através NOLS [1] em: •Nokia Siemens Networks Long Term Evolution Centro de Informação [4] É necessário estudar cuidadosamente o conteúdo da biblioteca e siga em procedimentos detalhados nos documentos. Será especificado no presente documento que a instrução deve ser usado para instalação de determinada entidade, todas as exceções de procedimento de base serão listados neste documento. Durante a execução do procedimento o usuário será solicitado a parar de seguir o cliente oficial Documentação e executar etapas mencionadas aqui. Uma maneira de acessar a documentação do cliente é descrito no ponto 2.1.

2.1 Outros Instruções de instalação relevantes

Todos LTE documentação do cliente, incluindo procedimentos de instalação padrão, é acessível através NOLS [1] na seção "Product Information Center" Nokia Siemens Networks Long Term Evolution Centro de Informações [4]

É muito importante verificar se nova mudança entregas estão disponíveis - eles podem conter mais recente versão dos documentos.

3. PREPARATIVOS

1. Hardware usado para a instalação devem ser integrados de acordo com a instalação de hardware orientar e todo o cabeamento necessário já deve ser feito. Documentos necessários podem ser encontrados em a secção "Instalar e comissões" na biblioteca de documentação do cliente •Para os documentos de referência Flexi Multiradio BTS LTE são nomeados "Instalando Flexi Multirrádio BTS LTE ... "[2] (Figura 1)



3 (19)

Figura 1 Documentos necessários para a preparação da biblioteca de documentação do cliente

2. Para permitir o uso de recursos SON devem ser tomadas algumas medidas de preparação. É descrito em Biblioteca de documentação do cliente na seção "Área Funcional Descrição-Operacionalidade- Gestão Configuration Management-SON "capítulo 4" Descrição funcional para o filho gestão "[5].

4. SW instruções de download

O software para os produtos lançados está disponível em NOLS.

O software recém-lançado pode ser baixado a partir dos links diretos:

• Flexi Multiradio BTS LTE:

https://online.portal.nokiasiemensnetworks.com/SWD/?access_key=OTYzNTM% 3D

Software item eNB

BTS Site Manager

Ouro SCF


Nome do Software Arquivo LN4.0_ENB_1202_780_10_release_B TSSM_downloadable.zip BTS_Site_Manager_LN4.0_BTSSM_1 202_765_00.zip Golden_SCF-FB1202_6xy_P8 partir-update --- 2013-02-26.zip

SHA1 soma de verificação C27464AF62ACA4323BD8C27A7 1235CDABDAF3F42 AD6220CF7B317550688E0B761 BA7D23643096FF5 6E4DEA86562D25DA3489D4CC 5BC0B3A93E9892ED


4 (19)

Depois de baixar o software é importante para gerar soma SH1 para arquivos e comparar com o previsto no Resumo das correções e aprimoramentos documento, essa vontade garantir que os arquivos não foram corrompidos durante a transferência.

• LTE IOMS:

Não há nenhuma nova versão do LTE IOMS SW.

A última versão lançada LTE IOMS SW foi publicado em LTE_RL40

Entrega LTE_RL40 IOMS SW está disponível sob seguinte link:

https://online.portal.nokiasiemensnetworks.com/SWD/?access_key=OTQ1MTA% 3D

No entanto observe as dicas e as limitações operacionais importantes ligados ao recentemente lançado 4.0 SW LTE IOMS (R_GOMS6_1.82.1.0_corr30):

1. TS-LTE_iOMS-SW-0009 - LTE IOMS 3.0 para 4.0 LTE IOMS upgrade - restrição e atualização procedimento

NA05344350: PM arquivos não são compactados em eNB e por isso não coletados em IOMS Este problema só é válido no caso de o LTE IOMS é atualizado para o LTE IOMS 4.0 SW (R_GOMS6_1.82.1.0_corr30) e eNB permanece no nível RL30 SW. O problema é ocasional. Se ele vai ocorrer, em seguida, os dados PM não será visível por 24 horas. Este problema é corrigido no eNB SW LN4.0_ENB_1202_780_10 fazer parte dessa entrega.

TS-LTE_iOMS-SW-0006 -> alarmsystem afetado durante a atualização do SW e fallback

2.

3.

5. CONDIÇÕES ESPECIAIS

5.1 Flexi Multiradio BTS LTE

Produto FHCA 472169A.103 (FPGA) deve ser usado no máx. 2 * 20W de potência DL. Este firmware só deve ser utilizado nas seguintes condições: modo de 20W -40 a 50 graus.

FRGP deve ser usada em 2 * 15W potência DL.

5.2 Matriz de compatibilidade

SW entrega

RL40


LN4.0_ENB_1202_691_02

BTSSM

LN4.0_BTSS M_1202_759 _00 LN4.0_BTSS M_1202_765 _00

LTE IOMS

R_GOMS6_1.82.1.0_corr30

NetAct

OSS5.4 CD2

OSS5.4 CD2

SEM validador

6.20.371

RL40 1,0 LN4.0_ENB_1202_780_10 R_GOMS6_1.82.1.0_corr30 6.20.371

5.3 partilha RF

O recomendado e liberado GSM BTS SW para compartilhamento de RF com RL40 MP1 são EX5 0.0.1 EX5 e 1.0.0 (RG20 e RG30 EP2).

Para obter detalhes sobre as configurações suportadas, tais como: níveis de potência, tipos de configuração de antena, requisitos, bandas, e assim por diante, ver Flexi Multiradio BTS Sharing RF Configurações suportadas arquivo excel. Instruções para atualização Release - Projeto de atualização



5 (19)

O caminho de atualização recomendado e liberado em caso de GSM-LTE Sharing RF é de LN3.0 4.0/EX5 0.0.1toLN4.0 1.0/EX5 0.0.1or LN4.0 1.0/EX4.2 MP1toLN4.0 1.0/EX5 0.0.1or LN4.0 0.0.1/EX5 0.0.1toLN4.0 1.0/EX5 0.0.1or LN4.0 1.0/EX5 0.0.1toLN4.0 1.0/EX5 1.0.0or LN3.0 4.0/EX5 1.0.0toLN4.0 1.0/EX5 1.0.0.

5.4 LTE IOMS

Antes de iniciar a instalação IOMS o relógio HW na BIOS da unidade, onde o software é ser instalado deve ser corrigido para refletir hora atual em fuso horário UTC / GMT.

6. Migração de dados

Em caso de atualizar o IOMS de RL30 para RL40 por favor siga as instruções do cliente Documento "Atualizando da LTE OMS 3.0 para LTE OMS 4.0" [6].

7. Instruções de atualização LIBERAÇÃO DE ENTREGA


Pré-requisito:

Flexi Base Station LTE tem um ativo da seguinte SW: oLTE RL30 fábrica SW (LN3.0_ENB_1103_771_02) oLTE RL30 2,1 (LN3.0_ENB_1103_772_11) oLTE RL30 3,0 (LN3.0_ENB_1103_896_05) oCliente Específico LTE RL30 3.1.1 (LN3.0_ENB_1103_897_10) oLTE RL30 4.0 (LN3.0_ENB_1103_930_41) oLTE RL40 P8 (LN4.0_ENB_1202_691_02) oCliente Específico LTE RL40 0.0.2 (LN4.0_ENB_1202_691_04) oCliente Específico LTE RL40 0.0.3 (LN4.0_ENB_1202_691_11) oCliente RL40 LTE específica 0,1 (LN4.0_ENB_1202_692_07) oLTE RL40 fábrica SW (LN4.0_ENB_1202_696_00)

Actualização do mencionado acima cargas SW para RL40 1.0 SW foi testado e é recomendado atualizar caminho.

7.1.1 Primeira instalação e comissionamento

O procedimento de comissionamento da Flexi Multiradio BTS LTE é descrito no documento "Comissionamento Flexi Multiradio BTS LTE" [3]. Por favor, esteja ciente de que BTS Site Manager devem ser atualizadas antes do BTS SW.

7.1.2 Upgrade / Atualização para RL40 1,0

A atualização SW do Flexi Multiradio BTS LTE pode ser executado seguindo as instruções em o documento "Comissionamento Flexi Multiradio BTS LTE" [3].

Antes da atualização de um eNB é iniciado, deve ser verificado se a seguinte condição for cumprida:

As seguintes condições devem ser cumpridas para que todos os objetos LNCEL se um



6 (19)

Instância LNRELG pertence a ela: - B2threshold1GERAN em MRBTS / LNBTS / LNCEL / LNHOG deve ser definido. - B2threshold1GERAN deve ser maior do que threshold4. - B2threshold1GERAN deve ser menor que threshold2GERAN.

Quando o parâmetro actCellTrace é falsa, então as actPeriodicIntraUeMeas parâmetro deve também ser falsa.

Para resumir as configurações possíveis:

RL30: agir traço celular verdadeiro verdadeiro falso falso

agir medições periódicas verdadeiro falso falso verdadeiro

Está bem Está bem Está bem nok

Isto irá ser convertido em

RL40: agir traço celular verdadeiro verdadeiro falso falso

ato MDT traço celular verdadeiro falso falso verdadeiro

Está bem Está bem Está bem nok

Erros de validação após a atualização para o RL40

Há mudanças implementadas para BTSSM validador em RL40 e pode acontecer que, depois de atualizar haverá erro na validação novo arquivo de colocação em funcionamento. Alguns parâmetros não foram validado em RL30 e eles podem ter valores incorretos (fora da faixa aceita ou ausente). Como em RL40 são verificados por validador é necessário alterá-los para valores permitidos.

Exemplo de erro de validação:

<mensagem> LN4.0 MRBTS-282/LNBTS-282/LNCEL-1 Incomplete configuração: cellReSelPrio Erro Parameter cellReSelPrio (prioridade resseleção celular) valor 7 precisa ser Not_Equal de parâmetro relacionado uCelResPrio (uCelResPrio) no objeto gerenciado UFFIM. </ Message>

Validação PhyCellID

Quando a configuração de PCI em LN3.0 não é mantida gama PCI fora na lista negra e atualização para LN4.0 é feito, LN4.0 BTS Site Manager detecta seguinte erro:

A identidade da célula da camada física (PCI) phyCellId da própria célula não deve estar dentro de qualquer lista negra Gama PCI na lista (IAFIM-intrFrBCList-startIntraPci, IAFIM-intrFrBCList-rangeIntraPci). Isto é causado pela validação PhyCellID incorreto em LN3.0 BTS Site Manager, corrigido no LN4.0 Gerente BTS Site. Esta situação pode acontecer durante a conversão do arquivo SCF comissionamento de LN3.0 para LN4.0 ou ao baixar LN3.0 originais SCF diretamente para LN4.0 BTSSM.

Instruções de instalação LTE_RL40_1.0 A Nokia Siemens Networks © CONFIDENCIAL APROVADO 2.0

7 (19)

Exemplo: Há seguinte configuração no arquivo SCF (encomendado em LN3.0 BTS Site Manager): •gama PCI na lista negra (intrFrBCList) orangeIntraPci = n8 ostartIntraPci = 1 •física Cell ID (phyCellId) são 4, 5, 6 para três células configurados.

Isso significa que phyCellId estão na faixa (intrFrBCList) que não tenha de ser aceito por BTS SiteManager. Este é devidamente detectado em LN4.0 BTS Site Manager mas não no LN3.0 BTS site Manager.

Instruções: Ao configurar Flexi Multiradio BTS LTE em LN3.0 BTS Site Manager, operador precisa verificar manualmente se a identidade da célula física (phyCellId) não está dentro de qualquer gama PCI na lista negra na lista (intrFrBCList-startIntraPci, intrFrBCList-rangeIntraPci).

Configuração da identidade da célula física (phyCellId) é feito em: •Comissionamento \ MRBTS-xxx \ LNBTS-xxx \ identidade da célula \ camada física LNCELL-yyy.

Configuração da faixa de PCI na lista negra na lista é feito em: •Comissionamento \ MRBTS-xxx \ LNBTS-xxx \ LNCELL-yyy \ IAFIM-1 \ Intra-freqüência lista de células na lista negra. Parâmetros configurados: Menor PCI na faixa intra-freqüência Número de PCI na faixa intra-freqüência

PCI ou validação configuração CI, falha de validação possível após a atualização do RL30 para RL40

No caso de haver são duplicados PCI ou configuração CI para configuração da célula vizinho cliente RL30 DB (eNB configurado com PCI duplicado na tabela de mapeamento PCI-IP ou duplicado CI em LNRELG objetos), o cliente irá encontrar validação problema de falha ao tentar re-configurar o eNB depois a atualização para o RL40. A razão é que em RL30, PCI única e CI única para célula vizinha definição não são verificados pelo validador, essa verificação é adicionado em RL40.

Para evitar a questão acima é necessário corrigir a configuração inconsistente manualmente antes de eNB atualizar para RL40 e realizar re-comissionamento. Então provisionamento Plano CM será bem sucedida após o upgrade para RL40.

Alternativamente, é permitido corrigir configuração inconsistente manualmente após a atualização para o RL40. Então provisionamento Plano CM será bem sucedido.

Por causa de uma incompatibilidade menor no modelo de informação entre NetAct e eNB seguinte mensagem de aviso é emitido em NetAct Carregar janela:

Incompatibilidade de conteúdo com metadados detectado. Parâmetros desconhecidos em classes: ============================== PLMN / MRBTS / LNBTS / FTM / PMTNL: [Lte_TOP_PhaseSync_Stats_Interval] 31/08/12 15:03:09: Informações

O upload de arquivo plano é executado, sem restrição quanto a esta mensagem, por favor, ignore-o.



8 (19)

Após a atualização de um eNB um CM Carregar deste eNB em NetAct deve ser executado. Se em RL30 há LNADJW (ou LNADJG) objetos com numeração não a partir de 0 ou não consecutivamente numerada, então pelo NetAct o CM carregamento deve ser executado duas vezes.

7.2 SON

Filho é um conjunto de recursos que permite operador configurar estação base, ligando-o ao rede. Para permitir o uso de instalações FILHO algumas etapas de preparação devem ser tomadas. É descrito na biblioteca de documentação do cliente na seção "Área Funcional Descrição- Operacionalidade-Configuration Management Management-SON "capítulo 4" gestão FILHO "[7]. As descrições e dicas sobre o uso do recurso de SON pode ser encontrada também na documentação do cliente para NetAct.

Resctrictions 1. Quando a configuração de HW é FSME com RL30 2,0 Fábrica SW e FTM com RL10 Fábrica SW (FTM_L10_170.00), então AutoConfiguration com VLAN não está funcionando. Solução: FTM tem que ser atualizado manualmente para um exemplo mais recente do software com BTSSM.

8. SUGESTÕES E RECOMENDAÇÕES OPERACIONAIS

LNADJ estado da instância em falta ou incompletos objeto LNADJ

Causa-raiz é condição de corrida na cadeia NE ENB / IOMS / NetAct para o estado da instância LNADJ atualizar através de dois canais separados: Configuration Change Notificação e rtOperation

Solução: ENB tem sempre informações atualizadas sobre o status do link X2 e possível desalinhamento de LNADJ MOs entre eNB e NetAct pode ser sincronizado via upload do arquivo de configuração pedido.



9 (19)

Instruções para forçar 4X a velocidade de conexão para o módulo FRIG RRH: Um) Desative a Segurança Porta Ethernet com a BTS Gerente, a fim de poder entrar com

telnet para os módulos de RF: Gerente BTS / Ferramentas / Ethernet Segurança Portuária

Desative a porta de segurança.

Agora você é capaz de fazer o que for necessário, mas tenha cuidado.



10 (19)

B) Força 4X a velocidade de conexão para o módulo FRIG RRH via telnet (linhas de comando será escrito diretamente na RF shell Unix e será armazenado permanentemente). 1. Primeiro login com telnet para 192.168.254.129 (primeiro RFmodule), 192.168.254.133 (segundo módulo RF) e, finalmente, 192.168.254 .. 137 (terceiro módulo RF) com a porta 2323. Exemplo: De cmd RUN "telnet 192.168.254.129 2323"

. 2 Digite o comando para a desativação de 8X velocidade do link: RAD-pw 0xEF 1

3. Unidade de redefinir ou reposição do site é necessário. Isso tem que ser feito uma vez para cada unidade Frig. Durante a inicialização as linhas de comando será armazenado automaticamente dentro de unidade de RF / ram.

C) Habilite a porta Ethernet de Segurança com a BTS Manager (veja acima).

Restrição para FSMF Installation Factory mais FTIF

Fábrica nova FSMF ter versão SW LN4.0_ENB_9402_280_00 instalado não deve ser equipado com FTIF antes SW-Update para LN4.0_ENB_1202_XXX_YY. Módulo FSMF irá reiniciar a cada 5 minutos e sem adequada SW download será possível.

Como contornar Se FTIF foi instalado já fisicamente: 1. Desligue FSMF. 2. Remover FTIF Module. 3. Ligar FSMF. Se FTIF é removido FSMF, alarme "Módulo Transporte falta" vai aparecer. SW download irá falhar, uma vez que reconheceu FTIF módulo não pode ser adequadamente instalado. 4. Recuperar FTM precisa ser executado via https://192.168.255.129. 5. Posteriormente iniciar o procedimento de download SW normal sem FTIF a uma carga igual ou SW mais recente que LN4.0_ENB_1202_XXX_YY. 6. Instale FTIF após a reinicialização bem sucedida de FSMF.



11 (19)

SFP troca a quente em FSMF ou FXEB

Se a troca de qualquer conector SFP SFP para outro com uma capacidade de velocidade diferente (hot swap), Unit Radio seja reiniciado e toda a célula vai ao ar sem qualquer alarme ou aviso. Mas tudo RACH tentativas falharem e não configurações de chamada são possíveis.

Solução: Se a conexão SFP foi quente trocados, uma reposição do site é necessária.

NetAct Planfile validação após atualização

Não é possível criar um novo MO em RL40 com NetAct quando existe ainda um arquivo de plano de RL30 que cria / deleta / modifica o mesmo MO ID e quando as mudanças na PDDB para este objeto classe foram feitas em RL40 em comparação com RL30. Instrução: Já não precisava Excluir arquivos de plano RL30 em NetAct antes de começar a criar / modificar / excluir MOs com o mesmo ID no arquivo de plano de RL40. Para encontrar os planos que contêm operador objeto problemático pode em real árvore de objetos, selecione o objeto e no menu pop-up, selecione Lista de planos

Dica Operador para LTE649:

1) Os contadores de desempenho para o TRS FTLB para 'pacotes Ethernet recebidos descartados devido estouro de AF *, BE e EF ' em caso de pacotes descartados devido à formação egresso são nomeados enganosa, uma vez que o tráfego classe, representada pelo valor de DSCP, tem nenhuma solução relação a fila de prioridade escolhido e leva à má interpretação dos exibida valores.

2) Em RL20 e RL30, a configuração de uma VLAN-ID com o valor zero (0) foi possível, violando Padrões IEEE. No caso de um operador usado este valor nos projetos de rede de transporte, é necessário alterar esta configuração de rede com o padrão conforme valores (ie, VLAN-ID 1 ... 4094) antes de migrar para LTE RL40.

Dica Operador para LTE497:

Quando 'aprimorados AC e GBR serviços' são ativados, ou seja, se actEnhAcandGbrServices iguais 'True', é altamente recomendável para configurar gbrCongHandling para 'l2andl3'. Se não configurado como isso, a admissão GBR nas células vazias podem falhar.

Cabeamento: Fibras para módulo de rádio:

As fibras paralelas ao módulo de rádio deve estar de mesmo cabo. Isto assegura que as duas fibras são mesmo comprimento e funciona o sistema. O sistema agora permite max. Diferença 5 metros de comprimento entre as fibras principais e secundárias.

Tamanho da MTU na OMS, CA Server eo servidor LDAP precisa ser reduzido para 1.400 bytes quando IP-Sec é usado:



IPSec requer adicionar. Sobrecarga IP. No caso de o tamanho padrão MTU de 1500 bytes é usado, o IPSec

12 (19)

Gateway precisa fragmentar os pacotes IP antes de criptografia é feito. Algumas aplicações são definindo o 'não fragmentar' bits, que é proibir a fragmentação, mas neste caso o IP pacotes são descartados e não são transferidas a todos. A fim de evitar isso, o tamanho de MTU OMS, CA Server eo servidor LDAP deve ser limitado. Para OMS:

vínculo fsipnet modificar bond0 nó CLA-0 mtu 1400 fsipreconfigure cometer

eNB IPsec IKEv1 Operador multi Túnel Dica:

FTIB e FTLB: Para várias configurações de túnel IPSec com IKEv1, é necessário configurar em eNB dedicada e única sub-redes remotas por túnel nas políticas IPSec. Devido à roteamento baseado endereço de destino eNB interna IPSec daemon varia o endereço de sub-rede não devem sobrepor-se. Configuração IKEv1 válido

A implementação strongSwan atual para IKEv1 não suporta roteamento IP-Source baseado.

Configuração IKEv2 válido (não é possível com IKEv1)



13 (19)

A implementação strongSwan atual para IKEv2 suporta roteamento baseado em IP-Fonte.

IPsec PROTEGER políticas / desvio definição:

Para a configuração de diretivas IPsec no eNB, a seguinte regra precisa ser considerado. Em caso de várias políticas correspondentes IPsec, a regra de política que deve ser aplicada precisa ter um menor número do que a outra política correspondente. O menor número de diversas políticas correspondentes é aplicado pela primeira vez.

Por exemplo, se uma política ampla de proteção é definido (por exemplo, ANY-to-any) e um dedicado tipo de tráfego deve ignorar o túnel IPSec, do que a política BYPASS precisa ser configurado com um menor "Ordem Política Number 'do que a política de proteção.

LTE710 sincronização de interface de PDH LTE713 Synchronous Ethernet LTE134 sincronismo sobre Packet

Se PDH é escolhido como fonte de sincronização e Ethernet Synchronous ou sincronismo sobre Packet como fonte de sincronização secundário, mas nenhum sinal PDH está ligado, em seguida, após um reset eNB o módulo de transporte está encaminhando um relógio interno de módulo do sistema por alguns segundos, antes de o relógio correto derivado de sincronização secundário escolhido é encaminhado. Isso perturba BTS sintonia interna ea palavra seguinte DAC calculado é errado por max. 6 dígitos (Cerca de 5 ppb). A perturbação não é o serviço que afetam. Após 20 minutos a próxima palavra DAC é mais uma vez correto. Isto pode ser seguido pelo gestor de local (sítio Informações> Informações do Site> história sintonia BTS relógio).

ICMP limitação de taxa

A fim de evitar uma interrupção do sistema devido a ataques de negação de serviço (ICMP inundação) a entrada ea saída Taxas de pacotes ICMP são limitadas. Apenas uma explosão de 8 ICMP_ECHO_REQUESTS / ICMP_ECHO_REPLY são permitidos. Se, por exemplo, mais de 8 ICMP_ECHO_REQUESTS são enviados em uma



14 (19)

explosão, eNB só vai responder à primeira 8. Isto é aplicável para o endereço da interface eNB (es) (Ethernet e VLAN).

Medidas LTE574 rede de transporte IP

Configuração do número de Porta UDP do Responder TWAMP

Actualmente, a UDP do TWAMP reflector pode ser configurada livremente no intervalo de 0 a 65535, com um valor padrão de 5000. Configuração gratuito deste parâmetro requer cuidados especiais, uma vez que as entradas podem entrar em conflito com os números das portas que já estão atribuídos a outros aplicações. Por exemplo os números de porta 0 ... 1023 e 5001 ... 5010 são reservados e não deve ser utilizado para a função TWAMP respondedor. Atualmente, o sistema não oferece suporte a uma completa verificação da TWAMP configurado responder número da porta contra todos os outros números de portas utilizados na o sistema.

Para evitar conflitos entre o número da porta UDP TWAMP e outros números de porta, é recomendável usar sempre o valor padrão de 5000. Verificou-se que a flexibilidade configurar o número da porta não fornece um benefício real e usando um valor fixo elimina a possibilidade de mal-configurações.

Transferência de arquivo seguro de IOMS para NetAct:

Se TLSmodeOM = sondagem em IOMS, certificados corretos devem ser instalados em NetAct. Se cert correto não estiver disponível, a transferência de arquivos a partir de uplink IOMS para NetAct falhar. Em caso de problemas de transferência de arquivos de IOMS para NetAct, defina TLSmodeOM = Off no IOMS.

BTS site Representante: Data / hora incluída no nome de falha de transmissão de alarmes é enganosa no Gerenciador de BTS Site. A mesma questão é exibido corretamente em NetAct Alarm Monitor.

Sincronização: •Fonte de relógio mudar de OCXO de relógio recebido da RP3-01 quando o gerente do site operar como um módulo do sistema de extensão, ou como um sistema escravo de sincronização módulo. •No módulo de sistema escravista, a definição sobre a sincronização não é necessária. Sincronização vai ser fixada ao módulo do sistema mestre. •Se o módulo do sistema é sincronizado com módulo do sistema mestre, gerente do site será exibido a fonte de sincronização como "Outros BTS".

Traçar roteamento após a transição para servir IOMS

Se eNodeB está configurado com dois endereços IOMS (uma é a IOMS servindo, o outro a não- servindo IOMS) eo eNodeB foi comutada para os ex-IOMS não servindo como novo servindo IOMS então os traços será rota "conexão trace" via o velho IOMS (agora o não- servindo um) para TraceViewer. Se os IOMS não servindo será seguida de rastreamento do serviço vai em estado de erro, nenhuma nova traços pode ser ativado com sucesso. Isso é válido para "conexão trace" para traço celular (LTE433; LTE162) e traço assinante (LTE 163).

Solução: O eNodeB precisa de um reinício, a fim de rota "conexão trace" através do novo servindo IOMS.



15 (19)

Solução para atualização Trust Anchor (consulte Suporte técnico Nota TS-LTE-SW-0001)

Em RL40 o Flexi Multiradio BTS LTE não é capaz de gerenciar múltiplas âncoras de confiança em um forma automatizada (por meio de CMP) ou configuração NetAct. Assim, uma solução precisa de ser definido para permitir a implantação de uma nova âncora certificado raiz da CA / Confiança.

Normalmente, uma âncora de confiança é válido por 15 anos ou mais. Mas existe uma certa probabilidade de que um operador gosta de trocar de uma primeira inicial (trial) implantação de sistema de PKI final / outro PKI.

definição eNB Parâmetro: dias CA certificado de confiança âncora antes da expiração

O parâmetro eNB "certificado CA e confiança âncora dias antes do vencimento" deve ser definido como o menor valor possível (um dia), para evitar a atualização automática âncora de confiança antes de procedimento manual descrito a seguir pode ser iniciado. Caso de uso: confiança atualização âncora devido a expiração do tempo de renovação CA cert CA cria um novo certificado auto-assinado (CA Cert 2). Este certificado é utilizado a partir de agora para a nova solicitação de assinatura inicial ou atualização pedidos. O CA cert 1 ainda é válido para os certificados de entidade autenticações de todos os certificados assinados com CA cert 1.

Confie seqüência de atualização âncora:

1. 2. 3.

4.

Todos IOMS / SMEAO obter o novo CA cert 2 via configuração manual, CA cert1 ainda em vigor Todos SeGW obter o novo CA cert 2 via configuração manual. CA cert 1 ainda está em vigor Mass comando para acionar procedimento IR em todos eNB (trigger massa de atualização de chave não suportado no RL10, RL20, RL30) Todos eNB obter um novo certificado de operador assinado com CA cert 2 eo novo CA cert 2 via IR procedimento, o ex-CA Cert 1 ainda está em vigor, pois não é substituído / deletado por IR procedimento. O novo certificado de operador eNB é utilizado a partir de agora para IPsec e TLS a. Autenticação sec IP entre eNB e SeGW continua, autentica ENB SeGW com CA cert 1, SeGW autentica eNB com CA cert 2 b. Autenticação TLS entre eNB e IOMS / SMEAO continua, autentica ENB IOMS / SMEAO com CA cert 1, IOMS autentica eNB com CA cert 2 c. ATENÇÃO: todos os uploads de arquivos HTTPS diretamente entre eNB e NetAct falhar agora porque os colegas não tem um novo certificado de entidade ainda. d. Uma exceção é a conexão LDAP segura para CUAA porque não há mútua autenticação, ou seja, o eNB verifica o certificado do servidor LDAP (ainda assinado por CA cert 1), mas não do jeito que outra rodada NetAct (incluindo o servidor CUAA LDAP) obter um novo certificado de entidade assinou com CA cert 2 a. ATENÇÃO: Todos os tipos NE e NE (WCDMA, LTE, MSS), que não se inscreveram a novo certificado de CA CA cert 2 não será capaz de estabelecer novas conexões neste ponto até que os certificados foram matriculados. SeGW recebe um novo cert entidade assinou com CA cert 2, CA cert 1 ainda na piscina confiança a. Autenticação IPsec entre eNB e SeGW continua, autentica ENB SeGW com CA cert 2, SeGW autentica eNB com CA cert 2 Todos IOMS obter um novo certificado assinado com a entidade CA cert 2, CA cert 1 ainda na piscina confiança a. Autenticação TLS entre eNB e IOMS continua, eNB autentica IOMS com CA cert 2, IOMS autentica eNB com CA cert 2 Nova cert operador é usado a partir de agora para IPsec e TLS

5.

6.

7.

8.

Resultados esperados: Todos os nós têm agora uma nova entidade cert assinado com CA cert 2

OH para pendurar empregos provisionamento plano CM



16 (19)

A modificação do referido parâmetro para vários eNBs pode ser realizado com um plano de CM trabalho de provisionamento começou em NetAct e dirigida a vários eNBs. O trabalho consiste em 2 partes, faça o download e ativação plano plano. A ativação do plano é iniciado quando todos os eNBs confirmou a operação de plano de download, normalmente após cerca de um minuto. Se um ou mais eNBs não responda causada por problemas internos, o plano de operação de download deve ser excedido. Isso pode leva bastante tempo, em implementação real de cerca de 45 minutos. Para alcançar a modificação de parâmetros no eNBs restantes tão rapidamente quanto possível, o operador pode iniciar um segundo plano de trabalho CM provisionamento de NetAct utilizando o mesmo plano e CM dirigida aos mesmos eNBs como no primeiro trabalho, mas o com a opção "plano de ativar apenas". O ativação do plano é realizada imediatamente para todos os eNBs, que tinha confirmado a transferência de plano operação a partir do primeiro emprego, e é rejeitado pelas eNBs, que não tinham confirmado o plano baixar operação.

Processo técnico: O primeiro trabalho de provisionamento plano CM, inclusive de download plano e plano de operação de ativação é iniciada da seguinte forma: Aplicação Gerente-Start CM Operação em NetAct -Select plano CM que inclui a modificação parâmetro obrigatório -Menu Iniciar Provisioning em pasta Plano -Selecione como Operação: Preparar, Provisão, Activate

O segundo trabalho de provisionamento plano CM, incluindo ativação do plano só é iniciado na seguinte maneira: Aplicação Gerente-Start CM Operação em NetAct -Selecione mesmo plano CM como em primeiro emprego -Menu Iniciar Provisioning em pasta Plano -Selecione como Operação: Preparar, Provisão, Activate Plano Pré-Ativado

9. CONTROLE DA CONSISTÊNCIA PACOTE


A fim de verificar a consistência do pacote após a atualização Flexi Multiradio BTS LTE SW, por favor assegurar que o procedimento "Atualizar SW para o site BTS" está encerrando com sucesso.

9.2 LTE IOMS

N / D

10. FALLBACK

Por favor note que fallback para RL40 fábrica SW (LN4.0_ENB_1202_696_00) para FSMF A.102 é não é permitido por causa de FSMF uboot limitação downgrate descrito no seguinte nota TS: TS-LTE_BTS_FDD-SW-0042 -> FSMF A102 U-boot rebaixamento não é possível

Só a atualização para versão superior SW é permitido e possível.

Durante a actualização do RL30 RL40 para os dados de configuração são salvos no arquivo SCFBackup.xml arquivo. Em caso de Fallback esse arquivo é reutilizado. Todas as alterações feitas após a atualização será perdido, porque um Fallback sempre inclui também um retorno da configuração. O mesmo também é válido no caso de uma atualização de RL40 X versão para RL40 Versão x +1. Durante Atualização de RL40 X versão para RL40 Versão x +1 os dados de configuração são salvos no arquivo Arquivo SCFBackupMinor.xml. Em caso de fallback para RL40 X versão deste arquivo é reutilizado. Todas as alterações feito após a atualização será perdida em caso de reversão.



17 (19)

11. ANEXOS / Referências

[1] NOLS - Nokia Siemens Networks Serviços Online fazer login na ligação: https://online.portal.nokiasiemensnetworks.com [2] - "Flexi Multiradio BTS LTE Requisitos de Instalação do Site", DN0951839, 03A Issue - "Instalando Flexi Multiradio 10 BTS exterior para Pilha, Parede, e Pole Configurações", DN09107819, Edição 01 - "Cabeamento Flexi Multiradio 10 BTS Outdoor", DN09107822, Edição 01 - "Instalando Flexi Multiradio BTS módulos LTE em armários", DN0951842, 04A Issue - "Instalando Flexi Multiradio BTS LTE Itens opcionais", DN0951854, 04A Issue [3] DN0951893 "Comissionamento Flexi Multiradio BTS LTE", Edição 04A [4] Link para a Nokia Siemens Networks Long Term Evolution Centro de Informações: https://online.portal.nokiasiemensnetworks.com/pic/com/nsn/extranet/pic/controller/productinfovi ? ew / pivdocumentation.do productId = urn: nsn.com: mxpdm :133-047489 & rid = urn: temp: Flexi- LBTS4.0 (LTE Radio Access, Rel. RL40, Documentação operacional, Issue 01) [5] "LTE RAN O & M Segurança" DN0958798, Edição 04A [6] "Atualizando da LTE OMS 3.0 para LTE OMS 4.0" DN0983101, Edição 03 https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D476885615 [7] "Gestão FILHO" DN0944055, Edição 04



18 (19)

Renúncia








19 (19)

Relatório de verificação de atualização SW ID: Solte entrega: Família de produtos: Produto: Lançamento:


LTE_RL40_1.0

RL40 1,0

Estações Base


LN4.0 1.0

17-May-2013


LTE_RL40_1.0 Verificação Documento A Nokia Siemens Networks ©

1 (5)

Confidencial da Empresa

Índice 1. 2. 3. 4. 5. 6.

Propósito ......................................................................................................................................................... 3 Fases de teste e quantidade de casos de teste ....................................................................................................... 3 O ambiente de teste .......................................................................................................................................... 3 Descrição das entidades fase de teste .................................................................................................................. 3 Restantes Falhas Abertas encontrados em testes de ............................................ .................................................. 3 ...... Apêndices / Referências .............................................................................................................................. 4

Contato: Contacte o apoio local da Nokia Siemens Networks





2 (5)

1. PROPÓSITO

Este documento apresenta os resultados dos testes de LTE RL40 entrega 1.0 manutenção.

2. FASES DE TESTE ea quantidade de casos de teste

A tabela abaixo resume as entidades fase de teste realizados e os montantes de teste casos em fase de teste correspondente.

Fase de Teste

Correção de testes

O teste de regressão

Testes de instalação da atualização de software Total

Total

182

1124

62

1368

Passado Taxa passou

182

1119

57

1358

100%

99,6%

91,9%

99,3%

3. Ambiente de teste

O ambiente de teste é construir de acordo com o capítulo "Descrição do sistema" [1] no Cliente Biblioteca de Documentação

4. DESCRIÇÃO DAS ENTIDADES DE TESTE FASE

Teste de Correção

Todas as correções individuais passaram por testes sub-sistema. Todas as correções individuais passaram por testes entidade.

Teste de Regressão

Teste de regressão verifica as partes inalteradas de um produto depois de partes do produto tem foram alteradas. É uma forma de garantir que a alteração não afecta qualquer outra coisa e que não há efeitos colaterais inesperados.

Teste a instalação da atualização de software A meta é validar que a entidade em uma versão mais antiga pode ser atualizado conforme o esperado para a versão a ser lançado. Update foi testado a partir de vários níveis de SW, para obter informações detalhadas informações sobre os caminhos e procedimentos de atualização, por favor consulte o "LTE_RL40 1.0 Instalação Instructions.pdf documento "que faz parte do RL40 versão 1.0 documentação.

5. Restantes FALHAS EM ABERTO ENCONTRADO EM TESTES

Falhas abertas restantes são enumeradas no documento "LGF-LTE-RL40-2013-w20.pdf", que é parte do RL40 1,0 documentação de liberação.



3 (5)

6. APÊNDICES / Referências

[1] "Descrições do Sistema" consiste em: "LTE / EPC Visão Geral do Sistema" DN0943898, "LTE RAN Descrição do Sistema" DN0943905 ", LTE / SAE Interfaces" DN0962158



4 (5)

Renúncia As informações contidas neste documento estão sujeitas a alterações sem aviso prévio e descreve apenas o produto definido na introdução desta documentação. Esta documentação é destinado ao uso de clientes da Nokia Siemens Networks para os fins de o acordo sob o qual o documento é enviado, e nenhuma parte dela pode ser usado, reproduzidos, modificados ou transmitida por qualquer forma ou meio, sem a prévia e por escrito permissão da Nokia Siemens Networks. A documentação foi preparado para ser usado por profissionais e pessoal devidamente treinado, eo cliente assume total responsabilidade ao usá-lo. Nokia Siemens Networks recebe comentários de clientes como parte do processo de desenvolvimento e melhoria contínua da documentação.







5 (5)

Índice PANORAMA ..................................................................................................................................6 Falhas genéricos recém-inaugurado .............................................. .................................................. 7. 2.1 Fábrica SW FRHA redefine a cada 6 minutos .......................................... ................................... 7 2.2 iOMS4.0_ O comando "# omscertificate cmp-init-seqüência" não pode ser com sucesso feito em R_GOMS6_1.82.1.0.release_oms.corr31 instaladas na lâmina HP460G8 .............................. 7 2.3 conflito validação para o parâmetro maxNumRrcEmergency quando actEmerCallRedir e actFlexBbUsage estiverem habilitados .............................................. .................................................. 8 ... 2.4 LN4.0 célula SW defeituoso após o local de reset pelo gerente local ..................................... ......................... 8 2.5 LCGID erro de conversão de parâmetro ao atualizar do 4.0 para RL30 RL40 1,0 .................... 9 2.6 RACH Falha no dia 4 de célula de modo Juntamente banda dupla em FSMF ..................................... ............. 9 2.7 [LTE IOMS RL40] HTTPD desativado após donwgrade de corr30 para corr24 .......................... 10 2.8 Comissionamento Alarme de erro depois que os planos de adjacência foram correu resolvido por recomissiong o sítio ........................................................................................................................................... 11 2.9 QCI1 PDCP Descartar taxa é alta ........................................... .............................................. 11 2.10 eNB não aceitar a mudança de configuração via NetAct ou Site Manager remoto ...................... 12 2.11 FXEB e FSMF-MDDA CS7299220.05 na configuração estado ...................................... ...... 12 2.12 A incapacidade de recuperar arquivo de despejo DSP após BTSOM detectado o reset do DSP .................. 13 2.13 Atualização IOMS RL40 - questões omsswm_install ........................................... .......................... 13 2.14 Atualização IOMS RL40 - omsswm_helper questões ........................................... ......................... 15 Plano 2,15 IOMS de download falhar ...................................................................................................... 15 Alarme 2,16 BTS é necessário resetar (4001) ocorreu após eNB Upgrade. ............................................ 16 2.17 FCM reiniciado repetidamente com razão fora de memória devido ao grande tamanho anormal Arquivo FrequencyHistory.xml ............................................................................................................... 16 2.18 LTE782 CRL0678 LNADJ indisponíveis já existia não pode estar disponível quando LNRELs criadas sobre o valor dos vizinhos Número LTE intraFrequency. ................................. 17 2.19 Os IOMS gerar medição muitos arquivos. .................................................. ............. 17 2,20 versões SW velhas no IOMS ............................................ .................................................. ...... 18 2.21 [UUF RL40 MP1] BTSSM problema de validação após a atualização do RL30 (897_10) para RL40 MP1 (780_10) ........................................................................................................................ 18 3. ABRIR falhas genéricos .................................................................................................................. 19 3.1 Após fallback para RL40 RL30 eNB é esporadicamente não comissionado. ...................................... 19 3.2 Após o módulo de rádio troca o número de série não é atualizada no 'Backup comissionamento arquivo ' ......................................................................................................................... 19 3.3 RL40_LTE524: Falha de implantação remota do endereço IP, IP-porta, URL CA / 's CR e CA Assunto-nome na OMS ....................................................................................................... 20 3.4 polarização errada para falha no módulo de potência e Mains corte de energia .................................. 20 3,5 mainMmeIpAddrSec não atualizado por NetAct ............................................ ............................. 21 3.6 FHDB: relatórios de potência de ruído de 5 a 6 dB mais elevada sobre pc sistema .................................... ........... 21 3.7 Desbloquear de FXEB não for possível, reposição do site é necessária ...................................... ................... 22 3.8 IKEv2 IPsec recodificação: novos valores ESP-SPI não utilizados imediatamente ..................................... 22. 3.9 dados de rastreio do Assinante é perdida durante NWI3 ligação interrupção e não mostrado na TraceViewer ................................................................................................................................... 23 3.10 FRHB: E-TM2 - valor incorreto de PDSCHUser07Power ....................................... ............... 23 3.11 RL40_SEC: garantiu a instalação em modo TLS inesperado com certificado OMS revogada. ................ 24 3.12 tag compartilhada está faltando nos alarmes compartilhados no lado GSM ..................................... .......... 24 3.13 IOMS Autónoma reinicialização ocorreu ............................................. .......................................... 24

1. 2.


3.14 OMS anormais reboot.......................................................................................................... 25 4. Falhas genéricos RECÉM RESOLVIDO ............................................ .................................................. 25 .. 4.1 1232 fatal quando fazer a entrega por muito tempo ......................................... .................................. 25 4.2 Após MME restart eNB está preso no pedido de configuração S1 estado configure não enviou ao MME .......... 26 4.3 FSMr3-LTE1432-eNB queda observada em permitir que o tráfego de recurso de espelhamento. ......................... 26 4.4 Falha na interface do RP3 óptico de alarme devido a FPGA pino de reset capacitância parasita ............. 26 4.5 alta perda de desempenho de rádio na configuração de alta velocidade Multicélula. .................................... 27 4.6 [FSMr2 + FSMr3] AutoReboot após OnAir ......................................... ...................................... 27 4.7 FLDA (MHA) não é comissionado após BTS bloquear / desbloquear ..................................... ............ 28 4.8 FSP3 detecção falhou quando BTS startup ........................................... ................................... 28 4.9 Alarme Failure "na interface do RP3 óptica (0010)" é acionado usando FSM eIF2 para RP3 interface e FTIF eIF3, 4 Sametime. .................................................. ........................................... 28 4.10 PLMN errado em S1 TAI após S1 Entrega ......................................... ................................. 29 4.11 Problema com LTE PS Handover para WCDMA .......................................... ................................... 29 4,12 Baixa throuput TCP (5M) é observada em DL ....................................... .................................... 29 4.13 DTAG Alarme Alinhamento "falha de conexão da camada de transporte em relação X2" / muitos ............. 30 4.14 não pode desbloquear fôrma ......................................................................................................... 30 Faltando 4.15 ativação Plano no log de feedback - reiniciar parcialmente eNodeB necessário ................. 31 4.16 FSMF-NTP Interrupção alarmante com novo módulo ....................................... HW FSMF ........... 31 4.17 certificado Vendedor faltando .............................................. .................................................. 32 .... 4.18 Nenhuma chamada possível após MME interrupção recuperado .......................................... ............................ 32 4.19 FTM reiniciado devido a uma falha SW (SmaAsn1is terminado) ....................................... .............. 32 4.20 FHCCs esporadicamente são perdidas durante a ficha do cabo ótico / teste desligue e células configuradas finalmente vai para defeituoso com 1868 em modo acoplado ......................................... .................................... 33 4.21 ID Fault 2016 Nome Solicitação de Mudança de Autonomous redefinir como ação de recuperação em vez de falha ônibus Baseband ............................................. .................................................. ..... 33 4.22 "Falha na interface do RP3 óptica" alarme foi visto por FRIE-3 após a atualização para 1202_689_00 ................................................................................................................................. 34 4.23 Inter-Vendor HO falha com habilitado ......................................... RoHC .................................... 34 4.24 falha de controle de antena RET relatados com errado ......................................... alarme ............... 34 4.25 perda de memória BTSOM ocorreu quando o módulo RF é bloqueado e desbloqueado repetidamente. ..................................................................................................................................... 35 4,26 eNB reinicialização autónoma devido ao "EFaultId_NoConnectionToUnitAl" (ID: 10) para FSPD observada em um site .......................................................................................................................... 35 4.27 pacote de descarte devido ao protocolo não suportado contado como ifInErrors15 .................................... 36 4,28 E-RAB DR (LTE_5025C) e UEs RRC Conectado (LTE_1076A) aumentou após Atualização RL40 P8 ........................................................................................................................... 36 Arquivos 04:29 não são compactados em eNB e por isso não coletados em IOMS .................................... 36 .. 4,30 DL LTE rendimento com RL40 menor do que o esperado ......................................... ..................... 37 4,31 RACH SSR KPI é "0" após MP3.1.4 SW atualizar .................................... ............................ 37 4,32 RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente. BTS reset está needed....................................................................................................................... 38 4.33 FSMF Precoce Projeto :: 1 +1 +1 com RF Módulo FRHA 20 Mht BW, terceiro setor não é trabalhar .......................................................................................................................................... 38 4,34 FXEB relata alarme "Módulo RF detectou nenhum poder TX em bloco filtro interno" .............. 38 4.35 Pantech móvel Volte ROHC CRC falhar ........................................... ....................................... 39 4,36 FSMF projeto cedo: LTE83: FSMF - Teste Negativo (alarme Fan) - teste falhou ......................... 39


4,37 RF Módulo Bloco de falha ocorreu na BTS Site Manager para a recuperação de RP3 10 após RL40 0.0.2 SW Atualizado ................................................................................................................ 40 Alarme interface de 4,38 X2 (6203), não sendo apagada, porém verdadeira ligação X2 é ........................ disponível 40 4.39 Problema com o contadores M8013C6, -7, - 8, -27) .................................. ............................... 40 4.40 Samsung Gallaxy S3 que apoiou Único Band (5) inter-Frequency HO de 2,1 g a 850M Failure .............................................................................................................................. 41 4.41 FHCAs ficou inicialização falhar depois de atualização de software do MP3.1.4 para MP3.1.5 (SW 4.0.711) ........ 41 Compartilhamento de 4,42 RF cabeamento pode bloquear eNB ........................................... ............................................. 42 4,43 configuração incompleta que incompatibilidade de Recursos celular comissionamento direito arquivo depois eliminação de células .................................................................................................................................... 42 4.44 As células deficientes são causados por alto tráfego - FSP colidiu com falhas 418 ................................. 43 4.45 falha Tx incorreta no MIMO visto em alguns RL40 0.0.3 eNBs .................................... ........... 43 4,46 implementação Murkku-logger para FSMF para salvar o histórico MURKKU ASIC para mais tarde usar 43 4,47 RL40 Aceitação - X2 Atualização da Huawei eliminado Vizinho Relacionamento ........................ 44 Status operacional da célula torna-se 4,48 eNodeB disable devido a BCN nenhuma resposta após 200UE anexada com modelo de tráfego 11 e configuração 7 para 15 minutos ....................................... ........... 44 4,49 RL40 LTE FOA - FALHA NA RP3 OPTICAL INTERFACE ........................................ ......... 44 4,50 FSM3: FSMF A.102 uboot rebaixamento não é possível ...................................... .................... 45 5. RESOLVIDO genérico faults.............................................................................................................. 45 Comandos Momento Subseqüente Avanço com o mesmo valor: 5,1 RL40_LTE459. ......................... 45 5.2 No caso de quando é usado com FSMF FHCC no modo acoplado com FXEB e comprimento entre SM e FHCC é maior do que 12km, chamada não é possível ..................................... .............. 46 5.3 Falha em Recuperar Control_Hot insert_removal de módulo de RF sem BTS Repor ................ 46 5.4 Após a emissão Shutdown célula eNB uma mensagem CCN com a versão LN1.0 .................................... 47 Compensada 5,5 SFN entre FSMr2 e FSMr3 ........................................... ..................................... 47 5.6 1836: EFaultId_ALOvercurrentAl não é visto em BTS Site Manager ...................................... 48 5.7 FSMF última FHCC (1.6.1) e / ou FXEB acoplado (1.6.2) não detectado ............................. ......... 48 5.8 FSMF: RF compartilhando LTE-GSM: Depois de células LTE reposição do site estão desativados, eNB executa BTS redefinição autônoma como ação de recuperação (no caso de 40W células LTE) .................................... ....... 49 5.9 Falha 4039 não é limpo em LTE se o problema é resolvido ...................................... ..................... 49 5.10 FSMF: Unidade de contadores de erro de freqüência superior está incorreta em ascensão e SEM ........................ 50 5.11 alarme ALD não aparece depois de bloquear a RFM. (RET está em estado despercebidos) .................. 51 5.12 Carregar da PM não arquivos desencadeada por eNB no caso de algumas combinações de ativado e desativado tipos de medição ............................................ ................................................. 51 5.13 BTS do Site Manager 3.0 validação PhyCellID incorreta .......................................... ................. 52 Falha no módulo 5,14 LTE RL30 Mp3.1.1 RF (1907) para cerca de 1 segundo presente .......................... 52 5.15 Falha na interface do RP3 óptico de alarme ocorreu devido a KEEPALIVE expirou. .................... 53 5.16 mudanças Site-ID em BTS Manager não visíveis no CM editor ..................................... ............... 53 5.17 eNB redefinição espúrias devido a falta de memória ......................................... ................................... 54 5.18 No PCI alarme duplicação (6307) ocorreu ......................................... .................................... 54 5.19 FSP acidente em tupu F3C2 ............................................ .................................................. ...... 55 5,20 FSP acidente na MAC-PS (F2C1) ........................................ .................................................. 55 .... 5,21 ERAB liberar Contador incompatibilidade ............................................. ............................................ 56 5,22 Frig não pôde ser detectado (falha na interface do RP3 óptico) após eNB desceu com Problemas de GPS .................................................................................................................................... 56 5,23 FSMF eNB reinicialização espontânea no modo dedicado Teste ......................................... .............. 57


5,24 teste do site não é compatível com o software de RL40 eNB ........................................ ....................... 57 5,25 RL20: repetição da falha no módulo RF Alarme ......................................... .................................... 58

Contato:

Contacte o apoio local da Nokia Siemens Networks




1. PANORAMA

Lista de Falhas genéricos descreve os atuais problemas não resolvidos afetando a funcionalidade da Estação Base Flexi LTE, bem como as correcções introduzidas os problemas existentes.

Capítulo 2 lista recém-inaugurado problemas Capítulo 3 enumera os problemas em aberto Capítulo 4 lista recentemente resolveu problemas Capítulo 5 relaciona os problemas resolvidos

As descrições de problemas são estruturadas da seguinte forma:

Título Problema: Título do problema Relatório Problema: Problema número de identificação Existe em: Produtos e software de lançamento em que o problema existe Rectificada no / Correção Alvo: A liberação do produto / de software no qual o problema é tanto fixo ou planejado para ser corrigido Gravidade:

• Critical • Maior • Menor

Impacto para o Cliente: Área de impacto • Capacidade e Desempenho • Novo recurso / funcionalidade • Operação e Manutenção • Segurança • Estabilidade

Descrição: Uma breve descrição do problema e nos casos corrigidos também uma descrição do correção.

PR Em anexo: Relatórios de falhas relacionadas ligados com a mesma causa raiz. Este campo é opcional.

Probabilidade: • Raros: 1-2 casos durante um período de observação • Raramente: algumas vezes durante um período de observação • ocasionais: visto várias vezes (5-10), durante um período de observação • Permanente: ocorrerá sempre quando uma configuração ou um recurso é usado

Solução / Solução: Método para evitar o problema ou minimizar o impacto perante o defeito real descreve correcção está disponível

Impacto ao Operador: Uma descrição do que será o fenômeno provavelmente visto na rede por causa da problema


2. FALTAS GENÉRICOS recém-inaugurado

2.1 Fábrica SW FRHA redefine a cada 6 minutos

Relatório Problema: 103009ESPE04 Existe em: LN4.0 Correção Alvo: aberto Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Teste Cenário Etapas: - Pré-configurado: FSME + FTLB com 2x rel 2.1 FRHA LN4.0_ENB_1202_739_00

Teste Etapas: 1. BTS com LN4.0_ENB_1202_739_00 com no estado ar. 2. Uma rádio FRHA é com fábrica SW. 3. Fábrica SW FRHA corretamente detectado como incompatível Software. . 4 Todo cerca de 6,5 minutos, há FRHA reset: "Unidade de reset autônomo como ação de recuperação", Descrição do problema: BTS com fábrica SW FRHA redefine rádio a cada 6,5 minutos. FRM redefinição é contínuo e atualização FRM SW deve ser iniciado logo após a reinicialização. Em outra caso FRM poderia repor durante a atualização do SW.

Probabilidade: Permanente

Solução / Solução: Não há solução

Impacto ao Operador: BTS com fábrica SW FRHA redefine rádio a cada 6,5 minutos.

2.2 iOMS4.0_ O comando "# omscertificate cmp-init-seqüência" não pode ser feito com sucesso em R_GOMS6_1.82.1.0.release_oms.corr31 instalados no HP460G8 lâmina

Relatório Problema: 123188ESPE02 Existe em: LN4.0 Correção Alvo: aberto Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Comando para solicitar novos certificados de servidor cmp (CMP-init-seqüência) não funcionar corretamente devido a falta de diretório / tmp / SS_CertMan. Não é possível solicitar novo certificado.

Repetição: Permanente

Solução: CertMan reiniciar com comando # Fshascli-rn / CertMan irá restaurar diretório necessário e cmp-init-seqüência estará trabalhando.

© Nokia Siemens Networks Confidencial da Empresa 7 (59)

A segunda maneira é criar / tmp / SS_CertMan manualmente com o comando # Mkdir / tmp / SS_CertMan

Efeitos sobre a operadora: O operador não pode solicitar novos certificados de servidor cmp.

2.3 conflito validação para o parâmetro maxNumRrcEmergency quando actEmerCallRedir e actFlexBbUsage são ambos habilitado

Relatório Problema: 41625ESPE05 Existe em: LN4.0 Correção Alvo: RL40 2,0 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Pré-requisito: BTS Encomendado e no ar, teste de cenário Passos 1.1 Reconfiguração da BTS para permitir a "chamada de emergência ativo via sentido" 1.2 Não há erro de validação "Parameter maxNumRrcEmergency (número maxinum RRC ) Valor de emergência 420 precisa de ser BIGGER_OR_EQUAL a 440 porque parâmetro actEmerCallRedir em LNBTS objeto tem o valor igual a Enabled "para o LNCell. 1.3 Modifique o Parâmetro maxNumRrcEmergency a 440 1.4 Não é novo erro de validação "Parameter maxNumRrcEmergency (número maxinum ) Valor RRC emergência 440 precisa de ser SMALLER_OR_EQUAL a 420 porque parâmetro actFlexBbUsage em LNBTS objeto tem o valor igual a true ", o esperado comportamento é: . A validação for bem sucedida, o comportamento observado é: Há conflito para a validação de parâmetro maxNumRrcEmergency quando ambos actEmerCallRedir e actFlexBbUsage estão habilitados, Análise.: De acordo com PDDB, parâmetro maxNumRrcEmergency é restrita a metade se actFlexBbUsage é 'true'. E maxNumRrcEmergency é impactado se actEmerCallRedir é definido como 'Ativado' (cálculo em maxNumRrcEmergency). Há conflito para o validação dos maxNumRrcEmergency quando ambos actFlexBbUsage e actFlexBbUsage são ativado.



Impacto ao Operador: Conflito de validação para o parâmetro maxNumRrcEmergency quando actEmerCallRedir e actFlexBbUsage estiverem habilitados

2.4 LN4.0 célula SW defeituoso após o local de reset pelo gestor do site

Relatório Problema: 41928ESPE05 Existe em: LN4.0 Correção Alvo: RL40 2,0 Gravidade: B - Maior


Impacto para o Cliente: Manutenção Operação e

Descrição: 1. Teste Cenário Passos - FHCA Encomendado com FSME pelo gerente do local. - Após o comissionamento final, todo o estado celular está funcionando e bom. - Reposição do site pelo gerente local, a seguir à célula defeituosa mostrou no gerenciador de site e vai AutoRestart depois de 5 ou 7 minutos sempre., 2. descrição da falha -. Celular com defeito após o local de reset pelo gestor do site, 3 Análise - A versão antiga LN4.0_ENB_1202_713_00 sem este problema, também tentei com outro HW (FXFA) com _764_00, mesmo defeito celular.



Impacto ao Operador: Defeituoso celular após o local de reset pelo gerente local

2.5 LCGID erro de conversão de parâmetro ao atualizar do 4.0 para RL30 RL40 1,0

Relatório Problema: 42397ESPE05 Existe em: LN4.0 Correção Alvo: RL40 2,0 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Após a atualização do 4.0 para RL30 RL40 1,0 a eNB queixar LCGID incorreta parâmetro. , Se o parâmetro schedulType = NÃO GBR com a lista de valores: qciTab5 e lcgid = 2, NÃO é permitido ea validação não é aceite. O tipo de programação obrigatória ser configurado para schedulType = SINALIZAÇÃO., há implementou mudanças para BTSSM validador em RL40 e pode acontecer que após a atualização não haverá erro na validação de novo comissionamento de arquivo. Alguns parâmetros não foram validados no RL30 e eles podem ter valores incorretos (fora da faixa de aceite ou falta). Como em RL40 são verificados por validador é necessário mudá-las com os valores permitidos.


Solução / Solução: Altere os parâmetros problemáticos para valores permitidos.

Impacto ao Operador: Erros de validação após atualizar para RL40.

2.6 RACH Falha no dia 4 de célula de modo Juntamente banda dupla em FSMF

Relatório Problema: NA05350758 Existe em: LN4.0 Correção Alvo: RL40 2,0 Gravidade: B - Maior



Descrição: Quando BTS está configurado o modo acoplado dual band, existem 6 células e cada célula tem cobertura célula-mãe e cobertura celular repetidor. Cobertura celular Mãe significa que UE está conectar chamadas na faixa singal RU. Cobertura de celular repetidor significa que UE está se conectando chama no alcance do sinal do repetidor que está ligado ao FHCC. Com isso as células de configuração 1, 2, 3, 5, 6, é bem sucedido para conectar chamadas, mas para a célula 4, não é possível fazer uma chamada. UE enviar continuamente Rach, mas nenhuma mensagem (mesmo msg1) é visto na célula 4., Descrição do a falha: Erro de incompatibilidade Timestamp é observado na soma interruptor nó roteador em alguns dos configurações na unidade FHCC, o que significa que nós definiu seu playout_start compensar sinais de uma maneira que resulta em RP3 timestamp mensagem mudança relativa transmitida vírgula k28.7 personagem em direção uplink. Cálculo de desvio de sinal Playout_start depende de numerosos definições na BTS integrais. Percebeu-se que a configuração baseada FSMF é potencialmente mais vulnerável para esta questão como Módulo do Sistema FSMF não é capaz de compensar diferenças temporárias / atrasos introduzidos pela Numa tal configuração, tanto quanto FSME faz.


Solução / Solução: Como solução, uma restrição a seguir será usado: "Repetidor Delay "valor do parâmetro pode ser usado na faixa 0-59 nós. Correção completa está relacionada com a sintonia fina da Rádio Módulo e Módulo Sistema horários (60 - Uso 100US parâmetros serão tratadas com a correção completa concluído).

Impacto ao Operador: Nenhuma chamada possíveis no modo dual band na configuração FHCC para celular 4.

2.7 [LTE IOMS RL40] HTTPD desativado após donwgrade de corr30 para corr24

Relatório Problema: NA05351257 Existe em: LN4.0 Correção Alvo: opnen Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: Durante as operações de gerenciamento de software OMS OMS deixa de ouvir de ambos os endereços IP (Serviço HTTP), o que leva a transferências de arquivos através do protocolo http fracasso.

Probabilidade: Ocasional

Solução: Execute as seguintes (3) scripts como usuário root: # Sim | cp-vf / opt / Nokia / SS_OMSINST / script / start_script.sh / opt / Nokia / SS_HTTPDPlat # Rm-rf / tmp / HTTPDPlat # Fshascli-rn / HTTPDPlat Depois disso, a OMS deve escutar em ambos os endereços IP na porta 80 e 443.,

Efeitos sobre a operadora: As transferências de arquivos sobre HTTP / HTTPS não funciona.


2.8 Comissionamento Alarme de erro depois que os planos de adjacência foram correu resolvido por recomissiong sítio

Relatório Problema: NA05352498 Existe em: LN4.0 Correção Alvo: aberto Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Planos de adjacência foram correu e causar alarme erro comisiong no site. Podemos recuperar o site por recomissioning o site. Sua vem acontecendo muito oftern. NetAct OSS5.4 CD Set 2, LN4.0_1202_759_00 gerente do site


Solução / Solução: Recommisioning site

Impacto ao Operador: Comissionamento de alarme de erro depois que os planos de adjacência foram correu

2.9 QCI1 PDCP Descartar taxa é alta

Relatório Problema: NA05353595 Existe em: LN4.0 Correção Alvo: RL40 1,1 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: [PROBLEMA do campo] QCI1 PDCP Descartar Taxa é de cerca de 0,08 ~ 0,17% após a aplicação 691_00 em rede ao vivo. Formula é (PDCP_SDU_DISC_DL_QCI_1 (Lcelld) / PDCP_SDU_DL_QCI_1 (Lcelld))., [REPRODUÇÃO do laboratório] para 2 eNBs (com base em 691_00), teste intra-freqüência caso HO laboratório. Apenas uma chamada VoLTE usado para teste. Resultado do teste é PDCP_SDU_DISC_DL_QCI_1 = 6 em PDCP_SDU_DL_QCI_1 = 552.



Impacto ao Operador: Alta QCI1 PDCP Descartar Taxa


2.10 eNB não aceitar a mudança de configuração via NetAct ou Gerenciador Remoto do Site

Relatório Problema: NA05355177 Existe em: LN4.0 Correção Alvo: aberto Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Alguns eNBs foram descobertos para não aceitar uma alteração de configuração de NetAct ou via Gerenciador Remoto Site. O site requer um reset para aceitar uma mudança de configuração., Este foi descoberto durante a execução de Otimização de RF em uma rede pré lançamento.


Solução / Solução: Reposição do site.

Impacto ao Operador: eNB não aceitar uma alteração de configuração de NetAct ou via remota Site Manager

2.11 FXEB e FSMF-MDDA CS7299220.05 em estado de configuração


Descrição: Liberação SW são: Flexi Multiradio BTS LTE: - ENB: LN4.0_ENB_1202_691_03 - BTS site Representante: BTS_Site_Manager_LN4.0_BTSSM_1202_759_00, LTE IOMS: R_GOMS6_1.82.1.0 + todos os Corrs até Corr30

Configuração do site: 3 Sector, FSME + + FTIF FXEB, alimentador de 25 metros, MHA MDDA (Código do Produto CS7299220.05) RET (Código do Produto 86010147): MDDA CS7299220.05 - versão SW A_VE220V003 RET 86010147 - FW_V02.03.01

Quando carregar o DB os MHAS permanece em estado de configuração, nesta situação a DB não é disponível e não pode executar qualquer ação recomissionamento. A única maneira de sair da este comportamento é para excluir o arquivo em SCF / rom / config e reiniciar o eNB.

Nós tentamos com um MDDA (Produto Código CS7299220.04) sem RET conectado a Setor 2 com um pequeno alimentador e ele funciona bem.


Solução / Solução: excluir o arquivo em SCF / rom / config e reiniciar o eNB


Impacto ao Operador: MHAS permanece em estado de configurar quando o DB é carregado

2.12 A incapacidade de recuperar arquivo de despejo DSP após BTSOM detectado o reset do DSP


Descrição: O fracasso da recuperação de arquivo de despejo DSP após BTSOM detectada a reposição de DSP. Nós não poderia obter o arquivo de despejo DSP na maioria das fotografias tiradas após os eventos.



Impacto ao Operador: A falha de recuperação de arquivo de despejo DSP

2.13 Atualização IOMS RL40 - questões omsswm_install

Relatório Problema: NA05358993 Existe em: LN4.0 Correção Alvo: aberto Gravidade: C - Minor Impacto para o Cliente: Operação e Manutenção, Operacionalidade

Descrição: Durante a execução de atualização de IOMS em ambiente de laboratório de clientes de RL30 MP4 (R_GOMS6_1.27.1.1_release_omsCorr39) para RL40 P8 (R_GOMS6_1.82.1.0_release_omsCorr30) estávamos enfrentando alguns problemas para a instalação de incrementos em cima da etapa de atualização principal (corr19). - Ativação de corr30 falhou em situação dedicado - Remoção conjunto passiva falhou em situação dedicado

Solução de problemas foi feito com o apoio de Andreas em Ulm. Como resultado pls. em anexo, as seguintes questões (AE) que precisam de ser adaptado como solução em novo omsswm_install ferramenta ou marcado como solução alternativa / operador sugere Lançamento documentação.

Nota: Com seguindo as soluções mencionadas nas recomendações abaixo nenhum problema observados para atualização de segunda IOMS em ambiente de laboratório!

A) Ferramenta de instalação omsswm_install permite o máximo de 4 conjuntos (1 ativa e passiva 3), mas não verificar com antecedência


- Verifique se há número de conjuntos é apenas marcada no final do script. Em caso de demais sets a instalação-un é tentado automaticamente.

Problema: Se falhar o sistema está em estado indefinido. - Solução: A ferramenta deve executar cheque de número de jogos no início. (Pf também referem-se a emitir B)) - Solução: OH: [Verificar manualmente com antecedência e retire antigo conjunto, se necessário]

B) Ferramenta de instalação omsswm_install torna automático un-instalação de conjunto de idade. - Ferramenta de instalação omsswm_install permite o máximo de 4 jogos (1 ativa e passiva 3). Ele verifica após a instalação se o número máximo de conjuntos é atingido. Se há muitos define um un-instalação automática do conjunto mais antigo é tentado.

Problema: O conjunto mais antigo poderia ser o conjunto ativo ou um conjunto que você deseja manter. - Solução: A ferramenta deve dar a escolha que definido para excluir ou para abortar. (Pf consulte também questão A)) - Solução: OH: [Verificar manualmente com antecedência e retire antigo conjunto, se necessário]

Ferramenta C Instalação) desinstalação omsswm_install automática do conjunto velho falhou em estado de divisão - Com a criação do novo conjunto com o número "5" omsswm_install-ferramenta está tentando automaticamente para desinstalar um conjunto de idade. Problema: A execução deste passo no modo de divisão failes como omsswm_install não reconhece - Opção única. - Solução: Verifique o status do disco para determinar se o parâmetro único é necessário e fornecer parâmetro único para a desinstalação com omsswm_helper. - Solução 1: OH: [Verificar manualmente com antecedência e retire antigo conjunto, se necessário] - Solução 2: OH: [Se omsswm_install falhou, remova instalado definir manualmente] (adicional instruções necessárias para esta solução alternativa)

D) omsswm_install verifica espaço em disco no disco errado Problema: verificação de espaço em disco é sempre executada por c0d0p1 disco, portanto, em estado de divisão esta faz não ajudar! - Solução: Verifique o status do disco e, em seguida, verificar disco desbloqueado em omsswm_install ferramenta. - Solução: OH: [verificar manualmente espaço em disco antes de executar omsswm_install ferramenta] E) omsswm_install cheques diskspace com (muito pequeno) valor padrão. Problema: omsswm_install assume que não há espaço suficiente, se 24MB são livres para requiredBootFree. - Solução: Alterar o valor padrão usado para a rotina de verificação em omsswm_install ferramenta. (100MB é suficiente) - Solução: OH: [verificar manualmente espaço em disco antes de executar omsswm_install ferramenta]

Probabilidade: Permanente,

Solução: C - Para a remoção de conjunto de software, quando um disco OMS está bloqueado, este comando pode ser utilizados: fsswcli - set-remove - single "SW set name" D - n / a E - n / a,

Efeitos sobre a operadora: Incapacidade de escolher nível necessário para correção OMS


2.14 Atualização IOMS RL40 - omsswm_helper questões

Relatório Problema: NA05359585 Existe em: LN4.0 Correção Alvo: aberto Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: Durante a execução de atualização de IOMS em ambiente de laboratório de clientes de RL30 MP4 (R_GOMS6_1.27.1.1_release_omsCorr39) para RL40 P8 (R_GOMS6_1.82.1.0_release_omsCorr30) estávamos enfrentando alguns problemas para a instalação de incrementos em cima da etapa de atualização principal (corr19). - Ativação de corr30 falhou em situação dedicado - Remoção conjunto passiva falhou em situação dedicado

Solução de problemas foi feito com o apoio de Andreas em Ulm. Como resultado pls. em anexo, as seguintes questões (AB) que precisam de ser adaptado como solução em novo omsswm_helper ferramenta ou marcado como solução alternativa / operador sugere Lançamento documentação.

Com seguindo as soluções mencionadas nas recomendações abaixo nenhum problema observados para atualização de segunda IOMS em ambiente de laboratório!

A) omsswm_helper não pode remover um conjunto único no estado Problema: omsswm_helper não aceita parâmetro "single". - Solução: adaptar ferramenta omsswm_helper aceitar parâmetro "single" para todos relacionados funcionalidades - Solução: OH: [executar manualmente comando: fsswcli-s-r-s]

B) omsswm_helper - / opt / Nokia_BP / SS_SWMan / bin / set / ativar verificações sempre c0d0p1 (Com du-s "$ SET_IMG_PATH / $ SET também arquivos vinculados duro contados) Problema: Verificar c0d0p1 não ajuda em estado de divisão, pois isso é o disco bloqueado. Se disco bloqueado estiver cheia, você não pode instalar no disco desbloqueado.


Solução: A - Para a remoção de conjunto de software, quando um disco OMS está bloqueado, este comando pode ser utilizados: fsswcli - set-remove - single "SW set name" B - Verificação de espaço livre é realizada na partição correta, Descrição da correção (Análise de risco incluído): A - Agora, o parâmetro "single", está disponível,

Efeitos sobre a operadora: Incapacidade de escolher nível necessário para correção OMS

Plano 2,15 IOMS de download falhar

Relatório Problema: NA05360011 Existe em: LN4.0 Correção Alvo: RL40 1,1


Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Cenário Upload / download falhar devido a incorreta número de seqüência de tempo limite. O problema está acontecendo quando o tempo de atividade em IOMS é cerca de 49 dias.

Repetição: Ocasional.

Solução: Recomeço do sistema OMS.

Efeitos sobre a operadora: Funcionalidade Plano de upload / download não funciona.

Alarme 2,16 BTS é necessário resetar (4001) ocorreu após eNB Upgrade.


Descrição: BTS é necessário resetar alarme (4001) ocorreu após eNB upgrade do RL30 MP3.1.3 para RL40 MP0.0.3, a freqüência de emissão - 18 de um total de 491 eNBs


Solução / Solução: eNB redefinição

Impacto ao Operador: Redefinir necessário BTS após a atualização eNB.

2.17 FCM reiniciado repetidamente com razão fora de memória devido ao grande tamanho anormal Arquivo FrequencyHistory.xml


Descrição: FCM reiniciado repetidamente com razão fora de memória devido ao grande tamanho anormal Arquivo FrequencyHistory.xml eNB redefinir continuamente quando chegar instantâneo devido ao grande arquivo FrequencyHistory.xml.




Impacto ao Operador: eNB redefinir quando chegar instantâneo devido à grande FrequencyHistory.xml arquivo

2.18 LTE782 CRL0678 LNADJ indisponíveis já existia não pode estar disponível quando LNRELs criadas sobre o valor dos vizinhos Número LTE intraFrequency.

Relatório Problema: NA05365096 Existe em: LN4.0 Correção Alvo: aberto Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: CRL0678 LNADJ indisponíveis já existia não pode estar disponível quando LNRELs criado sobre o valor dos vizinhos Número LTE intraFrequency., pré-condição. HO: eNB61/LNCEL311 - eNB 63/LNCEL331 Vizinhos Número LTE intraFrequency = 0. eNB61 já tem LNADJ-60 (eNB63, não disponível), 1) O número de LNRELs criado é 17., O resultado esperado S1 HO é realizada LNADJ-60 foi alterado para disponível., Resultado real S1 HO é realizada Não há ENBC_SONConfigurationTransfer após A3MR. LNADJ-60 permanece indisponível., 2) O número de LNRELs criado é 15., O resultado esperado = Resultado real. S1 HO é realizada ENBC_SONConfigurationTransfer foi enviado após A3MR. LNADJ-60 foi alterado para disponível.



Impacto ao Operador: LNADJ já existia não pode estar disponível quando LNRELs criado sobre o valor dos vizinhos Número LTE intraFrequency

2.19 Os IOMS gerar medição muitos arquivos.

Relatório Problema: NA05370166 Existe em: LN4.0 Correção Alvo: RL40 1,1 Gravidade: B - Maior Impacto para o Cliente: Operação e Manutenção, operacionalidade

Descrição: OMS gera muitos arquivos o que causa problemas de desempenho em NetAct. NetAct tem problemas de desempenho e não entregar os dados de medição de tempo.


Armazenamento de arquivos IOMS deve ser feito uma vez por período de poupança. OMS fazer isso várias vezes em cada período de armazenamento.



Impacto ao Operador: As medições não estão disponíveis em NetAct no tempo.

2,20 versões SW velhas no IOMS


Descrição: A verificação de segurança dos IOMS com seguintes findnings (patching insuficiente) foi feito: Versões antigas SW são usados em OMS: RHEL 5.7, Kernel 2.6.18, 2.0.5 Vsftp, OpenSSH 4.3p, MySQL 5.1.66 É necessário Update para versões mais recentes.



Impacto ao Operador: Risco de segurança devido às versões SW velhos no IOMS

2.21 [UUF RL40 MP1] BTSSM problema de validação após a atualização do RL30 (897_10) para RL40 MP1 (780_10)

Relatório Problema: 42742ESPE05 Existe em: LN4.0 Correção Alvo: RL40 1,1 Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Após a atualização a partir de RL30 RL40, parâmetro actMDTCellTrace é automaticamente definido como verdadeiro, mesmo se cellTrace é definida como false. Isso causa o erro de validação: Parâmetro actMDTCellTrace (Activate MDT traço celular) valor verdadeiras necessidades para ser igual a falsa porque o parâmetro actCellTrace em LNBTS objeto tem o valor igual a false.


Solução / Solução: Para definir o traço de célula (parâmetro actCellTrace) por eNB em verdade antes de fazer a atualização.


Impacto ao Operador: Não possível planejar provisionamento após a atualização antes de mudar actMDTCellTrace parâmetro para valor correto.

3. ABRIR FALHAS GENÉRICOS

3.1 Após fallback para RL40 RL30 eNB é esporadicamente não comissionado.


Descrição: eNB é OnAir com RL40. Iniciar manualmente um fallback para RL30., In eNB alguns traços celulares foram criados e para estes traça o parâmetro "modo de rastreamento de células" era falsa. Em NetAct havia um script ativado que tenta excluir e recriar os traços de células com "Modo de rastreamento de células" iguais falsos a cada 15 minutos., Esporadicamente após o retorno do eNB é nem mais comissionados e não mais OnAir.


Solução / Solução: Não execute SW upgrade / fallback em paralelo com a operação CM.

Impacto ao Operador: Quando atualização SW / fallback é feita em paralelo com a operação CM esporadicamente o eNB se não comissionado. Operador tem que entrar um backup do comissionamento de arquivo.

3.2 Após o módulo de rádio troca o número de série não é atualizada no 'Backup comissionamento arquivo '

Relatório Problema: 100308ESPE04 Existe em: LN4.0 Correção Alvo: RL50 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Depois de módulo de rádio swap (troca FXEB) o arquivo de backup comissionamento ainda mostra a série número do módulo de rádio velho que foi retirado. Deve ser atualizado automaticamente. Também outras alterações de configuração de HW (por exemplo, a remoção de um módulo RF) não são atualizados para o comissionamento arquivo de backup, uma reposição do site é necessário para obter um comissionamento backup atualizado arquivo. Probabilidade: Permanente

Solução / Solução: Reinicie o site.


Impacto ao Operador: Após RM troca o número de série não é atualizada no 'Backup comissionamento de arquivo.

3.3 RL40_LTE524: Falha de implantação remota do endereço IP, IP-porta, URL CA / 's CR e CA Assunto-nome na OMS

Relatório Problema: 101269ESPE04 Existe em: LN4.0 Correção Alvo: RL40 1,1 Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: Falha de OMS_EFS_LTE524_RAN2267_27 Caso de Uso: A implementação remota Missa do endereço IP, IP-porta, URL CA / 's CR e CA Assunto-nome na OMS Atores: OMS, NetAct, Usando segmento n3factmx em NetAct para definir endereço IP CA / 's CR, IP- porto, URL e CA Assunto-nome no OMS n3factmx-flt PLMN-PLMN/OMS-44 fragmento CERTH set-baseId N3MD-OMS-44 - localMOIDs DN: NULL-0-u-p Nemuadmin nemuuser-cmpServerIpAddress 10.8.207.54 - cmpServerPort 8080-cmpRecipient 'C = FI, O = NSN, CN = MRTAmpereNewRootCA'., Comando falhou com erro: não é possível definir parâmetros OMS CertMan, implementação remota. de NetAct: É possível configurar todos os parâmetros relacionados com o cliente CMP juntos; é possível definir e PSK Sozinho refnum; Mas não é possível definir endereço IP, IP-porta, URL CA / 's CR e CA Assunto-nome; E não é possível definir CA Assunto-nome sozinho.



Impacto ao Operador: Comando para implantar endereço IP, IP-porta, URL CA / 's CR e CA Assunto-nome na OMS não

3.4 polarização errada para falha no módulo de alimentação e corte de energia à rede


Descrição: Polaridade de alarmes EAC FaultID_1412 "corte de energia à rede" e FaultID_1413 Power " Falha no módulo "é errado no módulo FSMF.



Solução / Solução: Necessário só para FSMF: Mudança de polaridade para alarmes FaultID_1412 "Mains corte de energia" e FaultID_1413 "falha no módulo Power" manualmente.

Impacto ao Operador: No caso de a solução não for aplicada (polaridade alarme configurado a partir de "Normalmente aberto" para "normalmente fechado" o comportamento de EAC FSMF não está de acordo com a documentação do cliente. Alarmes podem ser exibidos como ativo, mesmo se não há real problema existente.

3,5 mainMmeIpAddrSec não atualizados por NetAct

Relatório Problema: 120104ESPE02 Existe em: LN4.0 Correção Alvo: aberto Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: mainMmeIpAddrSec não é atualizado para anular quando mainMmeIpAddrPrim é alterado com um valor levando uma mainMmeIpAddrSec vazio. mainMmeMainCode, mainMmeMainGroupId, mainMmeMainMcc e mainMmeMainMnc também não são atualizados.


Solução / Solução: Operações CM NetAct Gerente de Upload.

Impacto ao Operador: mainMmeIpAddrSec, mainMmeMainCode, mainMmeMainGroupId, valores mainMmeMainMcc e mainMmeMainMnc erroneamente exibido no lado NetAct.

Relatórios de potência de ruído de 5 a 6 dB mais elevados mais de pc sistema: 3.6 FHDB


Descrição: - Poderes de ruído relatados são em torno de-101dBm a-102dBm - BTS é atualizado para a mais recente criação, - poderes de ruído relatados são-95dBm a 96dBm que maior do que o esperado (-101dBm para-102dBm) para celular 10Mhz BW, - De acordo com RFM-FSM especificação de interface, existe e Exception para a variante de freqüência de 900Mhz RF (por exemplo Rel3.2 RENO FHDB), RxPowerScaling deve ser-120.31dBm - Então "Rx.Power.Scaling" é fixado no novo BPF que lançou em LN4.0 ENB 1201 376 00 - Parece novo Rx.Power. Escala é necessário sincronizar com RF SW também.




Impacto ao Operador: Limitação para UL Power Control, Ligação de Adaptação, Referência Som Signal, Throughput em borda da célula será limitado por causa do alto nível de ruído (de 5 a 6 dB adicional).

3.7 Desbloquear de FXEB não for possível, reposição do site é necessária


Descrição: Configuração partilha RF eNB FSMr3 1 +1 +1 H-tipo de configuração (L111-H-9-2TX-2RX) 10MHz/20W 2G ESMB, FIQB 4 +4 +4 config/20W, - eNB trabalhando todas as células são OnAir - Bloquear um dos dois módulos de RF (FXEB) - Desbloquear o módulo RF (FXEB), o módulo de RF não está se preparando após desbloquear. Informações de BTSSM: FXEB 1.1.1 não pode ser desbloqueado. Tente novamente mais tarde. O mesmo procedimento é trabalhar com FSMr2 e FXEA.


Solução / Solução: Reposição do site

Impacto ao Operador: Módulo RF bloqueado não pode ser desbloqueado, reposição do site é necessário.

3.8 IKEv2 IPsec recodificação: novos valores ESP-SPI não for utilizado imediatamente

Relatório Problema: 72217ESPE04 Existe em: LN4.0 Correção Alvo: aberto Gravidade: C - Minor Impacto para o Cliente: Novo recurso / funcionalidade

Descrição: Para FTIB e FTLB: Durante IKEv2 recodificação eNB não toma novos valores SPI imediatamente em conta, de modo SEC-GW pode soltar alguns poucos pacotes.



Impacto ao Operador: Operador observa alguma pequena perda de pacotes.


3.9 dados de rastreio do Assinante é perdida durante NWI3 ligação interrupção e não mostrado na TraceViewer


Descrição: Dados de rastreamento de Assinante (ENB: modo de arquivo) deve ser visível em NetAct TraceViewer. Normal caso é ok. Durante a interrupção da ligação entre NWI3 IOMS e NetAct, dados de rastreio é armazenado em IOMS [Está bem]. Depois de arquivo de rastreamento recuperação ligação é transferida para NetAct mas os dados não estiver visível na TraceViewer. [NOK] Novos dados de rastreamento de chamada após a recuperação da ligação é visível na TraceViewer como esperado. [Ok], Neste execução de teste, NWI3 ligação interrupção foi causada pelo bloqueio do tráfego IP no roteador Cisco. , Mas mesmo problema era visível em outro teste, quando interromper a ligação por "bloqueio / NWI3Adapter "em IOMS. Probabilidade: Ocasional


Impacto ao Operador: Dados de rastreio do Assinante é perdida durante NWI3 ligação interrupção e não mostrado na TraceViewer.

3.10 FRHB: E-TM2 - valor incorreto de PDSCHUser07Power


Descrição: - BTS é OnAir - Enter para testar estado dedicado - Modelo de ensaio de arranque 2 em 1 célula - Modelo de teste de parada, valor errado para PDSCHUser07Power. Espera poder [db] = 0,0; -,512958647714174 (Real). Excedeu o desvio + / -0.5 especificado pelo 3GPP documentação.




Impacto ao Operador: Precisão do nível de potência 3GPP não foram totalmente cumpridas durante o teste mdel execução

3.11 RL40_SEC: garantiu a instalação em modo TLS inesperado com certificado OMS revogada.

Relatório Problema: 90386ESPE01 Existe em: LN4.0 Correção Alvo: RL40 2,0 Gravidade: B - Maior Impacto para o Cliente: Segurança

Descrição: Ocasionalmente eNB não conseguiu verificar um certificado OMS revogada contra a CRL e estabeleceu uma conexão TLS seguros, quando próprio certificado da BTS também está presente no CRL.

Em um cenário improvável, em que ambos os cerfificates de ENB e IOMS foram revogados ea ENB não recebeu um certificado atualizado, as conexões remotas via OM alegou IOMS utilizando certificado IOMS revogada serão aceitas e TLS sessão será erroneamente estabelecida. , Solução: fornecer um certificado válido para o ENB impedirá TLS aperto de mão usando o certificado IOMS revogada

3.12 tag compartilhada está faltando nos alarmes compartilhados no lado do GSM


Descrição: Na configuração do compartilhamento de RF os alarmes emitidos para os recursos compartilhados devem conter a tag compartilhado como informações adicionais. Esta marca compartilhada adicional é fornecido na compartilhado alarmes do lado do LTE, mas está faltando no lado do GSM. Probabilidade: Permanente

Solução / Solução: A tag partilhada adicional pode ser verificado nos alarmes LTE.

Impacto ao Operador: No lado GSM informações compartilhadas está faltando em alarmes compartilhados.

3.13 IOMS Autónoma reinicialização ocorreu


Relatório Problema: NA05328388 Existe em: LN4.0 Correção Alvo: RL40 1,1 Gravidade: C - Minor Impacto para o Cliente: Operação e Manutenção, Operacionalidade

Descrição: IOMS-2 servidor blade foi automaticamente reiniciado devido a mysql caiu. OMS restart foi desencadeada pelo Plano CM restart banco de dados. Coincidência CMPlan DB restart (uma das possíveis razões é a falta de memória virtual) e problemas de conexão LDAP.



Impacto ao Operador: IOMS reinicialização

3.14 anormal reinicialização OMS

Relatório Problema: NA05331909 Existe em: LN4.0 Correção Alvo: RL40 1,1 Gravidade: C - Minor Impacto para o Cliente: Operação e Manutenção, Operacionalidade

Descrição: OMS reinicia devido a um problema com o banco de dados CMPlan que ficar sem memória.

Repetição: Permanente.

Solução: Nenhum.

Efeitos sobre a operadora: OMS anormais reiniciar.

4. FALTAS GENÉRICOS RECÉM-RESOLVIDO

4.1 1232 fatal quando fazer a entrega por muito tempo

Relatório Problema: 122788ESPE02 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Tarefa UL lançado memória e ainda usá-lo para o tempo. Às vezes, tarefa DL reservados exatamente essa memória. Nos resultados da tarefa UL tem valores indevidos e tivemos acidente.




Impacto ao Operador: diminuição da capacidade eNB por um período de tempo de recuperação

4.2 Após MME restart eNB é preso no estado de solicitação de configuração S1 configure não enviado para MME

Relatório Problema: 125929ESPE02 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Após o envio ENBC_LinkStateChangeReq, rrom estava esperando por ENBC_LinkStateChangeResp ignorando TUP_LinkStateInd.



Impacto ao Operador: Ligação S1 são vistos de forma incorrecta eNB

4.3 FSMr3-LTE1432-eNB queda observada em permitir que o tráfego de recurso de espelhamento.


Descrição: Assim recurso foi ficando habilitar o eNB ia para reinicialização após alguns minutos



Impacto ao Operador: Se o operador ativar esse recurso, então eNB irá falhar.

4.4 Falha na óptica RP3 interface de alarme devido a FPGA pino de reset capacitância parasítica

Relatório Problema: 40184ESPE05


Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Suspeitou-se que keepalive reinicialização foi provocada por OBSAI FPGA reposto.



Impacto ao Operador: Keepalive reinicialização pode ser causado por este problema

4.5 alta perda de desempenho de rádio na configuração de alta velocidade Multicélula.


Descrição: GetChAdaptMultipliers função misturado scalers entre as células que levam à má rádio desempenho.



Impacto ao Operador: Degradação do desempenho de RF.

4.6 [FSMr2 + FSMr3] AutoReboot após OnAir


Descrição: Uma vez eNB veio Air, TRS foi para reset




Impacto ao Operador: Uma vez eNB veio Air, TRS foi para reset

4.7 FLDA (MHA) não é encomendado após o bloqueio BTS / desbloquear


Descrição: FLDA (Mha) dados adicionais foi modificado durante a re-comissionamento e BTS reiniciado devido para isso. Após o arranque BTS FLDA MHA não foi encomendado mais, porque FLDA número ProductCode foi alterado e BTS O & M detectado FLDA depois como MHA novo.



Impacto ao Operador: MHA não está a ser utilizada pelo sistema.

4.8 FSP3 detecção falhou quando BTS startup

Relatório Problema: 90367ESPE01 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: A - Crítica Impacto para o Cliente: Operação e Manutenção, startup BTS falhar devido a FSP redefinição

Descrição: Inicialização RapidIO durante a inicialização falha. Unidade directio / campainha não será habilitado. Download de software para placas FSP falhar



Impacto ao Operador: O FSP não iniciar.

4.9 Alarme Failure "na interface do RP3 óptica (0010)" é acionado usando FSM eIF2 para RP3 interface e FTIF eIF3, 4 Sametime.

Relatório Problema: 92204ESPE01 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: A - Crítica



Descrição: RP3-01 ligação por trás da interface de rádio RF6 em FSMF é resetado


Solução / Solução: Para usar FTM_EIF2/EIF4, FCT_EIF1

Impacto ao Operador: RP3-01 ligação por trás da interface de rádio RF6 em FSMF é resetado

4.10 PLMN errado em S1 TAI após S1 Entrega

Relatório Problema: NA05311458 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: Servindo PLMN em HONotify mensagem não foi o durante HO Prep calculado através Serving PLMN



Impacto ao Operador: PLMN é retirado da lista HORestriction em vez de armazenados GUMMEI

4.11 Problema com LTE PS Handover para WCDMA

Relatório Problema: NA05319825 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: RAD_t304 estáticos utilizados em vez do operador T304InterRAT configurável



Impacto ao Operador: Interrat HO KPI pode ir para baixo

4,12 Baixa throuput TCP (5M) é observada em DL


Relatório Problema: NA05329849 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: B - Maior Impacto para o Cliente: User Qualidade Plane

Descrição: Baixa throuput TCP (5M) é observada em DL. Ao mesmo tempo, o TCP UL não é degradada ~ 35Mbps, UDP DL não é degreeded ~ 80Mbps. Mudança MTU (em serwer) de 1500 a menor, por exemplo, 1424 causa que TCP DL não é degradada. Reposição do site causar esse problema não é observar por algum tempo. Enorme quantidade de tráfego UDP (para saturar o link) que causa problema é observada de novo. Problema também é observada, mas após mais tempo sem UDP tempestade teste, logo após longo período de trabalho normal BTS. Há várias estações com este problema. Existem também vários estação com o mesmo SW onde problema não é observado. Parece que problema é desencadeado por "tempestade UDP" quando o tráfego UDP é perto da fronteira banda. Probabilidade: ocasionais, Solução: Não há solução (reposição do site causar esse problema não é observado por algum tempo), Efeitos sobre a operadora: TCP DL degradada

4.13 DTAG Alarme Alinhamento falha de conexão / muitos "camada de transporte em X2 Interface "


Descrição: Falhas foram unnecesarrily levantou para SCTP pares abortar cenários de seus pares X2


Solução / Solução: Mude temporizador maxTimeSctpSetup a 100s (solução para 9s alternando caso apenas) Aplique alternando a prevenção como solução (para 130 apenas alternando caso),

Impacto ao Operador: Alarme levantou para SCTP pares abort

4.14 não pode desbloquear fôrma


Descrição:


Módulo de rádio não conseguiu realizar Bloco / processo de desbloqueio por causa do tempo limite



Impacto ao Operador: Frma não pode ser desbloqueado

Faltando 4.15 ativação Plano no log de feedback - reiniciar parcialmente eNodeB necessário

Relatório Problema: NA05336271 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: Durante o plano de massa de aprovisionamento, observou-se que para alguns eNBs houve o plano ativação em falta no feedback. Era necessário BTS reset para restaurar a funcionalidade, ainda mais provisionamento plano estava funcionando bem.



Impacto ao Operador: Possíveis problemas com abastecimentos plano.

4.16 FSMF-NTP Interrupção alarmante com novo módulo HW FSMF


Descrição: CCS (AaSNTP) permanece em estado inválido, assim, nova configuração NTP de SEM não é levado



Impacto ao Operador: Nova configuração NTP não é aceito Status NTP inválidos


4.17 certificado Vendedor faltando


Descrição: FILHO com unidade FTLB não foi bem sucedido como o pedido do CMP não conseguiu receber do operador certificado.



Impacto ao Operador: O operador pode resolver se algum erro acontecer como o arquivo PKCS # 12 é renomeado e retidos.

4.18 Nenhuma chamada possível após MME interrupção recuperado


Descrição: Após acidente de um dos MME em uma rede eNBs ter perdido a capacidade de se comunicar em todas as Ligações S1 permanentemente (até eNB reiniciar).


Solução / Solução: Redefinir de preso eNB

Impacto ao Operador: ENBs inoperáveis após a restauração caiu MME

4.19 FTM reiniciado devido a uma falha SW (SmaAsn1is terminado)


Descrição: SmaAsn1 processo terminou resultando em unidade restart


Probabilidade: Uma Ocorrência


Impacto ao Operador: eNB sai do ar devido a unidade de reset

4.20 FHCCs esporadicamente são perdidos durante o teste de óptica ficha do cabo / desligue e configurado células finalmente vai para defeituoso com 1868 em modo acoplado


Descrição: Falha 10 é rehandled muitas vezes e leva muito tempo, e faz com que a manipulação culpa atraso acumulação


Solução / Solução: Ao manusear / remanejamento culpa 10 por causa de outras falhas e falha 10 já está armazenado para FR, apenas alarme apropriado é enviado à componente FDAR e posterior manipulação de culpa 10 terminou. Rulestep Removido em 4161 culpa cancelar regra que falhas rehandled armazenados para FR,

Impacto ao Operador: Várias óptica / contínuo plugue do cabo / teste manuseio causa da falha desligue atraso build-up, ea probabilidade de que as células vão defeituoso.

4.21 ID Fault 2016 Nome Solicitação de Mudança de Autonomous redefinir como ação de recuperação em vez de falha ônibus Baseband


Descrição: Alarme errado exibido na SEM 2016 em culpa ocorrência.


Solução / Solução: Alarme enviado mudou em FlexiFDrules.,

Impacto ao Operador: "Falha de ônibus Baseband" em vez de "Unidade de reset autônomo" exibido em SEM culpa em 2016 ocorrência.


4.22 "Falha na interface do RP3 óptica" alarme foi visto por FRIE-3 após a atualização para 1202_689_00


Descrição: Falha na relação RP3 óptica Congela módulo RF e conexão solta na interface óptica.


Solução / Solução: Não há solução (atualização SW é essencial)

Impacto ao Operador: Congela módulo RF e conexão solta na interface óptica.

4.23 Inter-Vendor HO falha com habilitado RoHC


Descrição: Cálculo da diferença entre a configuração de origem e destino não foi devidamente implementado. O problema era que o nosso ENB não enviou PDCP-config a fonte, quando há houve diferença na configuração específica: por exemplo, ambos os eNBs, para o mesmo qci1, usado compressão de cabeçalho, mas com diferente rohcMaxCid.



Impacto ao Operador: Depois de HO é excuted silenciamento chamada ocorre pelo D / L de erro de descompressão e decodificação falhar

Falha de controle de antena 4,24 RET relatados com alarme errado

Relatório Problema: NA05341112 Existe em: LN4.0 Corrigido em: RL40 1,0


Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Este RET deve estabelecer a relação com cell1 e número do alarme deve ser 7654 (Funcionamento da célula local degradado), a alteração do processo de criação de tal relação.



Impacto ao Operador: Alarme errado está presente para usuário

4.25 perda de memória BTSOM ocorreu quando o módulo RF é bloqueado e desbloqueado repetidamente.


Descrição: Fixação de vazamento de memória em OAM: - AntennaLineAgent objeto não foi retirado após bloco de RF - Os dados lidos do banco de dados não foi lançado



Impacto ao Operador: eNBs redefinir devido a falta de memória

4,26 eNB reinicialização autónoma devido ao "EFaultId_NoConnectionToUnitAl" (ID: 10) para FSPD observada em um site


Descrição: Processador Cavium OCTEON produzir erros ECC espúrias sob algumas circunstâncias.

Probabilidade: Uma ocorrência

Solução / Solução: Definir CvmCtl [IPREF] para 1 em cada núcleo.


Impacto ao Operador: Sistema reinicia ocasionalmente

4.27 pacote de descarte devido ao protocolo não suportado contado como ifInErrors15


Descrição: OSPF não é compatível com LTE e, portanto, esses pacotes são descartados foram contados como pacotes. A especificação não menciona explicitamente como este pacote precisa ser tratada.



Impacto ao Operador: Erro desnecessário incremento contagem de pacotes

4,28 E-RAB DR (LTE_5025C) e UEs RRC Conectado (LTE_1076A) aumentou após Atualização RL40 P8


Descrição: Especial temporizador QCI5 inatividade no MAC PS leva ao aumento da chamada cai na rede devido a prolongamento de chamadas com QCI5 portador.


Solução / Solução: Use R & D parâmetro rdQci5SignInactivityTimer = 0 para desativar o especial temporizador QCI5 inatividade.

Impacto ao Operador: Maior duração da chamada e maior probabilidade queda de chamada para o afetado chamadas

Arquivos 04:29 não são compactados em eNB e por isso não coletados em IOMS




Descrição: PM de upload é realizado durante outras operações SW_DL provisão plano, o setor de diagnóstico ( escrever em sintonia). Observou-se que esporadicamente arquivos de partículas não são comprimidas.


Solução / Solução: Nenhuma solução ou solução alternativa. Para evitar a "falta de memória" situações operador deve excluir arquivos descompactados PM da pasta / ram manualmente

Impacto ao Operador: Esporadicamente um arquivo PM não são compactados. Como consequência deste ficheiro não é enviado para a OMS. Arquivo fica para sempre no diretório / ram e consome vários MB memória (dependendo do tamanho da configuração de BTS)

4.30 DL LTE rendimento com RL40 menor do que o esperado


Descrição: Rendimento DL FTP é degradada devido a atrasos no retorno UL TCP.



Impacto ao Operador: Redução do rendimento DL FTP

4,31 RACH SSR KPI é "0" após a atualização MP3.1.4 SW


Descrição: BBC definir valor de correção delta como 0



Impacto ao Operador: RACH SSR KPI é "0"


4,32 RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente. BTS reset é necessário


Descrição: Problema ocorreu em determinados cenários, quando o pedido de instalação X2 vinha eNB que foi marcado como indisponível. Este erro causado em eNB que foi levando à insuficiência durante provisão plano.



Impacto ao Operador: RNW ativação plano falhou devido a um problema interno e BTS é estado inconsistente.

4.33 FSMF Precoce Projeto :: 1 +1 +1 com RF Módulo FRHA 20 Mht BW, terceiro setor não é trabalhar


Descrição: LFS fez mudança de cenário de sincronização de velocidade do link de 4x. Após a mudança HWAPI envia primeiro API_OPT_SYNC_IND (Off) e depois API_OPT_SYNC_IND (Frame) para BTSOM durante o ajuste do buffer elástico. Código BTSOM (após LTE1542 implementação característica) tentou re-sincronizar ligação com cenário velocidade do link de 8x e alarmes desnecessários eram gerada.


Solução / Solução: Para usar FTM_EIF2/EIF4, FCT_EIF1

Impacto ao Operador: RP3-01 ligação por trás da interface de rádio RF6 em FSMF é resetado

4,34 FXEB relata alarme "Módulo RF detectou nenhum poder TX em bloco filtro interno"

Relatório Problema: NA05349186


Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Após BTS reset (gerente de BTS) Alarme de "Módulo RF detectou nenhum poder TX em bloco filtro interno "foram relatados a partir de FXEB em gerente BTS. Medidor de potência de energia não confirmou saída nos tubos problemáticos da FXEB.


Solução / Solução: HW BTS reset (gerente de BTS) resolveu o problema.,

Impacto ao Operador: A RFM módulo Bloqueio / Desbloqueio é feito de Site Manager. Após o desbloquear todos os módulos e células devem se recuperar bem, no entanto, ocasionalmente, alguns se o GSM TRX pode falhar e um alarme 'TRX defeituosa: Módulo RF detectou nenhuma TX pow

4.35 Pantech móvel Volte ROHC CRC falhar


Descrição: Quando RoHC está habilitado e pacotes IP contêm bandeira DF definir o Ue vai descartar pacotes voip como a descompressão falhar.


Solução / Solução: RoHC desativado, não usando a bandeira DF em gerador de dados de teste em DL direção.

Impacto ao Operador: Pior ou nenhuma transmissão de Voip.

4,36 FSMF projeto cedo: LTE83: FSMF - Teste Negativo (alarme Fan) - teste falhou


Descrição: Alarme 4073 não apaga mesmo que não há mais condição defeituosa.




Impacto ao Operador: Alarme 4073 ainda visíveis em MEV após condição de falha foi removido.

4,37 RF Módulo Bloco de falha ocorreu na BTS Site Manager para a recuperação de 10 RP3 depois RL40 0.0.2 SW Atualizado


Descrição: Alguns BTS não pode bloquear Módulo RF para a recuperação de RL30 10 após RL40 0.0.2 Atualização SW


Solução / Solução: eNB local de reset

Impacto ao Operador: Atividade Manutenção errado

Alarme interface de 4,38 X2 (6203), não sendo apagada, porém verdadeira ligação X2 está disponível


Descrição: Alguns BTS não pode bloquear Módulo RF para a recuperação de RL30 10 após RL40 0.0.2 Atualização SW


Solução / Solução: Repor eNB


4.39 Problema com o contadores M8013C6, -7, - 8, -27)




Descrição: 1.Problems com UE atribui devido ao transbordamento de armazenamento do usuário MAC 2. Célula para baixo devido a DSP acidente na MAC. 3. Ao inatividade do usuário é detectada por um UE, pode acontecer que a liberação de conexão não foi enviado para a UE eo contexto UE só é excluído da rede.


Solução / Solução: Desativar DRX estendida

Impacto ao Operador: Não Anexar possível ou muito difícil Célula para baixo devido a DSP acidente UE tenta reestablishments que falham.

4.40 Samsung Gallaxy S3 que apoiou Band único (5) inter-Frequência de HO 2,1 g de 850M Failure


Descrição: Falha é original ao lado UE, mas de patching UE pede interação com o usuário e assim CPlane deve fornecer uma solução para remendar essa falha UE. Motivo da falha é que UE entrar em um celular com um earfcn configurados, que não é suportado de UE e gatilho depois de um InterFreq / interband entrega, que é abortada. Correção funciona dessa forma para desativar para tal UE da possibilidade de InterFreq / interband e InterRat entrega.



Impacto ao Operador: InterFreq / interband entrega é abortada

4.41 FHCAs ficou inicialização falhar depois de atualização de software do MP3.1.4 para MP3.1.5 (SW 4.0.711)



Descrição: FHCA que não arranca com sucesso



Impacto ao Operador: A unidade não irá arrancar e ser detectado pelo BTS

Compartilhamento de 4,42 RF cabeamento pode bloquear eNB


Descrição: eNB não pode estar no ar após seguinte procedimento: desligue a alimentação RF, reposição do site eNB , Ligar fonte de alimentação RF




4,43 configuração incompleta que incompatibilidade de Recursos celular comissionamento direito arquivo após eliminação de células


Descrição: Configuração incompleta que Resource celular arquivo incompatibilidade comissionamento logo após célula eliminação



Impacto ao Operador: Celular 5 é perdida em recomissionamento


4.44 As células deficientes são causados por alto tráfego - FSP colidiu com falhas 418


Descrição: Problemas com a UE atribui devido ao transbordamento de armazenamento do usuário MAC. Célula para baixo devido a DSP acidente na MAC. Quando inatividade do usuário é detectada por um UE, pode acontecer que a liberação de conexão foi não enviado para a UE eo contexto UE só é excluído da rede.


Solução / Solução: Desativar DRX estendida

Impacto ao Operador: KPIs em níveis erradas.

4.45 falha Tx incorreta no MIMO visto em alguns RL40 0.0.3 eNBs


Descrição: 0x7655 alarme desnecessário para falhas em 4003 Bloqueio / Desbloqueio de FR com celular que tem tudo recursos nele



Impacto ao Operador: 0x7655 alarme desnecessário por culpa 4003, bloqueando o FR

4,46 implementação Murkku-logger para FSMF para salvar o histórico MURKKU ASIC para uso posterior


Descrição:


Com merge / correção, o comportamento enlace óptico é registrada e se houver problemas entre módulo do sistema e módulo de rádio, novos logs podem ser usados para solução de problemas pelo apoio equipe. Logs são automaticamente incluídas no instantâneo com outros registros técnicos.



Impacto ao Operador: Murkku registra ausente do instantâneo.

4,47 RL40 Aceitação - X2 Atualização da Huawei eliminado Vizinho Relacionamento

Relatório Problema: NA05366479 Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: A - Crítica Impacto para o Cliente: Novo recurso / funcionalidade

Descrição: Ao testar o LTE Característica 1014 eu encontrei um problema de interoperabilidade ao testar X2 interface



Impacto ao Operador: Interworking problema na interface X2 entre Huawei e NSN.

Status operacional da célula torna-se 4,48 eNodeB disable devido a BCN nenhuma resposta após 200UE anexada com modelo de tráfego 11 e configuração 7 para 15 minutos


Descrição: Faltando valores SERDES no ramo de software



Impacto ao Operador: Conexão SRIO instável entre a FCT ea FSP o que leva a pacotes gotas.

4,49 RL40 LTE FOA - FALHA NA RP3 OPTICAL INTERFACE



Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: A falha em RP3 óptico de alarme Interface ocorreu aleatoriamente em vários sites diferentes e OptIF diferente, o alarme está ativo normalmente 30-60 seg



Impacto ao Operador: É difícil ver qualquer impacto para KPIs, pois o problema tem ocorreu muito raramente na rede (2-3 vezes por semana) e queda de célula é bastante curta

4,50 FSM3: FSMF A.102 uboot rebaixamento não é possível


Descrição: RL40 é instalar o U-boot contido no pacote sem verificar se é realmente mais recente que o U-boot instalado. FSMF A102 U-boot rebaixamento não é permitido como U-boot está diretamente ligada com a hardware (update é possível) eo fato declarado superior leva a um U-boot rebaixamento caso o U-boot no alvo é mais recente



Impacto ao Operador: U-boot rebaixamento não é possível

5. FALTAS GENÉRICOS RESOLVIDO

Comandos Momento Subseqüente Avanço com o mesmo valor: 5,1 RL40_LTE459.

Relatório Problema: 101340ESPE04 Existe em: LN4.0 Corrigido em: RL50 Gravidade: B - Maior Impacto para o Cliente: Manutenção Operação e

Descrição: Durante uma chamada, os comandos Momento posterior avanço com mesmo valor Cronometragem Adiantamento pode ser observada.




Impacto ao Operador: Ao analisar vestígios recolhidos na ferramenta NetAct Trace Viewer, Momento posterior comandos antecedência com mesmo valor poderia acontecer observado, o que não é de acordo com a implementação necessário, embora não seja uma limitação para o traçado funcionalidade itsself.

5.2 No caso de quando é usado com FSMF FHCC no modo acoplado com FXEB e comprimento entre SM e FHCC é maior do que 12km, chamada não é possível


Descrição: Configuração usada: L111-Hcoupled71-2TX-2Rx com FSMF e com 2xFHCC-FXEB. Tanto FHCC são conectados a um SM via cinco quilômetros de cabo óptico. Atraso Repeater está configurado para 70US. - Um BTS é OnAir. - UE ligado a ambos os FHCCs no modo MIMO é ligar - Embora, UE vê uma célula adequada não pode anexar ao celular. Fixe não é possível, então chamada Não é possível também., chamada não é possível se o comprimento entre SW e FHCC é maior que 12 km. Neste caso, o comprimento é igual a 19 km mencionado = 5 km de cabo óptico + 14km (como um 70US de atraso repetidor -. Uma km = 5us), Chamada funciona se demora repetidor está definido para 35us (comprimento cerca de 12 km). Problema ocorre apenas quando FHCC está ligado no modo juntamente com FXEB e mencionou comprimento é mais do que 12 km. Com FXEA o problema não é visível.


Solução / Solução: Restrito com módulo do sistema FSMF e FXEB até 10 km cabos ópticos.

Impacto ao Operador: A chamada não é possível se o comprimento entre SW e FHCC é maior que 12 km. Neste caso, o comprimento é igual a 19 km mencionado = 5 km de cabo óptico + 14km (como um 70US de atraso repetidor - 1km = 5us).

5.3 Falha em Recuperar Control_Hot insert_removal de módulo de RF sem BTS Redefinir


Descrição:


Caso de teste:. Recuperar Control_Hot insert_removal de módulo de RF sem BTS Reset, Configuração: - FSMF + FXEB (master) + FXEB (escravo) - Configuração MIMO - Testado com 20 km de fibra Cabo (entre SM e mestre FXEB) - Hot remover, inserir nova quente FXEB na posição mestre. - Chamada em curso - Retire fibra de SM e substituir de volta. Resultados: As unidades são novamente detectado sem problemas, - Retire fibra de SM e de mestre. FXEB. - Substitua mestre FXEB com novo FXEB Resultado:. Nenhuma unidade são detectados depois de esperar por mais de 10 minutos, ainda não há detecção de modo pré-formada uma redefinição de site. Resultado:. Ainda sem unidade detectado, - Ciclo de energia a SM só Resultado:. Ainda sem detecção, - Ciclo de energia a FXEB só Resultado: Agora a cadeia FXEB é detectado e chamadas podem ser feitas em escravo.


Solução / Solução: Um ciclo de poder ao Mestre RFM talvez necessário para resolver problema de detecção.

Impacto ao Operador: Substituição Manutenção de mestre RFM dentro da cadeia não pode ser detectados automaticamente pelo módulo do sistema.

5.4 Após a emissão Shutdown célula eNB uma mensagem CCN com a versão LN1.0

Relatório Problema: 36918ESPE05 Existe em: LN4.0 Corrigido em: RL50 Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: Depois de um celular desligar, eNB envia uma configurationChangeNotification com managedObject class = "LNCEL" version = "LN1.0" name = "administrativeState" travado ".



Impacto ao Operador: Depois de um celular desligar, eNB envia uma configurationChangeNotification com a versão = "LN1.0" em vez de "LN4.0".

Compensada 5,5 SFN entre FSMr2 e FSMr3



Descrição: Medição de interface aérea é feita de forma síncrona para ambos eNBs. Números são do SFN gravado., há um deslocamento de 347 números de quadro entre FSMr2 e FSMr3 constante (FSMr2 SFN é 347 quadros para trás). , UTC, UNIX época, época GPS e tempo CDMA são calculado de forma semelhante em ambos os casos, mas cdmaTimeOffset parece diferente. eNB redefinição não alterar o status, offset era constante.



Impacto ao Operador: No caso do operador usa tanto FSMr2 e FSMr3, PRS será localizado na quadros assíncronos e OTDOA não funcionará entre os dois eNBs.

5.6 1836: EFaultId_ALOvercurrentAl não é visto em BTS Site Manager


Descrição: - BTS é OnAir com MHA conectados às portas da antena 1 e 2 de FHDB 1.2.1 módulo RF. - Curta o viés-T entre a porta da antena 1 e MHA. - 1836 alarme deve ser visto relatados na BTS LOG. Deixe alarme ativo e depois tempo de filtragem, alarme associado. - 1836 é visto na BTS SYSLOG mas nenhum alarme sempre aparece no SITE BTS Gestor., Pode ser visto na syslog que 1836 é gerada e enviada, mas não é de alarme visto na Gerente BTS Site., In BTS Site Manager, os campos MHA e RET mudar de mostrando o status VERDE para serem desativados. Ou no local que iria ver um intermitente vermelho / verde LED no RRH.



Impacto ao Operador: 1836: EFaultId_ALOvercurrentAl alarme está faltando em BTS site Gerente

5.7 FSMF última FHCC (1.6.1) e / ou juntamente FXEB (1.6.2) não detectado



Descrição: FSMF última FHCC (1.6.1) e / ou acoplado FXEB (1.6.2) não detectado.


Solução / Solução: Bloqueio / Desbloqueio de FHCC

Impacto ao Operador: FSMF última FHCC e / ou FXEB acoplada não detectado.

5.8 FSMF: RF compartilhando LTE-GSM: Depois de células LTE reposição do site estão desativados, eNB executa BTS redefinição autônoma como ação de recuperação (no caso de 40W células LTE)


Descrição: ENB com FSMF. Às vezes, após reposição do site acionada manualmente em BTS Site Manager, as células LTE ir para Estado operacional "Disabled" e "OAM desconectado 'BTS site mostra Manager. Após um enquanto LTE eNB executa um reset autônoma como uma ação de recuperação. Depois disso, as células de LTE suba. Este é um problema ocasional.


Solução / Solução: Power-off reset ou esperar o reset autônomo

Impacto ao Operador: Ocasionais após células LTE reposição do site manual são desativados, eNB executa BTS redefinição autônoma como ação de recuperação.

5.9 Falha 4039 não é limpo em LTE se o problema é resolvido


Descrição: Sistema LTE e GSM está instalado e funcionando, sem falhas ativa, as células são OnAir.


Desligue sistema GSM e cabos ópticos transversais de OptIf1 e OptIf2. Ligue o sistema GSM. Falha 4039 é gerado em LTE. Equivalente culpa é gerado em sistema GSM. Este é o comportamento esperado. No sistema GSM cabos ópticos transversais de OptIf1 e OptIf2 para que a culpa desencadeada condição não é mais válido No sistema GSM a falha é limpa, mas as células não estão em alta. No sistema LTE a falha 4039 não é limpo O comportamento esperado é que a falha é eliminada em ambos os sistemas. Como medida adicional de uma reinicialização BCF é realizada no local GSM. GSM está chegando, sem qualquer falha e as células são OnAir No sistema LTE o alarme ainda está ativo. Este não é o esperado. Uma reposição de módulos de RF sobre LTE é necessário para resolver o problema.



Impacto ao Operador: Falha 4039 (link RP3 conflito) não é limpo em LTE se o problema é resolvido.

5.10 FSMF: Unidade de contadores de erro de freqüência superior está incorreta em ascensão e SEM


Descrição: eNB equipado com FSMF: Explicação para contadores topFreqSyncError abaixo tabela de contador não é totalmente correta, a unidade de contadores de erro é errado. Explicação está falando sobre 'microssegundos ", mesmo que deveria ser ppb/1000. Em FSMF, a unidade usada é realmente ppb/1000 mas a descrição em SEM é "Os três últimos contadores de descrever a mínima, média e o valor máximo da distribuição ao longo do pacote erro de sincronização de frequência do serviço em microssegundos. ", Contadores foram verificados a partir de RISE (para LN4.0 release). Também há descrição e unidade de medição de erro de freqüência é '' microssegundos. Portanto, este deve ser corrigido primeiro a subir e, em seguida, a vista SEM. Probabilidade: Permanente

Solução / Solução: Em FSMF, a unidade usada é realmente ppb/1000. Portanto, existe uma fator de 1000, quando comparados os resultados de FSME e FSMF.

Impacto ao Operador: Unidade de contadores de erro de freqüência superior está incorreta.


5.11 alarme ALD não aparece depois de bloquear a RFM. (RET está em estado não detectado)


Descrição: Bloquear RFM com RET ligado e comissionado, RFM Quando é bloqueada RET do designado para linhas de antena mudar de estado para esta unidade não pode ser detectado. Ele está em falta ou com defeito. Depois de alguns minutos de alarme ALD aparecer, mas apenas para aqueles que estão em outros BTS. Para aqueles que são atribuídos a RET em cada RFM nenhum alarme é disparado. Probabilidade: Permanente


Impacto ao Operador: Falta de alarme ALD após o bloqueio da RFM

5.12 Carregar da PM não arquivos desencadeada por eNB no caso de algumas combinações de tipos de medição ativados e desativados


Descrição: Se nem todos os tipos de medição são ativados no eNB, com algumas combinações com tipos de medição de desempenho de ativado e desativado a eNB não desencadear uma carregar com fileLoadPrepare mensagem aos IOMS (upload para BTSSM afetado também)., Este acontece apesar de o arquivo de medição de desempenho criado no eNB contém o resultados esperados de medição de desempenho dos tipos de medição ativado.

Este comportamento é independente da utilização de FSME ou FSMF.


Solução / Solução: Se todos os tipos de medição são ativados o problema não ocorrer.

Impacto ao Operador: Resultados de medição de desempenho são criadas enviados para IOMS / BTSSM de tipos de medição que estão fora do âmbito de interesse e assim seriam desativado pelo operador.


3.0 validação PhyCellID incorreta 5,13 BTS Site Manager


Descrição: Arquivo SCF Dado é comissionado com o Gerenciador de LN3.0 BTS Site. Em seguida, o mesmo arquivo SCF é baixado para BTS com LN4.0 e BTS é reiniciado. BTS converte SCF para a versão LN4.0. Após a conversão, LN4.0 BTS Site Manager relata erros em:, nome p = "text" incorreto parâmetro: phyCellId / p nome p = "status" Erro / p nome p = "detalhes" A identidade da célula da camada física (PCI) phyCellId da célula em si não deve estar dentro de qualquer faixa PCI na lista negra na lista (IAFIM-intrFrBCList-startIntraPci, IAFIM- intrFrBCList-rangeIntraPci). / p, O mesmo erro é reprodutível quando o download de originais LN3.0 SCF diretamente ao Gerente LN4.0 BTS Site. , PDDB diz que: MRBTS / LNBTS / LNCEL / IAFIM intrFrBCList rangeIntraPci (Número de PCI no intra- faixa de freqüência) Descrição: Indica o número de PCIs no intervalo (incluindo startPCI). Valor n4 corresponde a 4, n12 corresponde a 12 e assim por diante. O UE aplica valor 1, se o campo está ausente, caso em que apenas se aplica ao valor de identidade física célula indicada pelo início. Parâmetros relacionados: LNCEL-phyCellId phyCellId da célula não deve ser incluído na intervalo configurado intrFrNCList-rangeIntraPci (público) Descrição das relações de parâmetros: a identidade da célula da camada física (PCI) phyCellId de o celular não deve estar dentro do intervalo configurado na partida intrFrBCList-startIntraPci. , SCF encomendado em LN3.0 BTS Site Manager configurou parâmetros: nome da lista = "intrFrBCList" item nome p = "rangeIntraPci" n8 / p nome p = "startIntraPci" 1 / p / Item / List, Cell ID Física na SCF são 4, 5, 6 para três células configurados. nome p = "phyCellId" 4 / p nome p = "phyCellId" 5 / p nome p = "phyCellId" 6 / p, esta phyCellId estão na faixa que não tenha de ser aceite por BTS SiteManager. , LN4.0 BTS SiteManager detecta que phyCellId tem um valor que está em gama intrFrBCList mas LN3.0 BTS SiteManager não.


Solução: Nota técnica foi preparada e está disponível no seguinte link: https://online.portal.nokiasiemensnetworks.com/pic/downloadproxy/urn:nsn.com:sharenet: 488140042

Impacto ao Operador: Erro de validação PhyCellID.

Falha no módulo 5,14 LTE RL30 Mp3.1.1 RF (1907) para cerca de 1 segundo presente



Existe em: LN4.0 Corrigido em: RL40 1,0 Gravidade: C - Minor Impacto para o Cliente: Manutenção Operação e

Descrição: Módulo RF falha 1907 alarme ocorre esporadicamente e limpar-se após ~ 1 segundo.

PR Em anexo: NA05257421


Solução / Solução: bloquear e desbloquear o módulo RF correspondente

Impacto ao Operador: 1907 Alarme ocorre esporadicamente e limpar-se após ~ 1 segundo.

Nota: A correção é fornecida para os módulos fôrma e FRMB.

5.15 Falha na interface do RP3 óptico de alarme ocorreu devido a KEEPALIVE expirou.


Descrição: FR1.2.1 FHCA falha alarme RP3 óptica ocorreu devido a KEEPALIVE esperar temporizador [70000 ms] expirou. - Ocorreu de forma aleatória em rede ao vivo - Problema recupera automaticamente

PR Em anexo: NA05326360,



Impacto ao Operador: BTS redefinir

5.16 mudanças Site-ID em BTS Manager não visíveis no Editor de CM


Descrição:


Fazer alterações em todos os IDs MRBTS acordo com a nova convenção de nomenclatura. A fim de proceder com esta solicitação, passos seguintes já foi tentado:, Passo-1: Mudando atributo btsId em MO-BTSSCL-FALHOU, é um comportamento esperado como a mudança só poderá ser realizada . através do Gerenciador de BTS Site, Passo-2: btsId mudou para um dos locais de 7290 a 417290 através de BTS SM-SUCESSO No entanto, temos vindo a observar alguns problemas após o ID de Mudança: - A informação não está devidamente atualizado no CM editor - A mudança não propagado em relação vizinho; sim um novo vizinho foi criado com novo ENB ID:. 417.290 Nesse caso, estava causando conflito com cplaneipaddress existente relacionamento com id velho 7290. Issue foi resolvido apenas por excluir manualmente o velho relações.


Solução / Solução: Emissão foi resolvido apenas por excluir manualmente o velho relações.

Impacto ao Operador: Mudanças Site-ID em BTS Manager não visíveis no Editor CM.

5.17 eNB espúrias redefinir devido a falta de memória

Relatório Problema: NA05326903 Existe em: LN4.0 Corrigido em: RL40 1.0, 4.0 RL30 Gravidade: A - Crítica Impacto para o Cliente: Manutenção Operação e

Descrição: eNBs repor em rede ao vivo devido à falta de memória.



Impacto ao Operador: eNBs redefinir devido a falta de memória.

5.18 No PCI alarme duplicação (6307) ocorreu


Descrição: - BTS-SM reconfiguração para fazer PCI duplicação de propósito - LNADJLNADJLPhysical ID da célula da célula servida por vizinho eNB


- Verifique se ocorre inconsistência configuração da célula X2 próximo (6307), ocorre Sem alarme quando PCIs são duplicados em informações vizinho BTSSM e NetAct história do alarme. Ele só existe na história alarme cru. Este alarme é omitido, independentemente do FSME ou FSMF.



Impacto ao Operador: Sem alarme ocorre quando PCIs são duplicados em informações vizinho em BTSSM e NetAct história do alarme. Ela existe apenas no histórico de alarmes cru.

5.19 FSP acidente em tupu F3C2


Descrição: FSP acidente resultando em Unidade de reset autônomo. Isso acontece em torno de uma vez por dia de 200 sites. Alarme "Unidade de reset autônomo como ação de recuperação" é visível. Isto é limpo com FSP rearme automático.



Impacto ao Operador: Reset automático FSP.

5,20 FSP acidente na MAC-PS (F2C1)


Descrição: FSP acidente resultando em Unidade de reset autônomo. Alarme Unit "redefinição autônoma como a recuperação ação "apuradas pela FSP rearme automático.




Impacto ao Operador: Reset automático FSP.

Liberação 5,21 ERAB Contador Incompatibilidade


Descrição: - Gerar lançamento ERAB a cada 15 minutos * Inatividade: deixar UE para entrar em modo de espera * Separar: Modo Avião * Normal: Dados fora, contra liberação ERAB não é correspondida em comparação com as mensagens exibido na Emil ou Wireshark. Especialmente ERAB contra liberação normal é muito pequeno do que aqueles de ocorrência real.



Impacto ao Operador: ERAB contra liberação normal mostra a valores pequenos

5,22 Frig não pôde ser detectado (falha na interface do RP3 óptico) após eNB desceu com problemas de GPS


Descrição: Local único setor havia sido configurado com 1xFRIG e 1xFSMF (sincronização fase em uso) e local foi no ar. Houve alguns problemas de GPS conhecidas no site., Alguns dias mais tarde (após o fim de semana), foi observado que Frig não foi mais detectada e houve "falha em Interface RP3 óptica "alarme para ele, o site foi preso em estado inicializado. Sinal de GPS tinha sido instável no local e que parece ter causado problemas com eNB arranque e sincronizando corretamente com Frig.



Impacto ao Operador: Ocasionais o Frig não foi mais detectada e houve Alarme "Falha na interface do RP3 óptica".


5,23 FSMF eNB reinicialização espontânea no modo de teste Dedicado


Descrição: - Modo Activate eNB Teste Dedicado pela BTS SM através de LMP. - Monitorar o reinício eNB para o modo de teste dedicado. - Espere por 10 minutos, logo depois de reiniciar em modo de teste dedicado a eNB. reinicia espontaneamente e se recupera no modo operacional normal. O FSMF não tem módulo semelhante como FSME.



Impacto ao Operador: FSMF eNB reinicialização espontânea no modo de teste dedicado.

5,24 teste do site não é compatível com o software de RL40 eNB


Descrição: BTS está em estado OnAir e selecione a partir do site BTS testes de menu - gerente. Testes site, o Item de menu testes do site não pode ser selecionado com RL eNB software - mensagem de erro: "Corre Site testa Indisponível porque BTS HW não suporta testes do site ".



Impacto ao Operador: Sítio Testes menu é acinzentada no Site Manager quando RET (Remote Inclinação eléctrico), não é usado na configuração do eNB. Todos os clientes que não utilizam RET para inclinar antena não será capaz de executar testes do Site. Local Os testes também são usados para testar downlink e uplink Ethernet comunicações entre FSM e módulo de RF. Este ensaio é independente do teste comunicação antena. Clientes teste de comunicação Ethernet usam para detectar problema hw entre os módulos FSM e RF.


5,25 RL20: repetição da falha no módulo RF Alarm



Solução: Alarme apuradas pelo módulo de Bloqueio / Desbloqueio.

Solução: Além de correcção implementado em RL30, a seguir foi adicionada em corrente Entrega SW: - 6dB adicional caminho digital para A101 e A102 para proporcionar espaço suficiente para o analógico PA, tentando automaticamente para compensar as diferenças de temperatura e freqüência e envelhecimento da PA, - Correção abrange tanto A101 e A102.

Observação: A correção não foi possível de ser verificada no laboratório (pode ser testado no campo apenas).

Impacto ao Operador: "Fracasso módulo RF 1920" culpa é visível.

Nota: A correção é fornecida para os módulos fôrma e FRMB.

Renúncia

As informações contidas neste documento estão sujeitas a alterações sem aviso prévio e descreve apenas o produto definido na introdução desta documentação. Esta documentação destina-se a utilização do Nokia Siemens Networks clientes apenas para os fins do contrato sob o qual o documento é submetido, e nenhuma parte dela pode ser utilizada, reproduzida, modificada ou transmitida por qualquer forma ou meio sem a prévia autorização escrita da Nokia Siemens Networks. A documentação foi preparado para ser utilizado por profissionais e pessoal devidamente treinado, eo cliente assume total responsabilidade ao usá-lo. Nokia Siemens Networks recebe comentários de clientes como parte do processo de desenvolvimento e melhoria contínua da documentação.

As informações ou declarações prestadas na presente documentação relativa à adequação, capacidade ou desempenho dos produtos de hardware ou software mencionados são dadas "como é" e qualquer responsabilidade decorrente


em conexão com esses produtos de hardware ou software será definida de forma conclusiva e, finalmente, em um acordo separado entre a Nokia Siemens Networks e cliente. No entanto, a Nokia Siemens Networks tem feito todos os esforços razoáveis para assegurar que as instruções contidas no documento são adequados e livres de erros materiais e omissões. A Nokia Siemens Networks, se for considerado necessário pela Nokia Siemens Networks, explicar as questões que não podem ser cobertos pelo documento.

Nokia Siemens Networks vai corrigir erros nesta documentação o mais rápido possível. EM HIPÓTESE VAI A Nokia Siemens Networks SERÁ RESPONSÁVEL POR ERROS NO PRESENTE DOCUMENTAÇÃO OU Por quaisquer danos, incluindo mas não limitado para Special, diretos, indiretos, ACIDENTAL OU CONSEQUENTE OU quaisquer perdas, como, mas não limitado a perda de LUCRO, RECEITA, INTERRUPÇÃO DE NEGÓCIOS, oportunidade de negócio ou de dados, ou POSSAM DECORRER DO USO DESTE DOCUMENTO OU informações nele contidas.

Esta documentação eo produto que ele descreve são considerados protegidos por direitos autorais e outros direitos de propriedade intelectual de acordo com as leis aplicáveis.

O logotipo da onda é uma marca registrada da Nokia Siemens Networks Oy. Nokia é uma marca registrada da Nokia Corporation. A Siemens é uma marca registrada da Siemens AG.

Outros nomes de produtos mencionados neste documento podem ser marcas comerciais de seus respectivos proprietários, e eles são mencionados apenas para fins de identificação.

Copyright © Nokia Siemens Networks 2013. Todos os direitos reservados.


lte_rl40 1.0 release documentation.en.pt

Documents