Comportamento GSN con errori di attivazione PDP e nessuna risposta echo GTP

Introduzione

In questo documento viene descritto il comportamento del GPRS (General Packet Radio Service) Gateway (GPRS) Supporting Node (GSN) quando il GPRS Supporting Node (SGSN) al servizio non risponde alla richiesta echo GTP (GPRS Tunneling Protocol) inviata dal GSN.

Premesse

Si potrebbero verificare errori di attivazione del protocollo PDP (Packet Data Protocol) elevati nel GSN durante un periodo di tempo in cui il SGSN non risponde alle richieste echo GTP. Di seguito sono riportate alcune domande che potrebbero sorgere in questo scenario:

1. Le richieste Create PDP o Update PDP dal SGSN arrivano al GSN?
   
   
2. Quando le richieste echo GTP dal GSN ai SGSN hanno esito negativo, come deve comportarsi il GSN se il contesto Update PDP inviato dal GSN non riceve una risposta?
   
   
3. In che modo un GSN non riesce a un PDP se non riceve una risposta echo GTP o una risposta per i messaggi di richiesta non echo ricevuti da un SGSN per tale PDP?
   
   
4. In che modo la mancanza di risposte echo/non echo GTP influisce direttamente sugli errori di attivazione PDP?

Comportamento GSN

Se i messaggi non arrivano al GSN, il SGSN attiva un allarme di errore di percorso e li rifiuta in modo invisibile all'utente. Inoltre, se non viene ricevuta alcuna risposta echo per la richiesta echo avviata dal GSN, il peer è inattivo, quindi il GSN cancella localmente le chiamate correlate a tale peer.

Nell'output del comando show support details o show gtpc statistics verbose, è possibile visualizzare i contatori GSN Req Timeout:

#show gtpc statistics verbose 

SGSN Restart:                       Timeout:
    Create PDP Req:                 5   GTPC Echo Timeout:          149160
    Update PDP Req:                 0   GTPU Echo Timeout:               0
    Echo Response:                312   GGSN Req Timeout:            24182

Path Management Messages:
  Echo Request RX:         34006780   Echo Response TX:         34006780
  Echo Request TX:         29603851   Echo Response RX:         29537123

Se si esaminano i messaggi di richiesta echo trasferiti dal GSN al SGSN, risulta che il GSN non riceve le risposte echo. È necessario verificare che i messaggi non vengano eliminati a causa di problemi di routing sulla rete o che il servizio SGSN non sia disponibile.

Il problema più comune è rappresentato dagli errori del percorso di controllo, che rendono irraggiungibile un numero elevato di SGSN mobili.

Se esiste un messaggio di controllo GTP (ad esempio una richiesta di aggiornamento del contesto PDP) dal GSN che non riceve una risposta dopo tutti i tentativi esauriti, il GSN ritiene che il peer non sia raggiungibile e interrompe solo quella sessione specifica segnala la causa come Errore percorso. Il contesto PDP viene eliminato nel GSN, ma il SGSN non viene notificato. Il conteggio è identificato dalle seguenti statistiche:

SGSN Restart:                       Timeout:
    Create PDP Req:                 5   GTPC Echo Timeout:          149160
    Update PDP Req:                 0   GTPU Echo Timeout:               0
    Echo Response:                312   GGSN Req Timeout:            24182


Update PDP Context Denied:
  No Resources:                 500   No Memory:                       0
  System Failure:                 0   Non-existent:                55460

Il GSN ora interrompe la sessione di contesto PDP e non invia alcuna notifica al SGSN o all'apparecchiatura utente (UE). SGSN o UE potrebbe attivare una richiesta di aggiornamento del contesto PDP e il GSN potrebbe rifiutarla con un codice causa 192 (inesistente).

Di seguito è riportata una sezione tratta da TS 29.060:

