Contenido

Introducción

Problema

Secuencia de eventos que llevan a una alarma M3UA en SGSN

Trampas SGSN

Registro de seguimiento

Solución

Información Relacionada

Introducción

Este documento describe el problema y la solución relacionados con los enlaces de capa de adaptación de usuario (M3UA) de nivel 3 de MTP (parte de transferencia de mensajes) que van a un estado de congestión o estado de inestabilidad, después de una interrupción de red importante o una actualización de software del nodo de servicio (SGSN) del router de servicios de agregación (ASR) de Cisco que atiende GPRS (servicio de radio de paquetes general). Esto sucede normalmente en los escenarios de interoperabilidad en los que el nodo ASR 5000 está conectado a nodos de terceros, como Home Location Register (HLR) o Radio Access Network (RNC).

Problema

El problema subyacente es que la SGSN ASR 5000 recibe un tamaño de ventana de baja publicidad en la capa de protocolo de transmisión de control de transmisión (SCTP) desde el nodo de peer remoto, el nodo de punto de transferencia de señalización (STP), HLR o RNC. El tamaño bajo de la ventana se puede ver en el seguimiento de captura de paquetes, el comando show SCTP o el seguimiento del protocolo de monitoreo en el SGSN. En la captura de paquetes puede ver el tamaño de ventana anunciado en el mensaje SCTP SACK con un valor de cero o cercano a cero. Cuando esto sucede, SGSN provoca una alarma M3UA para informar al nodo de peer que no envíe el paquete desde ese punto final de peer. Esto hace que el link SCTP inestable o entre en un estado congestionado. Dado que SGSN envía un tamaño de ventana normal, continúa recibiendo datos M3UA de nodos de peer, pero esos paquetes podrían caer en la cola de espera si el nodo de peer nunca sale de la congestión.

Secuencia de eventos que llevan a una alarma M3UA en SGSN

1. SCTP envía una indicación de inicio del control de flujo a M3UA.

2. SCTP envía una indicación de detención del control de flujo a M3UA.

3. M3UA establece el indicador activo de congestión para la asociación y comienza a sondear SCTP periódicamente sobre su estado de control de flujo.

4. Mientras una asociación se encuentra en control de flujo, M3UA coloca en cola las futuras solicitudes de datos para esa asociación hasta que se alcance QUEUE_SIZE. En ese momento, se descartan los mensajes futuros para la asociación. M3UA propaga la información de congestión de asociación a los pares remotos individuales que forman parte de la asociación.

5. M3UA borra el indicador de congestión para la asociación y detiene el sondeo de SCTP.

6. M3UA transmite cualquier cosa en su cola de congestión para esa asociación a SCTP.

Trampas SGSN

Tue Feb 11 07:03:12 2014 Internal trap notification 1074

(M3UAPSPCongested) ss7-routing-domain-1 peer-server-1

peer-server-process-1 (point-code-13959424) congested

Tue Feb 11 07:03:12 2014 Internal trap notification 1056

(SS7PCCongested) ss7-routing-domain-1 point-code-13959424 congested

Tue Feb 11 07:03:13 2014 Internal trap notification 1075

(M3UAPSPCongestionCleared) ss7-routing-domain-1 peer-server-1

peer-server-process-1 (point-code-13959424) congestion cleared

Tue Feb 11 07:03:13 2014 Internal trap notification 1057

(SS7PCCongestionCleared) ss7-routing-domain-1 point-code-13959424 congestion cleared

Registro de seguimiento

Peer Server Id :        2   Peer Server Process Id:        1

Association State : ESTABLISHED

Flow Control Flag                       :                TRUE

Peer INIT Tag                           :                17282

SGSN INIT Tag                           :           3011555404

Next TSN to Assign to

Outgoing Data Chunk                   :            324019883

Lowest cumulative TSN acknowledged      :            324019882

Cumulative Peer TSN arrived from peer   :           2204328608

Last Peer TSN sent in the SACK          :           2204328607

Self RWND                               :              1048576 <- SGSN sends

this window size

Advertised RWND in received SACK        :                   32 <- peer sends

this window size

Peer RWND(estimated)                    :                   32 <- Estimated window

also goes down which cause SGSN not able to send packets on wire

Retransmission counter                  :                    0

Zero Window Probing Flag                :                FALSE

Last Tsn received during ZWnd Probing   :                    0

Bytes outstanding on all

addresses of this association        :                    0

Congestion Queue Length                 :                    0

Ordered TSN assignment Waiting QLen     :                 7690

Unordered TSN assignment Waiting QLen   :                    0

Total number of GAP ACKs Transmitted    :                    2

Total number of GAP ACKs Received       :                 2037

Solución

Siempre que se producen inestabilidades o congestión de forma continua en los links, esto indica que el nodo de peer no procesa la solicitud a tiempo debido a las solicitudes abrumadoras que vienen de SGSN, o SGSN podría recibir un número abrumador de solicitudes de la red debido a la congestión de la red o a un problema de red.

Una solución alternativa para salir de esta condición es bloquear y desbloquear los links asociados con esta congestión o inestabilidad. Otra forma es quitar y volver a agregar la instancia del proceso de señalización de pares (PSP) asociada a esta congestión o inestabilidad.

Información Relacionada

- Guía de administración de SGSN ASR5000 - Cisco Systems

- Soporte Técnico y Documentación - Cisco Systems