Sem fio : Cisco SGSN Serving GPRS Support Node

Autenticação do 5x00 Series SGSN ASR e de redistribuição PTMSI melhores prática

18 Junho 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Feedback

Introdução

Este documento fornece uma explicação básica dos benefícios da configuração da frequência do procedimento de autenticação, da identidade provisória do assinante de celular do pacote (PTMSI), e da redistribuição da assinatura PTMSI. Especificamente, este documento é para um procedimento de gerenciamento de terceira geração opcional da mobilidade do projeto da parceria para 2G e 3G em servir o nó de suporte GPRS (SGSN) esse é executado no 5000 Series do roteador do serviço Aggregated (ASR).

Este documento explica estes melhores prática:

  • Ajuste da frequência da autenticação
  • Redistribuição PTMSI
  • Redistribuição da assinatura PTMSI
  • O impacto se você não configura o ajuste da frequência da autenticação e a redistribuição PTMSI e a redistribuição da assinatura (baseada na experiência dos exemplos do cliente)
  • Diretrizes de configuração e o impacto em interfaces externas
  • Opções para pesquisar defeitos edições

Contribuído por Krishna Kishore DV, por Sujin Anagani, e por Parthasarathy M, engenheiros de TAC da Cisco.

Visão geral

A autenticação, da assinatura PTMSI, e PTMSI estrutura da redistribuição sob o perfil do Controle de chamadas permitem o operador de configurar a autenticação ou a atribuição da assinatura PTMSI e PTMSI pelo subscritor no 2G e no 3G SGSN e entidade de gerenciamento móvel (SRA.). No SGSN, a autenticação pode atualmente ser configurada para estes procedimentos - anexe, serviço-pedido, roteamento-área-atualização (RAU), curto-Mensagem-serviço, e destaque.

A SRA. igualmente utiliza a mesma estrutura a fim configurar a autenticação para os serviço-pedidos e as seguir-área-atualizações (tau). A redistribuição PTMSI é configurável para o anexo, o serviço-pedido, e o RAUs. A redistribuição da assinatura PTMSI é configurável para o comando do anexo, da redistribuição PTMSI, e o RAUs. A autenticação e a redistribuição podem ser permitidas para cada exemplo destes procedimentos ou para cada nth exemplo do procedimento, chamado autenticação/redistribuição seletivas. Determinados procedimentos igualmente apoiam a habilitação da autenticação ou a redistribuição baseada no tempo decorreu (periodicidade ou intervalo) desde a última autenticação ou redistribuição respectivamente.

Além disso, estes podem ser configurados especificamente para somente Universal Mobile Telecommunications System (UMTS) (3G) ou o General Packet Radio Service (GPRS) (2G) ou ambos. Esta configuração é verificada somente quando é opcional para que o SGSN autentique ou readjudique a assinatura PTMSI/PTMSI de um subscritor. Nas encenações onde é imperativo fazer estes procedimentos, esta configuração não é verificada.

Há três tipos de CLI para a configuração da frequência de cada procedimento - um GRUPO CLI, NENHUM CLI, e REMOÇÃO CLI. Quando você invoca um GRUPO CLI, o operador quer permitir a autenticação ou a redistribuição para o procedimento específico. NENHUM CLI é desabilitar explicitamente a autenticação ou a redistribuição PTMSI para um procedimento, e a REMOÇÃO CLI é restaurar a configuração a um estado onde o CLI (AJUSTE ou NÃO) não seja configurado de todo. Todas as configurações estão supostas PARA SER REMOVIDAS quando a árvore é inicializada na atribuição do centímetro-perfil. Daqui, REMOVE é a configuração padrão.

O GRUPO CLI afetará somente um procedimento específico na árvore quando NENHUM CLI e REMOVE O CLI afetará o procedimento atual e igualmente REMOVERÁ os Nós mais baixos. Também, se NENHUM CLI ou REMOVE O CLI afeta a árvore comum, o efeito será propagado nos Nós correspondentes nas árvores acesso-específicas igualmente.