• Se un GSN (Gprs Supporting Node) riceve un messaggio GTP-C (Gprs Tunneling Protocol-Control Plane) che richiede un'azione correlata a un contesto PDP che il nodo mittente ritiene esistere ma che non è riconosciuto dal nodo ricevente, quest'ultimo deve restituire all'origine del messaggio una risposta con il valore di causa appropriato (Inesistente o Contesto non trovato).  L'identificatore dell'endpoint del tunnel usato nel messaggio di risposta deve essere impostato su tutti gli zero.
• Se SGSN riceve una risposta al contesto PDP di aggiornamento con un valore di causa "Inesistente", it elimina il contesto PDP.

Errore codice causa 192

Il Cause Code 192 (o non esistente) è un errore inviato dai GSN sull'interfaccia Gn. Viene popolato nell'elemento di informazione Causa dei messaggi GTP.

Di seguito sono riportati i messaggi GTP che possono avere un errore Cause Code 192:

• Update_PDP_Context_Response
  
  
• Delete_PDP_Context_Response

Nota: Il valore TEID (Tunnel End Identifier) utilizzato nel messaggio contenente l'errore sarà zero. Fare riferimento a TS 29.060 per ulteriori dettagli.

È possibile che questo errore venga visualizzato nei messaggi sopra citati quando viene inviato da un GSN e non dispone di un contesto corrispondente a quello inviato dall'altro GSN. I GSN eliminano il contesto PDP alla ricezione dell'errore.

Scenari di esempio

In questa sezione vengono descritti quattro scenari in cui può verificarsi un errore del Cause Code 192.

• Scenario 1 - Si verifica un errore di percorso GTP-C tra i GSN.
  
  
• Scenario 2 - Errore di richiesta/risposta echo tra i GSN.
  
  
• Scenario 3: esiste un problema di handoff da GTP versione 1 (GTPv1) a GTP versione 0 (GTPv0) che causa l'errore. Di seguito è riportato un esempio di flusso di chiamata per questo scenario:
  
  
  1. È stata stabilita una richiesta di creazione del contesto PDP con GTPv1.
     
     
  2. Si verifica l'handoff da GTPv1 a GTPv0.
     
     
  3. La chiamata al GSN è ora in GTPv0.
     
     
  4. Il GSN riceve la richiesta di aggiornamento del contesto PDP con un TEID di intestazione diverso da zero e la rifiuta a causa dell'errore (inesistente).

     Nota: Il SGSN deve aver dimenticato il TEID, in quanto la chiamata viene spostata in GTPv0 (per GTPv0 esistono solo etichette di flusso, non TEID). Ciò indica che il SGSN ha mantenuto la chiamata GTPv1 anche dopo il passaggio a GTPv0.

• Scenario 4 - L'effetto TEID non sincronizzato viene moltiplicato. Di seguito è riportato un esempio:
  
  
  1. L'UE1 stabilisce un contesto PDP; il SGSN assegna il Control-TEID-1 (C-TEID-1) come TEID di controllo verso il GSN sul contesto sgsn-UE1-ctxt. Il C-TEID di tutti i messaggi sul GSN che si dirigono verso il SGSN ha il C-TEID-1.
     
     
  2. Un timeout del messaggio di segnalazione (non echo) sul SGSN e il SGSN pulisce localmente il contesto sgsn-UE1-ctxt. Informa anche il Radio Network Controller (RNC) per pulire. Non informa il GSN, in quanto considera il GSN inattivo. A questo punto non è presente alcun contesto PDP per UE1 nell'SGSN e il contesto PDP per la stessa UE1 esiste nel GSN con C-TEID-1. Il C-TEID-1 torna alla fine dell'elenco di disponibilità.
     
     
  3. UE2 desidera quindi stabilire un contesto PDP allo stesso APN e passa attraverso lo stesso SGSN e GSN. Nel SGSN, il TEID viene allocato e un contesto sgsn-UE2-ctxt viene inviato al GSN. Se il numero di TEID liberi è basso, il TEID liberato di recente viene riallocato nel nuovo contesto PDP. In questo caso, C-TEID-1 viene riassegnato a UE2.
     
     
  4. Sul GSN, ci sono due contesti con C-TEID-1 come Gn C-TEID. Il GSN non verifica se esiste già un TEID per lo stesso. Il GSN avvia quindi un Delete PDP Context (DPC) per UE1 verso il SGSN.
     
     
  5. Sul SGSN, viene trovato il C-TEID-1, insieme al relativo contesto, che è sgsn-UE2-Ctxt. Si è tentato di eliminare il contesto e rispondere al GSN.
     
     
  6. Se sono presenti richieste avviate da GSN (aggiornamento/eliminazione PDP) per gli altri contesti, il SGSN risponde con una causa Contesto non trovato.
     
     
  7. Il GSN rifiuta la risposta DPC per UE2 perché non ha mai inviato una richiesta DPC per UE2.
     
     
  8. Nel GSN è disponibile un secondo contesto che non corrisponde ad alcun contesto nel SGSN.
     
     
  9. Se lo stesso C-TEID-1 è assegnato a un altro UE, il problema si ripete e si aggrava.

