Autenticação SGSN ASR 5x00 Series e práticas recomendadas de realocação PTMSI

Introduction

Este documento fornece uma explicação básica dos benefícios da configuração de frequência do procedimento de autenticação, Packet Temporary Subscriber Identity (PTMSI) e realocação de assinatura PTMSI. Especificamente, este documento destina-se a um procedimento opcional de gerenciamento de mobilidade do Partnership Project de terceira geração para 2G e 3G em Serving GPRS Support Node (SGSN) executado em Aggregated Service Router (ASR) 5000 Series.

Este documento explica as melhores práticas:

• Configuração de frequência de autenticação
• realocação PTMSI
• realocação de assinatura PTMSI
• O impacto se você não configurar a configuração de frequência de autenticação e a realocação e realocação de assinatura PTMSI (com base na experiência de casos de clientes)
• Diretrizes de configuração e o impacto nas interfaces externas
• Opções para solucionar problemas

Overview

A estrutura de autenticação, PTMSI e realocação de assinatura PTMSI no perfil de controle de chamadas permite que o operador configure a autenticação ou alocação da assinatura PTMSI e PTMSI por assinante na SGSN 2G e 3G e na Entidade de Gerenciamento Móvel (MME). No SGSN, a autenticação pode ser configurada atualmente para esses procedimentos - anexar, solicitação de serviço, atualização da área de roteamento (RAU), serviço de mensagens curtas e desanexar.

O MME também usa a mesma estrutura para configurar a autenticação para solicitações de serviço e atualizações de área de rastreamento (TAUs). A realocação PTMSI é configurável para anexação, solicitação de serviço e RAUs. A realocação de assinatura PTMSI é configurável para anexar, comando de realocação PTMSI e RAUs. A autenticação e a realocação podem ser ativadas para cada instância desses procedimentos ou para cada nth instância do procedimento, chamada autenticação/realocação seletiva. Determinados procedimentos também suportam a habilitação de autenticação ou realocação com base no tempo decorrido (periodicidade ou intervalo) desde a última autenticação ou realocação, respectivamente.

Além disso, eles podem ser configurados especificamente para o Sistema Universal de Telecomunicações Móveis (UMTS) (3G) ou para o Serviço Geral de Rádio por Pacotes (GPRS - General Packet Radio Service) (2G) ou ambos. Essa configuração é verificada somente quando é opcional para o SGSN autenticar ou realocar a assinatura PTMSI/PTMSI de um assinante. Nos cenários em que é obrigatório executar esses procedimentos, essa configuração não é verificada.

Há três tipos de CLIs para a configuração de frequência de cada procedimento - uma CLI SET, uma CLI NO e uma CLI REMOVA. Quando você chama uma CLI SET, o operador deseja habilitar a autenticação ou realocação para o procedimento específico. A CLI NO é desativar explicitamente a autenticação ou a realocação PTMSI para um procedimento, e a CLI REMOVE é restaurar a configuração para um estado em que a CLI (SET ou NO) não está configurada. Supõe-se que todas as configurações sejam REMOVIDAS quando a árvore for inicializada na alocação de perfil cc. Portanto, REMOVER é a configuração padrão.

A CLI SET afetará apenas um procedimento específico na árvore, enquanto a CLI NO CLI e a CLI REMOVE afetarão o procedimento atual e também removerão os nós inferiores. Além disso, se NO CLI ou REMOVE CLI afetar a árvore comum, o efeito deve ser propagado nos nós correspondentes nas árvores específicas de acesso também.

Há dois tipos de CLIs para a configuração de periodicidade de cada procedimento - a CLI SET e a CLI REMOVE. O SET e o REMOVE concluídos em função da periodicidade afetarão apenas a configuração da periodicidade e deixarão a configuração da frequência intocada. A CLI NO executada para frequência (para ser mais preciso, a CLI NO é comum porque não aceita argumentos de frequência ou periodicidade, mas é identificada com a configuração de frequência internamente enquanto armazena) também REMOVE a configuração de periodicidade.

Determinados cenários em que a autenticação é concluída incondicionalmente são os seguintes:

• Conexão International Mobile Subscriber Identity (IMSI) - todos os anexos IMSI são autenticados
• quando o assinante não tiver sido autenticado antes e você não tiver um vetor
• quando há uma incompatibilidade de assinatura PTMSI
• quando há uma incompatibilidade do CKSN (Ciphering Key Sequence Number, número de sequência de chave de codificação)

Atualmente, a autenticação pode ser habilitada para esses itens no perfil de controle de chamada:

• anexar, solicitação de serviço, RAU, desanexar, serviço de mensagens curtas, todos os eventos e TAU
• TAU está em uso pelo MME
• O anexo e a solicitação de serviço são usados tanto pela SGSN quanto pela MME
• o restante é usado exclusivamente pela SGSN

Blocos de procedimentos de autenticação SGSN e assinatura PTMSI

Esta estrutura de árvore explica os blocos de procedimento que a SGSN considera para configurações de frequência.