Há dois tipos de CLI para a configuração da periodicidade de cada procedimento - o GRUPO CLI e a REMOÇÃO CLI. O GRUPO e REMOVE terminados contra a periodicidade afetarão somente a configuração da periodicidade e sairão da configuração da frequência sem tocar. NENHUM CLI executado para a frequência (para ser preciso, NENHUM CLI é comum que não toma nenhuns argumentos da frequência ou da periodicidade, mas é identificado com a configuração da frequência internamente ao armazenar) igualmente REMOVERÁ a configuração da periodicidade.

Determinadas encenações onde a autenticação é terminada incondicionalmente estão como segue:

  • Anexo internacional da identidade do assinante de celular (IMSI) - todos os diplomatas IMSI são autenticados
  • quando o subscritor não tem sido autenticado antes e você não tem um vetor
  • quando houver uma má combinação da assinatura PTMSI
  • quando houver uma má combinação de cálculo do número de sequência chave (CKSN)

Atualmente, a autenticação pode ser permitida para estes sob o atendimento-controle-perfil:

  • anexe, serviço-pedido, RAU, destaque, curto-Mensagem-serviço, todo-eventos, e tau
  • A tau está no uso pela SRA.
  • anexe e o serviço-pedido é usado por SGSN e por SRA.
  • o resto é usado exclusivamente por SGSN

Autenticação SGSN e de assinatura PTMSI blocos de procedimento

Esta estrutura de árvore explica os blocos de procedimento que SGSN considera para ajustes da frequência.


Figura 1: Os blocos de procedimento SGSN consideram para ajustes da frequência

As árvores para o procedimento da redistribuição PTMSI são mostradas aqui.


Figura 2: Árvore da configuração de autenticação


Figura 3: Árvore da configuração da redistribuição PTMSI

Porque a autenticação e da assinatura PTMSI redistribuição são exigidas

Pelas especificações técnica 3GPP (TS) 23.060, a seção 6.5.2, etapa (4), as funções da autenticação são definidos na cláusula da “função Segurança”. Se nenhum contexto do Gerenciamento de mobilidade (MM) para a estação móvel (MS) existe em qualquer lugar na rede, a seguir a autenticação é imperativa. Os procedimentos de cálculo são descritos na cláusula da “função Segurança”. Se a atribuição PTMSI será terminada e a rede suporta o cálculo, a rede ajustará o modo de cálculo.

Como mencionado, SGSN executa a autenticação somente para pedidos do novo registro tais como diplomatas IMSI e RAUs inter-SGSN em alguns fluxos de chamadas onde a validação da assinatura PTMSI ou do CKSN é combinada mal com armazenado. Por exemplo, os procedimentos tais como RAU periódico e intra-RAUs não são exigidos ser autenticados porque já têm uma base de dados existente com um SGSN registrado. A autenticação é opcional aqui. Não terminar a autenticação não é sempre por mais bom que o equipamento de usuário (UE) possa ficar na rede por dias junto sem desempenho de uma requisição de registro fresca. Há umas possibilidades que a instalação do contexto de segurança entre o SGSN e o UE pôde obter comprometida, assim que é sempre bom autenticar e verificar periodicamente a validez do subscritor que foi registrado em SGSN baseado em alguma frequência. Isto é explicado em detalhe em 3GPP 23.060, a seção 6.8.

As funções da Segurança e relacionados são encontrados em 33.102, a seção 6.8. Por exemplo, se a autenticação opcional está permitida com base em figuras 18 e 19 na seção 6.8 de 33.102, e se SGSN tenta autenticar o UE com parâmetros incorretos do contexto de segurança, o UE nunca poderá combinar a resposta da emissão (SRE) ou a resposta esperada (XRES) com o SGSN que conduz ao reattachment à rede. Isto impede o UE que fica na rede com um banco de dados falso por um tempo mais longo.

