Enciclopedia
2026-08-28 18:06:11
¿Cómo se enruta la señalización N2 de 5G hasta la AMF?
Explica cómo se enruta la señalización N2 de 5G desde el gNB hasta la AMF mediante NGAP, SCTP, redes de transporte y conmutadores del centro de datos, con orientación práctica sobre enrutamiento, reenvío y diagnóstico mediante capturas de paquetes.

Becke Telcom

¿Cómo se enruta la señalización N2 de 5G hasta la AMF?

Al capturar la señalización de registro 5G, los ingenieros suelen encontrar sin demasiada dificultad mensajes como Initial UE Message, Uplink NAS Transport y otros procedimientos NGAP. La cuestión más compleja suele estar por debajo: ¿cómo sale un paquete de señalización N2 del gNB, atraviesa la red de transporte y el centro de datos y llega finalmente al servidor que aloja el servicio AMF? Si la AMF está virtualizada y se ejecuta en una VM, ¿con qué punto final establece realmente el gNB su asociación SCTP? ¿Qué funciones desempeñan la puerta de enlace PTN, el router perimetral del centro de datos y los conmutadores EOR y TOR? Y cuando falla la señalización, ¿debe comenzar el diagnóstico por NGAP, SCTP, el enrutamiento IP o el reenvío MAC de Capa 2?

Estas preguntas parecen pertenecer a ámbitos de ingeniería distintos. El equipo de radio se centra en el gNB, el equipo de red troncal en la AMF y NGAP, el equipo de transporte gestiona la PTN y el equipo del centro de datos se ocupa de los conmutadores y servidores. Sin embargo, en una ruta N2 operativa todos estos componentes funcionan como una cadena continua. Un NAS Registration Request recibido por el gNB no “salta” directamente a la AMF. El gNB primero retransmite el mensaje desde el lado RRC hacia NGAP, lo encapsula sobre SCTP e IP, lo envía a través de varios nodos de red de Capa 3 y Capa 2 y finalmente lo entrega al entorno de cómputo donde se ejecuta el proceso AMF. El diagnóstico del enrutamiento N2 resulta mucho más sencillo cuando se observan conjuntamente la ruta lógica de protocolos y la ruta física de red, en lugar de reducirlo a una simple prueba de “¿puedo hacer ping a la AMF?”.

¿Qué reenvía realmente la interfaz N2?

N2 es la interfaz de señalización entre el gNB y la AMF. Para el registro del UE, la gestión de movilidad y otros procedimientos del plano de control 5G, el UE genera mensajes NAS mientras el gNB realiza una función crítica de retransmisión. Toma el NAS-PDU recibido del UE, lo transporta dentro del mensaje NGAP correspondiente y lo envía hacia la AMF por N2. En el sentido descendente se aplica el proceso inverso. Por ello, para entender la señalización N2 hay que separar el propio mensaje de aplicación de la ruta de transporte que lo lleva.

Pensemos en un UE que inicia el registro. Primero envía un NAS Registration Request hacia el gNB a través de la pila de protocolos de radio. Para este tipo de señalización, el gNB no es el punto final de aplicación. Su función es insertar el NAS-PDU en un mensaje NGAP y reenviarlo hacia la AMF mediante la relación de transporte N2 ya establecida. A alto nivel, en el lado del UE el mensaje se procesa mediante NAS, RRC, PDCP, RLC, MAC y L1. En el gNB, el mensaje NAS se retransmite desde la pila de radio hacia NGAP y después se transporta sobre SCTP, IP, Capa 2 y Capa 1. En la AMF, el paquete se desencapsula siguiendo la pila inversa hasta que el mensaje NAS llega a la capa de procesamiento NAS.

Un error habitual es considerar que “el gNB reenvía NAS” de la misma forma que un router IP reenvía paquetes. Son funciones que ocurren en capas distintas. El gNB primero realiza una retransmisión a nivel de protocolo desde NAS/RRC hacia NGAP y crea un nuevo paquete SCTP/IP del lado N2. La red de transporte y la red del centro de datos no necesitan saber si la carga útil contiene un Registration Request u otro procedimiento NAS. Su trabajo consiste simplemente en mover el paquete de acuerdo con el enrutamiento IP, el direccionamiento MAC y la información de las interfaces.