Figura 1: O procedimento bloqueia as considerações de SGSN para configurações de frequência

As árvores para o procedimento de realocação PTMSI são mostradas aqui.

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

Figura 3: Árvore de Configuração de Realocação PTMSI

Por que a autenticação e a realocação de assinatura PTMSI são necessárias

Por 3GPP Technical Specifications (TS) 23.060, seção 6.5.2, etapa 4, as funções de autenticação são definidas na cláusula "Security Function" (Função de segurança). Se não houver contexto de Gerenciamento de Mobilidade (MM) para a Estação Móvel (MS) em qualquer lugar da rede, a autenticação será obrigatória. Os procedimentos de cifragem são descritos na cláusula "Função de segurança". Se a alocação PTMSI for concluída e a rede suportar cifragem, a rede definirá o modo cifragem.

Como mencionado, o SGSN executa a autenticação somente para novas solicitações de registro, como anexos IMSI e RAUs inter-SGSN em alguns fluxos de chamada em que a validação da assinatura PTMSI ou CKSN é incompatível com a armazenada. Por exemplo, procedimentos como RAU periódica e intraRAUs não precisam ser autenticados porque já têm um banco de dados existente com SGSN registrado. A autenticação é opcional aqui. Não concluir a autenticação nem sempre é bom, pois o equipamento do usuário (UE) pode permanecer na rede por dias juntos sem executar uma nova solicitação de registro. Há chances de a configuração do contexto de segurança entre a SGSN e a UE ser comprometida, portanto, é sempre bom autenticar e verificar periodicamente a validade do assinante registrado na SGSN com base em alguma frequência. Isso é explicado em detalhes na seção 6.8 da 3GPP 23.060.

As funções de segurança e as referências relacionadas estão localizadas na seção 6.8 da seção 3.102. Por exemplo, se a autenticação opcional for habilitada com base nas Figuras 18 e 19 da seção 6.8 de 33.102, e se o SGSN tentar autenticar o UE com parâmetros de contexto de segurança incorretos, o UE nunca conseguirá combinar o Enviar Resposta (SRES) ou Resposta Esperada (XRES) com o SGSN, o que resulta em reconexão à rede. Isso evita que a UE permaneça na rede com um banco de dados falso por mais tempo.

Para fornecer ocultação de identidade, uma SGSN gera uma identidade temporária para um IMSI chamado PTMSI. Quando o MS se anexa, o SGSN emite um novo PTMSI para o MS. Em seguida, o MS armazena esse PTMSI e o usa para se identificar ao SGSN em qualquer nova conexão futura que ele inicie. Como o PTMSI é sempre fornecido ao MS em uma conexão cifrada, ninguém será capaz de mapear um IMSI para o PTMSI externo, embora eles possam ver uma mensagem de texto simples com o IMSI passando às vezes. (Por exemplo, a primeira vez que um IMSI anexa e respostas de identidade com um IMSI).

A realocação de PTMSI é explicada na seção 6.8 da 3GPP 23.060 como um procedimento independente. O mesmo pode ser concluído como parte de qualquer procedimento de uplink para realocar assinaturas PTMSI e PTMSI para proteger identidades da UE. Isso não aumentará a sinalização de rede em nenhuma interface. A realocação de assinaturas PTMSI e PTMSI é sempre boa, pois essas são as identidades-chave que a SGSN atribui à UE na etapa de registro inicial. A reatribuição destes com base em alguma frequência ajuda a SGSN a esconder a identidade da UE com valores diferentes durante um período prolongado, em vez de usar apenas um valor PTMSI. A ocultação de identidade refere-se à ocultação de informações como IMSI e IMEI dos Estados-Membros, quando as mensagens dos Estados-Membros/para os Estados-Membros ainda são enviadas em texto simples e quando a encriptação ainda não foi iniciada.

Problema

Em algumas redes de clientes, observou-se que algumas identidades-chave, como MSIDN/PTMSI, são misturadas entre diferentes assinantes e enviadas em mensagens de sinalização GTPC na interface Gn e em registros de dados de chamadas (CDRs).

Os IDs de bug da Cisco CSCut62632 e CSCuu67401 lidam com alguns casos de canto de recuperação de sessão, que mapeiam a identidade de um assinante com outro. Três casos estão listados abaixo. Todos esses casos são revisados por código, a equipe de Garantia de qualidade é analisada e reproduzida.

Cenário 1 (duplo defeito no sessmgr que resulta na perda da identidade do assinante)

UE1 - Anexar - IMSI1 - MSISDN (Mobile Station International Subscriber Diretory Number) 1 - PTMSI1 - Smgr#1

Dupla morte da instância do sessmgr, SGSN perdeu detalhes da UE1.

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

PTMSI1 é reutilizado para UE2.

UE1 - Intra RAU - PTMSI1- SGSN processa esse uplink, já que a autenticação para intraRAU não é obrigatória.

Isso resulta na mistura de registros de duas sessões diferentes.