A fim fornecer a identidade que esconde, um SGSN gera uma identidade provisória para um IMSI chamado o PTMSI. Uma vez que os diplomatas MS, o SGSN emitem um PTMSI novo ao MS. O MS então armazena este PTMSI e usa-o a fim identificar-se ao SGSN em toda a conexão que futura nova iniciar. Desde que o PTMSI é dado sempre ao MS em uma conexão calculada, ninguém poderá traçar fora um IMSI ao PTMSI, embora possa ver uma mensagem do texto simples com o IMSI que vai às vezes. (Por exemplo, a primeira vez que diplomatas IMSI e identidade-respostas com um IMSI).

A redistribuição PTMSI é explicada em 3GPP 23.060, a seção 6.8 como um procedimento autônomo. O mesmos podem ser terminados como parte de todo o procedimento do uplink a fim readjudicar assinaturas PTMSI e PTMSI para proteger identidades UE. Isto não aumentará a rede que sinaliza em nenhuma relação. A redistribuição da assinatura PTMSI e PTMSI é sempre por mais bons que estas sejam as identidades chaves que SGSN atribui ao UE na etapa inicial do registo. A redistribuição destes baseados em alguma frequência ajuda SGSN a esconder a identidade do UE com valores diferentes por um tempo prolongado em vez do uso de apenas um valor PTMSI. Identidade-esconder refere esconder da informação tal como IMSI e IMEI do MS, quando as mensagens desde/até o MS estão enviadas ainda no texto simples e quando a criptografia não começou ainda.

Problema

Em algumas redes cliente, observou-se que algumas identidades chaves tais como MSIDN/PTMSI estão misturadas acima entre assinantes diferentes e enviadas em GTPC que sinaliza mensagens na relação GN e nos registros de dados de chamada (CDR).

O Bug da Cisco ID CSCut62632 e CSCuu67401 trata alguns casos secundários da recuperação da sessão, que traçam a identidade de um subscritor com outro. Três casos estão listados abaixo. Todos estes casos são código revisto, equipe da garantia de qualidade analisada, e reproduzida.

Encenação #1 (falha dobro no sessmgr esse resultados na perda das identidades do subscritor)

UE1 - Anexo - IMSI1 - Número de diretório de assinante internacional da estação móvel (MSISDN) 1 - PTMSI1 - Smgr#1

A matança dobro do exemplo do sessmgr, SGSN perdeu os detalhes UE1.

UE2 - Anexo - IMSI2 - MSISDN 2 - PTMSI1 - Smgr#1 

PTMSI1 é reutilizado para UE2.

UE1 - RAU intra - PTMSI1- SGSN processa este uplink, porque a autenticação para intra-RAU não é imperativa.

Isto conduz à mistura dos registros de duas sessões diferentes.

Encenação #2 (o aborto da peça do aplicativo das potencialidades de transação (TCAP) de uma sessão essa conduz à mistura acima de identidades do subscritor)

UE1 - Anexo - IMSI1 - UGL ajustado (TCAP - internamente abortado devido ao impacto do sessmgr)

UE2 - Anexo - IMSI2 - UGL enviado com o mesmo TCAP - OTID

HLR envia o TCAP - continuação da requisição precedente, UE1 MSISDN

SGSN atualiza o MSISDN incorreto de UE1 com UE2 neste caso. Isto conduz à mistura dos registros de duas sessões diferentes.

Encenação #3 (aborto TCAP de uma sessão essa resultados na mistura acima de identidades do subscritor)

UE1 - Anexo - IMSI1 - SAI enviado (TCAP - internamente abortado devido ao impacto do sessmgr)

UE2 - Anexo - IMSI2 - SAI enviado com o mesmo TCAP - OTID

HLR envia o TCAP - continuação da requisição precedente, vetores da autenticação UE1 (objetivas triplas ou os quíntuplos)

SGSN atualiza os vetores incorretos da autenticação de UE1 com UE2

Isto conduz a SGSN usando os vetores UE1 para a autenticação de UE2.

Aproximação da estabilização