Los procedimientos NGAP también pueden dividirse en procedimientos asociados a un UE y procedimientos no asociados a un UE. NAS Transport e Initial Context Setup son procedimientos asociados a un UE, mientras que NG Setup es un procedimiento a nivel de nodo no asociado a un UE. Esta distinción resulta útil durante el diagnóstico. Si todos los UE de un gNB no pueden comunicarse con la AMF, conviene comprobar primero la relación N2 a nivel de nodo, SCTP y el enrutamiento IP. Si solo está afectado un UE, la investigación debe continuar siguiendo el contexto NGAP y NAS de ese UE.

Pila de protocolos N2 de 5G en la que un mensaje NAS del UE llega al gNB mediante RRC, se encapsula en NGAP y SCTP y después se transporta por IP hasta la AMF
La señalización NAS del UE llega al gNB a través de la pila de radio, se retransmite hacia NGAP y después se transporta sobre SCTP e IP hasta la AMF.

¿Qué nodos de red atraviesa la señalización N2 entre el gNB y la AMF?

Los diagramas lógicos de arquitectura suelen representar N2 como una sola línea entre el gNB y la AMF. Esta representación es útil para explicar la relación de la interfaz, pero no muestra la ruta real de red que sigue el tráfico de señalización. En un despliegue real, el gNB rara vez está conectado directamente a un servidor AMF mediante un único enlace físico. Entre la RAN y el centro de datos de la red troncal existe una red de transporte, y dentro del propio centro de datos se utilizan routers, conmutadores y redes de servidores.

Una ruta de transporte N2 simplificada puede representarse así: el gNB envía el tráfico a una puerta de enlace PTN de Capa 3; el paquete atraviesa la red de transporte y llega al router perimetral de Capa 3 del centro de datos; luego pasa por los conmutadores EOR y TOR antes de llegar al servidor que aloja la AMF. La PTN transporta el tráfico IP del lado del gNB hacia el centro de datos regional o central. El router de Capa 3 situado en el límite del centro de datos enruta después el paquete N2 hacia la red de servidores correcta. Dentro del centro de datos, los conmutadores EOR y TOR realizan conmutación de Capa 2 hasta que la trama Ethernet alcanza la interfaz del servidor que soporta la carga de trabajo de la AMF.

En una red troncal 5G basada en la nube, la pregunta “¿en qué equipo está la AMF?” no puede responderse únicamente en términos de un servidor físico. La AMF puede ejecutarse como una función de red virtualizada en un nodo de cómputo de propósito general, y el mismo servidor físico también puede alojar máquinas virtuales OAM, otras funciones de red o múltiples instancias de servicio. Por ejemplo, una VM puede ejecutar el servicio AMF responsable del procesamiento de NAS, NGAP y SCTP. Desde el punto de vista del gNB, sin embargo, lo importante es el punto final IP del servicio N2 expuesto por la AMF, no la etiqueta del servidor físico del rack.

Esto significa que el diagnóstico de N2 implica al menos tres conceptos diferentes de ubicación. La ubicación física identifica el rack y el host físico donde se ejecuta la carga de trabajo. La ubicación lógica identifica la VM o instancia de servicio que aloja la AMF. La ubicación de red es la dirección IP N2 de la AMF que utiliza el gNB al establecer la asociación SCTP. Es perfectamente posible que el servidor físico, la VM y el proceso AMF parezcan estar en buen estado y, aun así, N2 siga siendo inaccesible porque la VLAN, la puerta de enlace predeterminada, la ruta IP, el puerto del conmutador o la capa de conmutación virtual no entregan correctamente el tráfico a esa dirección N2.

Topología física y lógica N2 de 5G en la que un gNB atraviesa la red de transporte PTN, el router del centro de datos y los conmutadores EOR y TOR antes de llegar a un servidor que aloja una máquina virtual AMF
N2 conecta lógicamente el gNB y la AMF, pero la ruta física puede atravesar la PTN, un router del centro de datos, conmutadores EOR y TOR y el entorno de servidores que aloja la VM o instancia de servicio de la AMF.