Cenário 2 (TCAP (Transaction Capabilities Application Part, Parte da aplicação de recursos de transação) aborta uma sessão que resulta na mistura de identidades de assinantes)

UE1 - Anexar - IMSI1 - UGL set (TCAP - cancelado internamente devido a travamento do sessmgr)

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

HLR envia TCAP - continuação da solicitação anterior, MSISDN da UE1

A SGSN atualiza o MSISDN incorreto de UE1 com UE2 neste caso. Isso resulta na mistura de registros de duas sessões diferentes.

Cenário 3 (aborto TCAP de uma sessão que resulta na mistura de identidades de assinantes)

UE1 - Anexar - IMSI1 - SAI enviado (TCAP - cancelado internamente devido a travamento do sessmgr)

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

HLR envia TCAP - continuação da solicitação anterior, vetores de autenticação da UE1 (trigêmeos ou quintuplos)

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

Isso resulta em SGSN usando vetores UE1 para autenticação de UE2.

Abordagem de estabilização

Se a autenticação para intraRAU estiver habilitada ou a realocação PTMSI estiver habilitada, o SGSN autenticará o cliente com um conjunto de vetor armazenado. Se a UE for diferente do que foi armazenado, a UE/SGSN não passará o estágio de autenticação para prosseguir na rede. Com isto, a possibilidade de a UE permanecer em rede com uma base de dados incorreta diminui. Estas são algumas áreas conhecidas no código. A unidade de negócios continuará a analisar mais casos para entender melhor esse problema.

Corrigir plano

A correção dos IDs de bug da Cisco é uma abordagem de melhor esforço. Analise mais áreas de código e implante-o em um nó menos denso para monitoramento antes de levá-lo a um nó de alta densidade.

Diretrizes de configuração

A ativação da autenticação aumenta a sinalização da interface Gr e Iu, pois a SGSN precisa buscar o conjunto de vetor de autenticação do HLR (Home Location Register) e executar procedimentos de autenticação adicionais para acessar. Os operadores precisam ter cuidado para escolher valores de frequência que afetem menos a rede.

O GPRS Mobility Management (GMM)/Mobile Application Protocol (MAP) Key Performance Indicators (KPIs) são importantes para serem analisados antes de você derivar valores de frequência para cada procedimento. Com base nos KPIs, verifique o procedimento que é executado alto. Para este procedimento, defina altos valores de frequência. (Essa é a maneira de ajustar cada parâmetro com base em um modelo de chamada de rede). 

Uma maneira ideal de configurar esses parâmetros é definir valores como leafs, mas não na raiz da árvore. Por exemplo, a Figura 2 explica a árvore de configuração de autenticação. Os operadores podem optar por definir o valor para um nível inferior, como mostrado aqui, em vez da configuração de "autenticação de anexo" diretamente.

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

É sempre bom definir valores de alta frequência (unidades como 10s) e depois monitorar limiares de sinalização de interface Gr/Iu. Se a sinalização estiver bem dentro dos limites, defina valores até que a sinalização atinja um local seguro perto de limiares que o operador gostaria de definir para suas redes.

Defina a frequência dos vários procedimentos em 20/30 e reduza-os para 5-10 com monitoramento atento do tráfego da interface externa. É necessário verificar o impacto na CPU da memória do linkmgr e do sessmgr com esse excesso de carga.

As realocações de assinatura PTMSI e PTMSI não causarão o pico na sinalização diretamente, mas é sempre importante definir valores de alta frequência para que os PTMSIs estejam disponíveis com instâncias do sessmgr (o que acontece raramente). Não é recomendável alterar PTMSI para cada procedimento de uplink da UE, uma vez que esta não é a melhor prática. Um valor de 10 pode ser decente. Depois de todas essas alterações, é importante monitorar e executar verificações de integridade 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

Troubleshoot

Quando a autenticação deve ser executada ou a assinatura PTMSI ou PTMSI deve ser alocada, os logs de depuração serão impressos para capturar o motivo pelo qual o procedimento foi concluído. Isso ajuda na solução de problemas em caso de discrepâncias. Esses registros incluem a configuração do cc-profile e o valor atual de todos os contadores e o movimento da lógica de decisão através das várias configurações e contadores. Além disso, os valores atuais do contador por assinante podem ser vistos com os comandos show subscribers sgsn-only ou show subscribers gprs-only.

Uma saída de exemplo disso é fornecida. Os contadores atuais e o timestamp autenticado mais recente são adicionados à saída completa do comando show subscribers.

[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 o problema for observado na rede, insira estes comandos para coletar informações para a unidade de negócios a ser usada para analisar o problema ainda mais:

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

Aumento da sinalização em direção às interfaces Gr/Iu, além de um leve impacto na CPU do processo interno (linkmgr) se você autenticar com muita frequência.

Sintaxe do comando

Todos os comandos estão no modo de configuração/controle de chamada-perfil e os privilégios de operador se aplicam. Um instantâneo dos comandos no perfil cc é o seguinte:

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]}