Se a autenticação para intra-RAU é permitida ou redistribuição PTMSI está permitido, SGSN autentica o cliente com um grupo armazenado do vetor. Se o UE é diferente do que o que esteve armazenado para, UE/SGSN não passará o estágio da autentificação para continuar mais na rede. Com isto, a possibilidade do UE que fica na rede com um banco de dados incorreto vem para baixo. Estas são algumas áreas conhecidas no código. A unidade de negócio continuará a analisar mais casos a fim compreender melhor esta edição.

Plano do reparo

O reparo do Bug da Cisco ID é uma melhor aproximação do esforço. Analise mais áreas do código e distribua isto no nó menos denso para monitorar antes que você a tome a um nó high-density.

Diretrizes de configuração

A habilitação da autenticação aumenta a relação GR e Iu que sinaliza enquanto SGSN precisa de buscar o grupo do vetor da autenticação do registro de lugar home (HLR) e de executar procedimentos de autenticação adicionais para o acesso. Os operadores precisam de ser cuidadosos escolher os valores de frequência que impactam a rede menos.

Os indicadores de desempenho chave do protocolo do aplicativo do Gerenciamento de mobilidade GPRS (GMM) /Mobile (MAPA) (KPIs) são importantes de analisar antes que você derive valores de frequência para cada procedimento. Baseado no KPIs, verifique o procedimento que executa a elevação. Para este procedimento, ajuste altos valores da frequência. (Esta é a maneira de ajustar cada parâmetro baseado em um modelo do atendimento da rede). 

Uma maneira ideal configurar estes parâmetros é aos valores determinados às folhas, mas não na raiz da árvore. Por exemplo, figura 2 explica a árvore da configuração de autenticação. Os operadores puderam escolher ajustar o valor a um nível inferior, como mostrado aqui, em vez da configuração “do anexo de autenticação” diretamente.

authenticate attach attach-type gprs-only frequency 10
authenticate attach attach-type combined frequency 10

É sempre bom ajustar os valores de alta frequência (unidades como 10s) e monitora então a relação Gr/Iu que sinaliza pontos iniciais. Se sinalizar está bem dentro dos limites, defina valores até que sinalizar alcance um lugar seguro perto dos pontos iniciais que o operador gostaria de se ajustar para suas redes.

Ajuste a frequência nos vários procedimentos em 20/30 e derrube-os a 5-10 com monitoração próxima no tráfego da interface externa. Exige-se verificar o impacto na memória CPU do linkmgr e do sessmgr com esta carga adicional.

As redistribuições da assinatura PTMSI e PTMSI não causarão o ponto na sinalização diretamente, mas é sempre importante ajustar valores de alta frequência de modo que o PTMSIs esteja disponível com exemplos do sessmgr (qual acontece raramente). Não se recomenda mudar PTMSI para cada procedimento do uplink do UE, como este não é o melhor prática. Um valor do 10 pôde ser aceitável. Afinal estas mudanças é importante monitorar e executar exames médicos completos padrão no sistema.

Como um exemplo:

Authentication:

authenticate attach ( we can still fine tune this based on KPIs of
Inter RAT attach & attach type).

authenticate rau update-type periodic frequency 10

authenticate rau update-type ra-update frequency 5




PTMSI & PTMSI signature allocation:

ptmsi-reallocate attach

ptmsi-reallocate routing-area-update update-type ra-update

ptmsi-signature-reallocate attach frequency 10

ptmsi-signature-reallocate routing-area-update frequency 20

ptmsi-reallocate routing-area-update update-type periodic frequency 10

Troubleshooting

Quando a autenticação deve ser executada ou assinatura PTMSI ou PTMSI devem ser atribuído, debugar logs estará imprimido para capturar porque o procedimento foi terminado. Isto auxílios no Troubleshooting no caso de algumas discrepâncias. Estes logs incluem a configuração do centímetro-perfil e o valor atual de todos os contadores e do movimento da lógica de decisão através da vários configuração e contadores. Também, os valores de contador atuais pelo subscritor podem ser vistos com os assinantes da mostra sgsn-only ou os comandos dos assinantes GPRS-somente da mostra.