¿Cuál es la diferencia entre enrutamiento y reenvío en la ruta N2?

Entregar un paquete de señalización N2 a la AMF implica algo más que disponer de una tabla de rutas. Desde la perspectiva del procesamiento de red, es importante distinguir entre enrutamiento y reenvío. El enrutamiento suele ser una función de Capa 3. Cuando un dispositivo recibe un paquete IP, busca la dirección IP de destino en su tabla de rutas, determina la interfaz de salida y selecciona el siguiente salto adecuado. A lo largo de la ruta N2, el gNB, la puerta de enlace PTN de Capa 3 y el router perimetral del centro de datos necesitan la información de enrutamiento IP correspondiente. Esas rutas pueden configurarse de forma estática o aprenderse mediante un protocolo de enrutamiento dinámico.

Supongamos que la dirección de origen N2 del gNB es A y la dirección N2 de la AMF es B. El gNB no necesita saber en qué rack físico de servidores se encuentra B. Solo necesita saber qué puerta de enlace de siguiente salto debe recibir los paquetes destinados a la subred que contiene B. Los dispositivos de Capa 3 de la PTN toman la misma decisión utilizando sus propias tablas de rutas hasta que el paquete entra en la red del centro de datos que contiene la AMF.

El enrutamiento determina adónde debe ir el paquete a continuación, pero el paquete todavía tiene que transmitirse por el enlace físico actual. Si se utiliza Ethernet, el dispositivo añade una cabecera de trama Ethernet con direcciones MAC de origen y destino. El conmutador reenvía entonces la trama según su tabla de direcciones MAC. Como resultado, la cabecera externa de Capa 2 del mismo paquete IP N2 puede cambiar al atravesar distintos saltos de Capa 3. La capa IP sigue representando la relación extremo a extremo entre el gNB y la AMF, mientras que las direcciones MAC solo son relevantes para el segmento de Capa 2 actual.

Dentro del centro de datos, los conmutadores EOR y TOR realizan principalmente conmutación de Capa 2. Una vez que el router de Capa 3 del centro de datos entrega el paquete N2 al dominio de Capa 2 correcto del lado de los servidores, los conmutadores EOR y TOR utilizan sus tablas MAC para llevar la trama hasta el puerto del servidor de destino. Esta distinción es importante al analizar capturas. Ver direcciones MAC distintas en diferentes puntos de captura no significa que el paquete haya cambiado su destino final, y que las direcciones IP de origen y destino no cambien tampoco significa que el paquete haya viajado directamente entre los dos extremos sin atravesar dispositivos intermedios.

¿Por qué la asociación SCTP es el límite clave en el diagnóstico de N2?

NGAP no se ejecuta directamente sobre IP, sino sobre SCTP. Por tanto, una ruta N2 utilizable requiere primero conectividad IP y después el establecimiento correcto de la asociación SCTP. Esto crea una dependencia clara de diagnóstico: si el enrutamiento IP está roto, SCTP no puede establecerse; sin SCTP, NGAP no puede funcionar; y sin NGAP, la señalización NAS no puede retransmitirse correctamente.