Di seguito è riportata una sezione tratta da TS 29.060:

Risposta echo

Il messaggio è inviato in risposta a una richiesta echo ricevuta.

Il GSN che riceve una risposta echo da un GSN peer confronta il valore del contatore di riavvio ricevuto con il valore del contatore di riavvio precedente archiviato per tale GSN peer. Se non è stato memorizzato alcun valore precedente, il valore del contatore di riavvio ricevuto nella risposta echo verrà memorizzato per il GSN peer.

Il valore di un contatore di riavvio precedentemente archiviato per un GSN peer può essere diverso dal valore del contatore di riavvio ricevuto nella risposta echo dal GSN peer. In tal caso, il numero di serie che ha inviato la risposta echo è considerato riavviato dal numero di serie che ha ricevuto la risposta echo. Il nuovo valore del contatore di riavvio ricevuto deve essere memorizzato dall'entità ricevente, sostituendo il valore precedentemente memorizzato per il GSN di invio.

Se il GSN di invio è un GSN e il GSN di ricezione è un SGSN, il SGSN considera inattivi tutti i contesti PDP che utilizzano il GSN. Per ulteriori azioni della SGSN fare riferimento alle specifiche tecniche del progetto di partenariato di terza generazione (3GPP) (TS) 23.007 [3].

Se il GSN di invio è un SGSN e il GSN di ricezione è un GSN, il GSN considera inattivi tutti i contesti PDP che utilizzano il SGSN. Per ulteriori azioni del GSN fare riferimento al documento 3GPP TS 23.007 [3].

Di seguito è riportata una sezione tratta da 3GPP TS 23.007 V8.0:

Ripristino dei dati nella SGSN

Riavvio di SGSN

Dopo un riavvio SGSN, il SGSN elimina tutti i contesti Mobility Management(MM), PDP, Multimedia Broadcast Multicast Services (MBMS) UE e MBMS Bearer interessati dal riavvio. L'archiviazione SGSN dei dati è volatile, ad eccezione di quanto specificato in questa sottoclausola. Il SGSN conserva nella memoria volatile un contatore GSN Restart per ogni GSN con cui il SGSN è in contatto e nella memoria non volatile contatori SGSN Restart relativi a ogni GSN con cui il SGSN è in contatto. I contatori di riavvio SGSN vengono incrementati e tutti i contatori di riavvio GSN vengono cancellati subito dopo il riavvio di SGSN.  È possibile che il contatore di riavvio sia comune a tutti i GSN oppure che esista un contatore separato per ogni GSN.

Il GSN esegue una funzione di polling (richiesta echo e risposta echo) nei confronti dei SGSN con cui il GSN è in contatto. Nella risposta echo deve essere incluso il contatore di riavvio SGSN. Se il valore ricevuto nel GSN è diverso da quello memorizzato per tale SGSN, il GSN considererà che è stato riavviato (vedere 3GPP TS 29.060). I contatori di riavvio del GSN vengono aggiornati nel SGSN sul valore ricevuto nel primo messaggio echo proveniente da ciascun GSN dopo il riavvio del SGSN.

Quando il GSN rileva un riavvio in un SGSN con il quale ha attivato uno o più contesti PDP, elimina tutti questi contesti PDP . Inoltre, il nuovo valore del contatore di riavvio SGSN ricevuto nella risposta echo dal SGSN riavviato è aggiornato nel GSN.