Um exemplo de saída deste é fornecido. Os contadores da corrente e o timestamp autenticado o mais atrasado são adicionados ao resultado completo do comando dos assinantes da mostra.

[local]# show subscribers sgsn-only full all
.
.
.
DRX Parameter:
Split PG Cycle Code: 7
SPLIT on CCCH: Not supported by MS
Non-DRX timer: max. 8 sec non-DRX mode after Transfer state
CN Specific DRX cycle length coefficient: Not specified by MS
Authentication Counters
Last authenticated timestamp : 1306427164
Auth all-events UMTS : 0 Auth all-events GPRS : 0
Auth attach common UMTS : 0 Auth attach common GPRS : 0
Auth attach gprs-only UMTS : 0 Auth attach gprs-only GPRS : 0
Auth attach combined UMTS : 0 Auth attach combined GPRS : 0
Auth attach irat UMTS : 0 Auth attach irat GPRS : 0
Auth attach irat-gprs-only UMTS : 0 Auth attach irat-gprs-only GPRS : 0
Auth attach irat-combined UMTS : 0 Auth attach irat-combined GPRS : 0
Auth UMTS : 0 Auth GPRS : 0
Auth serv-req : 0 Auth serv-req data : 0
Auth serv-req signaling : 0 Auth serv-req page-rsp : 0
Auth rau UMTS : 0 Auth rau GPRS : 0
Auth rau periodic UMTS : 0 Auth rau periodic GPRS : 0
Auth rau ra-upd UMTS : 0 Auth rau ra-upd GPRS : 0
Auth rau ra-upd lcl-ptmsi UMTS : 0 Auth rau ra-upd lcl-ptmsi GPRS : 0
Auth rau ra-upd irat-lcl-ptmsi UMTS : 0 Auth rau ra-upd irat-lcl-ptmsi GPRS : 0
Auth rau comb UMTS : 0 Auth rau comb GPRS : 0
Auth rau comb lcl-ptmsi UMTS : 0 Auth rau comb lcl-ptmsi GPRS : 0
Auth rau comb irat-lcl-ptmsi UMTS : 0 Auth rau comb irat-lcl-ptmsi GPRS : 0
Auth rau imsi-comb UMTS : 0 Auth rau imsi-comb GPRS : 0
Auth rau imsi-comb lcl-ptmsi UMTS : 0 Auth rau imsi-comb lcl-ptmsi GPRS : 0
Auth rau imsi-comb irat-lcl-ptmsi UMTS: 0 Auth rau imsi-comb irat-lcl-ptmsi GPRS: 0
Auth sms UMTS : 0 Auth sms GPRS : 0
Auth sms mo-sms UMTS : 0 Auth sms mo-sms GPRS : 0
Auth sms mt-sms UMTS : 0 Auth sms mt-sms UMTS : 0
PTMSI Realloc Counters
Last allocated timestamp : 1306427165
PTMSI Realloc Freq UMTS : 0 PTMSI Realloc Freq GPRS : 0
PTMSI Realloc Attach UMTS : 0 PTMSI Realloc Attach GPRS : 0
PTMSI Realloc Serv-Req : 0 PTMSI Realloc Serv-Req Data : 0
PTMSI Realloc Serv-Req Signaling : 0 PTMSI Realloc Serv-Req Page-rsp : 0
PTMSI Realloc Rau UMTS : 0 PTMSI Realloc Rau GPRS : 0
PTMSI Realloc Rau Periodic UMTS : 0 PTMSI Realloc Rau Periodic GPRS : 0
PTMSI Realloc Rau Ra-Upd UMTS : 0 PTMSI Realloc Rau Ra-Upd GPRS : 0
PTMSI Realloc Rau Comb-Upd UMTS : 0 PTMSI Realloc Rau Comb-Upd GPRS : 0
PTMSI Realloc Rau Imsi-Comb-Upd UMTS : 0 PTMSI Realloc Rau Imsi-Comb-Upd GPRS : 0
PTMSI Sig Realloc Counters
Last allocated timestamp : 0
PTMSI Sig Realloc Freq UMTS : 0 PTMSI Sig Realloc Freq GPRS : 0
PTMSI Sig Realloc Attach UMTS : 0 PTMSI Sig Realloc Attach GPRS : 0
PTMSI Sig Realloc Ptmsi-rel-cmd UMTS : 0 PTMSI Sig Realloc Ptmsi-rel-cmd GPRS : 0
PTMSI Sig Realloc Rau UMTS : 0 PTMSI Sig Realloc Rau GPRS : 0
PTMSI Sig Realloc Rau Periodic UMTS : 0 PTMSI Sig Realloc Rau Periodic GPRS : 0
PTMSI Sig Realloc Rau Ra-Upd UMTS : 0 PTMSI Sig Realloc Rau Ra-Upd GPRS : 0
PTMSI Sig Realloc Rau Comb-Upd UMTS : 0 PTMSI Sig Realloc Rau Comb-Upd GPRS : 0
PTMSI Sig Realloc Rau Imsi-Comb UMTS : 0 PTMSI Sig Realloc Rau Imsi-Comb GPRS : 0
CAE Server Address:
Subscription Data:
.
.