Lo contrario, sin embargo, no es necesariamente cierto. Poder hacer ping a la AMF solo demuestra cierto nivel de conectividad IP. No demuestra que el servicio SCTP necesario sea accesible, que la asociación SCTP pueda establecerse, que los parámetros NGAP sean correctos ni que el proceso de aplicación de la AMF funcione con normalidad.

  • Primero, verifique la ruta IP. Compruebe la dirección N2 del gNB, la máscara de subred, la puerta de enlace predeterminada y la ruta hacia la dirección N2 de la AMF. Después confirme que la puerta de enlace PTN y los dispositivos de Capa 3 del centro de datos disponen tanto de la ruta de ida como de la ruta de retorno. La ruta de retorno es especialmente fácil de pasar por alto. Un paquete que sale del gNB puede llegar correctamente a la AMF mientras que la AMF no tiene una ruta válida de regreso a la subred del gNB. Como N2 es una interfaz de señalización bidireccional, ambos sentidos deben funcionar.

  • Segundo, confirme que SCTP está realmente establecido. Una vez verificada la conectividad IP, compruebe si el gNB y la AMF completan el procedimiento de asociación SCTP y entran en el estado Established. Si la asociación nunca llega a establecerse, revise los puertos de la capa de transporte, las vinculaciones IP locales, las ACL, los cortafuegos y cualquier política de seguridad aplicada en la ruta. Los centros de datos reales también pueden incluir IDS/IPS, balanceadores de carga, componentes SDN u otros sistemas de seguridad y control de tráfico que pueden afectar a SCTP aunque no aparezcan en los diagramas de arquitectura simplificados.

  • Tercero, pase al análisis de NGAP y NAS. NG Setup, Initial UE Message y NAS Transport solo deben analizarse después de que la asociación SCTP sea estable. Si SCTP funciona pero falla NG Setup, el problema ha pasado por encima de la capa de transporte IP y se encuentra en la lógica de aplicación o configuración N2. Si NG Setup tiene éxito pero la señalización de registro de un UE concreto no llega a la AMF, continúe siguiendo Initial UE Message, los valores UE-NGAP-ID y el NAS-PDU. Este enfoque por capas evita un error habitual: comenzar a diagnosticar NAS antes de confirmar que el mensaje NAS realmente atravesó la interfaz N2.

¿Cómo puede una captura de paquetes reconstruir la ruta completa de señalización N2?

El verdadero valor de comprender el enrutamiento N2 aparece durante la captura de paquetes y el aislamiento de fallos. Al diagnosticar un caso en el que falla la señalización entre el gNB y la AMF, la ruta debe comprobarse desde las capas de transporte hacia arriba. El punto de captura importa. Una traza en el lado del gNB confirma si la señalización sale realmente de la estación base. Una captura cerca de la PTN o del borde del centro de datos ayuda a determinar si el paquete entra en la región de la red troncal. Una captura en el servidor muestra si el paquete N2 llega físicamente al host donde se ejecuta la carga de trabajo AMF. Si la traza del gNB muestra paquetes SCTP INIT transmitidos pero el host AMF nunca los ve, el fallo está casi con seguridad en la red intermedia y no en la lógica de aplicación NGAP.

Después de capturar el paquete, verifique que las direcciones IP de origen y destino coincidan con el diseño previsto. Si la AMF se migró, se amplió o se movió a una nueva VM mientras el gNB sigue apuntando a una dirección N2 antigua, la señalización puede seguir una ruta incorrecta aunque la configuración NGAP parezca no haber cambiado. A continuación, inspeccione la ruta salto a salto a través de los dispositivos de Capa 3. En el gNB, la puerta de enlace PTN y el router del centro de datos, compruebe la ruta hacia la subred de la AMF, incluida la interfaz de salida, el siguiente salto y la ruta de retorno. Si se utiliza enrutamiento dinámico, confirme que la ruta se ha aprendido realmente y se ha instalado en la tabla de reenvío, en lugar de limitarse a comprobar que el protocolo de enrutamiento está habilitado en la configuración.

Cuando el paquete llega al límite de Capa 3 del centro de datos pero sigue sin alcanzar el servidor AMF, el diagnóstico pasa del enrutamiento IP al reenvío de Capa 2. Compruebe la pertenencia a VLAN en los conmutadores EOR y TOR, el aprendizaje de direcciones MAC, el estado de los puertos orientados al servidor y si el servidor o la capa de conmutación virtual están conectados a la red de servicio correcta. Por último, relacione los hallazgos de red con el estado SCTP. Si la ruta IP bidireccional está sana pero SCTP sigue sin poder establecerse, investigue el tratamiento de puertos SCTP, la vinculación IP y el propio proceso AMF. Una vez establecido SCTP, el análisis de NGAP y NAS puede continuar con un límite de fallo mucho más claro.

Ruta de diagnóstico de señalización N2 de 5G desde el gNB, pasando por una puerta de enlace PTN de Capa 3, el router del centro de datos y los conmutadores EOR y TOR de Capa 2, hasta el servidor AMF y la asociación SCTP
El diagnóstico de N2 puede seguir paso a paso la ruta real del paquete: primero verificar el enrutamiento de Capa 3, después el reenvío de Capa 2 en el centro de datos y, por último, el procesamiento SCTP, NGAP y NAS.

Visto de extremo a extremo, el “enrutamiento de señalización N2” consta en realidad de dos procesos distintos pero continuos. El primero ocurre dentro del gNB. Un mensaje NAS llega desde el UE por el lado radio, se retransmite hacia un mensaje NGAP y después se encapsula sobre SCTP e IP para poder transportarse por la red N2.

El segundo proceso ocurre dentro de la red de transporte y el centro de datos. Estos dispositivos de red no necesitan saber si la carga útil contiene un Registration Request o un procedimiento Initial Context Setup. Utilizan el enrutamiento IP de Capa 3 y el reenvío MAC de Capa 2 para mover el paquete salto a salto hacia el entorno de cómputo donde se ejecuta el servicio AMF.

Por tanto, en ingeniería práctica, la forma más eficaz de diagnosticar N2 es mantener una visión de extremo a extremo:

UE NAS → retransmisión del gNB → NGAP → SCTP → enrutamiento IP → reenvío de Capa 2 → servidor AMF → proceso AMF

Una vez que se sigue esta cadena capa por capa, muchos problemas que al principio parecen complejos “fallos de registro”, “N2 inaccesible” o “fallos de asociación SCTP” pueden reducirse a una pregunta mucho más concreta: ¿en qué capa y en qué salto se detuvo el paquete?

Preguntas frecuentes

¿La señalización N2 pasa por la UPF?

En la arquitectura 5G normal, la ruta del plano de control N2 no depende de la UPF. N2 conecta el gNB y la AMF, mientras que la UPF participa principalmente en la ruta del plano de usuario. Cuando N2 no es accesible, el diagnóstico debe centrarse en la ruta de transporte del plano de control entre el gNB y la AMF, en lugar de comenzar por el túnel del plano de usuario N3.

¿Por qué cambian las direcciones MAC al capturar el mismo paquete N2 en puntos diferentes?

Las direcciones MAC pertenecen al segmento de Capa 2 actual. Después de que un paquete atraviesa un dispositivo de enrutamiento de Capa 3, se encapsula con una nueva cabecera de Capa 2 para el enlace siguiente. Por ello, las direcciones MAC de origen y destino pueden cambiar de un salto a otro aunque las direcciones IP extremo a extremo del gNB y la AMF sigan asociadas al mismo flujo de comunicación N2.

¿Por qué puede seguir fallando SCTP aunque el gNB pueda hacer ping a la AMF?

Ping verifica principalmente la conectividad IP basada en ICMP. SCTP también depende del tratamiento de puertos de transporte, la vinculación IP local, las ACL, los cortafuegos, las políticas de seguridad y el proceso de aplicación de la AMF. Por tanto, la conectividad IP es solo un requisito previo para la comunicación N2 y no garantiza que SCTP o NGAP funcionen correctamente.

Si la AMF se ejecuta en una máquina virtual, ¿el gNB necesita conocer la ubicación física del servidor?

No. El gNB establece la conexión N2 utilizando la dirección IP del servicio N2 de la AMF, no la ubicación física del servidor. El host físico, el conmutador virtual, la asignación de la VM y la topología interna del centro de datos son detalles de implementación, pero aun así deben entregar los paquetes dirigidos al punto final N2 de la AMF a la instancia de servicio correcta.

¿Por qué deben comprobarse tanto las rutas de ida como las de retorno en los problemas de N2?

NGAP y SCTP son bidireccionales. Aunque los paquetes del gNB puedan llegar a la AMF, el intercambio SCTP y los procedimientos NGAP posteriores seguirán fallando si la AMF no dispone de una ruta válida de regreso a la subred del gNB. Por tanto, la conectividad en un solo sentido no basta para demostrar que la ruta N2 está completa.