Se a edição é considerada na rede, incorpore estes comandos a fim recolher a informação para que a unidade de negócio use-se para analisar mais a edição:

show subscribers gprs-only full msisdn <msisdn>
show subscribers gprs-only full imsi <imsi>
show subscribers sgsn-only msisdn <msisdn>
show subscribers sgsn-only msisdn <imsi>
show subscribers gprs-debug-info callid <callid> (get o/p for both callid)
show subscribers debug-info callid <callid> (get o/p for both callid)
task core facility sessmgr instance < >
task core facility imsimgr instance < >
Mon sub using MSISDN or pcap traces
SSD during issue.
Syslogs during the issue.

Riscos

A sinalização aumentada para Gr/Iu conecta mais um leve impacto do processo interno (linkmgr) CPU se você autentica demasiado frequentemente.

Sintaxe do comando

Todos os comandos reagem do modo da configuração/perfil e os privilégios do operador aplicam-se. Um instantâneo dos comandos sob o centímetro-perfil é como segue:

Authentication
1. Attach
authenticate attach {inter-rat} {attach-type [gprs-only | combined ]}
{frequency <1..16>} {access-type [umts | gprs]}
no authenticate attach {inter-rat} {attach-type [gprs-only | combined ]}
{access-type [umts | gprs]}
remove authenticate attach {inter-rat} {attach-type [gprs-only | combined ]}
{access-type [umts | gprs]}

2. Service-request
authenticate service-request {service-type [data | signaling | page-response]}
{frequency <1..16> | periodicity <1..10800>}
no authenticate service-request {service-type [data | signaling | page-response]}
remove authenticate service-request {service-type [data | signaling | page-response]}
{periodicity}
3. Rau
authenticate rau {update-type periodic} {frequency <1..16> | periodicity <1..10800>}
{access-type [umts | gprs]}
authenticate rau {update-type [ra-update | combined-update | imsi-combined-update]}
{with [local-ptmsi | inter-rat-local-ptmsi]} {frequency <1..16> |
periodicity <1..10800>}
{access-type [umts| gprs]}
authenticate rau {update-type [ra-update | combined-update | imsi-combined-update]}
{with foreign-ptmsi} {access-type [umts| gprs]}
no authenticate rau {update-type periodic} {access-type [umts | gprs]}
no authenticate rau {update-type [ra-update | combined-update | imsi-combined-update]}
{with [local-ptmsi | inter-rat-local-ptmsi | foreign-ptmsi]}
{access-type [umts| gprs]}
remove authenticate rau {update-type periodic} {periodicity}
{access-type [umts | gprs]}
remove authenticate rau {update-type [ra-update | combined-update |
imsi-combined-update]}
{with [local-ptmsi | inter-rat-local-ptmsi]} { periodicity} {access-type [umts| gprs]}
remove authenticate rau {update-type [ra-update | combined-update |
imsi-combined-update]}
{with foreign-ptmsi} {access-type [umts| gprs]}
4. Sms
authenticate sms {sms-type [mo-sms | mt-sms]} {frequency <1..16>}
{access-type [umts | gprs]}
no authenticate sms {sms-type [mo-sms | mt-sms]} {access-type [umts | gprs]}
remove authenticate sms {sms-type [mo-sms | mt-sms]} {access-type [umts | gprs]}
5. Detach
authenticate detach {access-type [umts | gprs]}
no authenticate detach {access-type [umts | gprs]}
remove authenticate detach {access-type [umts | gprs]}
6. All-events
authenticate all-events {frequency <1..16>} {access-type [umts | gprs]}
no authenticate all-events {access-type [umts | gprs]}
remove authenticate all-events {access-type [umts | gprs]}