Productos Recomendados
Catálogo
Servicio al cliente Teléfono
We use cookie to improve your online experience. By continuing to browse this website, you agree to our use of cookie.

Cookies

This Cookie Policy explains how we use cookies and similar technologies when you access or use our website and related services. Please read this Policy together with our Terms and Conditions and Privacy Policy so that you understand how we collect, use, and protect information.

By continuing to access or use our Services, you acknowledge that cookies and similar technologies may be used as described in this Policy, subject to applicable law and your available choices.

Updates to This Cookie Policy

We may revise this Cookie Policy from time to time to reflect changes in legal requirements, technology, or our business practices. When we make updates, the revised version will be posted on this page and will become effective from the date of publication unless otherwise required by law.

Where required, we will provide additional notice or request your consent before applying material changes that affect your rights or choices.

What Are Cookies?

Cookies are small text files placed on your device when you visit a website or interact with certain online content. They help websites recognize your browser or device, remember your preferences, support essential functionality, and improve the overall user experience.

In this Cookie Policy, the term “cookies” also includes similar technologies such as pixels, tags, web beacons, and other tracking tools that perform comparable functions.

Why We Use Cookies

We use cookies to help our website function properly, remember user preferences, enhance website performance, understand how visitors interact with our pages, and support security, analytics, and marketing activities where permitted by law.

We use cookies to keep our website functional, secure, efficient, and more relevant to your browsing experience.

Categories of Cookies We Use

Strictly Necessary Cookies

These cookies are essential for the operation of the website and cannot be disabled in our systems where they are required to provide the service you request. They are typically set in response to actions such as setting privacy preferences, signing in, or submitting forms.

Without these cookies, certain parts of the website may not function correctly.

Functional Cookies

Functional cookies enable enhanced features and personalization, such as remembering your preferences, language settings, or previously selected options. These cookies may be set by us or by third-party providers whose services are integrated into our website.

If you disable these cookies, some services or features may not work as intended.

Performance and Analytics Cookies

These cookies help us understand how visitors use our website by collecting information such as traffic sources, page visits, navigation behavior, and general interaction patterns. In many cases, this information is aggregated and does not directly identify individual users.

We use this information to improve website performance, usability, and content relevance.

Targeting and Advertising Cookies

These cookies may be placed by our advertising or marketing partners to help deliver more relevant ads and measure the effectiveness of campaigns. They may use information about your browsing activity across different websites and services to build a profile of your interests.

These cookies generally do not store directly identifying personal information, but they may identify your browser or device.

First-Party and Third-Party Cookies

Some cookies are set directly by our website and are referred to as first-party cookies. Other cookies are set by third-party services, such as analytics providers, embedded content providers, or advertising partners, and are referred to as third-party cookies.

Third-party providers may use their own cookies in accordance with their own privacy and cookie policies.

Information Collected Through Cookies

Depending on the type of cookie used, the information collected may include browser type, device type, IP address, referring website, pages viewed, time spent on pages, clickstream behavior, and general usage patterns.

This information helps us maintain the website, improve performance, enhance security, and provide a better user experience.

Your Cookie Choices

You can control or disable cookies through your browser settings and, where available, through our cookie consent or preference management tools. Depending on your location, you may also have the right to accept or reject certain categories of cookies, especially those used for analytics, personalization, or advertising purposes.

Please note that blocking or deleting certain cookies may affect the availability, functionality, or performance of some parts of the website.

Restricting cookies may limit certain features and reduce the quality of your experience on the website.

Cookies in Mobile Applications

Where our mobile applications use cookie-like technologies, they are generally limited to those required for core functionality, security, and service delivery. Disabling these essential technologies may affect the normal operation of the application.

We do not use essential mobile application cookies to store unnecessary personal information.

How to Manage Cookies

Most web browsers allow you to manage cookies through browser settings. You can usually choose to block, delete, or receive alerts before cookies are stored. Because browser controls vary, please refer to your browser provider’s support documentation for details on how to manage cookie settings.

Contact Us

If you have any questions about this Cookie Policy or our use of cookies and similar technologies, please contact us at support@becke.cc .