PTMSI Reallocation
1. Attach
ptmsi-reallocate attach {frequency <1..50>} {access-type [umts | gprs]}
no ptmsi-reallocate attach {access-type [umts | gprs]}
remove ptmsi-reallocate attach {access-type [umts | gprs]}
2. Service-request
ptmsi-reallocate service-request {service-type [data | signaling | page-response]}
{frequency <1..50>} no ptmsi-reallocate service-request
{service-type [data | signaling | page-response]}
remove ptmsi-reallocate service-request {service-type [data | signaling |
page-response]}
3. Routing-area-update
ptmsi-reallocate routing-area-update {update-type [periodic | ra-update |
combined-update | imsi-combined-update]} {frequency <1..50>}
{access-type [umts | gprs]}
no ptmsi-reallocate routing-area-update {update-type [periodic | ra-update |
combined-update | imsi-combined-update]} {access-type [umts | gprs]}
remove ptmsi-reallocate routing-area-update {update-type [periodic | ra-update |
combined-update | imsi-combined-update]} {access-type [umts | gprs]}
4. Interval/frequency
ptmsi-reallocate [interval <60..1440> | frequency <1..50>] {access-type [umts | gprs]}
no ptmsi-reallocate [interval | frequency] {access-type [umts | gprs]}
remove ptmsi-reallocate [interval | frequency] {access-type [umts | gprs]}

PTMSI-Signature Reallocation

1. Attach
ptmsi-signature-reallocate attach {frequency <1..50>} {access-type [umts | gprs]}
no ptmsi-signature-reallocate attach {access-type [umts | gprs]}
remove ptmsi-signature-reallocate attach {access-type [umts | gprs]}
2. PTMSI Reallocation command
ptmsi-signature-reallocate ptmsi-reallocation-command {frequency <1..50>}
{access-type [umts | gprs]}
no ptmsi-signature-reallocate ptmsi-reallocation-command {access-type [umts | gprs]}
remove ptmsi-signature-reallocate ptmsi-reallocation-command
{access-type [umts | gprs]}
3. Routing-area-update
ptmsi-signature-reallocate routing-area-update {update-type [periodic | ra-update |
combined-update | imsi-combined-update]} {frequency <1..50>}
{access-type [umts | gprs]}
no ptmsi-signature-reallocate routing-area-update {update-type [periodic | ra-update |
combined-update | imsi-combined-update]} {access-type [umts | gprs]}
remove ptmsi-signature-reallocate routing-area-update {update-type [periodic |
ra-update | combined-update | imsi-combined-update]} {access-type [umts | gprs]}
4. Interval/frequency
ptmsi-signature-reallocate [interval <60..1440> | frequency <1..50>]
{access-type [umts | gprs]}
no ptmsi-signature-reallocate [interval | frequency] {access-type [umts | gprs]}
remove ptmsi-signature-reallocate [interval | frequency] {access-type [umts | gprs]}

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.