Portabilidad numérica: lo que los ISP y operadores necesitan saber

La portabilidad numérica es el mecanismo regulatorio que permite a un suscriptor conservar su número telefónico existente al cambiar de proveedor, tipo de transporte o categoría de servicio. Para los ISP y operadores, también es uno de los flujos de trabajo más dolorosos administrativamente en las operaciones de voz, y uno de los puntos donde resulta más fácil perder clientes cuando algo sale mal. La mayoría de los operadores no aprecia esto hasta su primer rechazo de portación.

Este artículo es la referencia operativa para ISP, ILEC, CLEC, MSP y operadores mayoristas que manejan actividad de portación de entrada y de salida como parte recurrente de las operaciones de voz, no como un evento de migración único. Cubrimos qué es realmente la portabilidad numérica local (LNP), cómo funcionan los regímenes dominantes en Norteamérica, el Reino Unido, la Unión Europea y varios mercados de Asia-Pacífico, qué debe hacer el controlador de borde de sesión (SBC) en la capa de enrutamiento una vez que un número ha sido portado, el flujo operativo para portación de entrada y de salida, y los modos de falla que causan la mayoría de las disputas de portación.

Si usted está ejecutando una migración única desde la PSTN hacia una plataforma VoIP, la guía de migración de reemplazo de PSTN para ISP es el punto de partida adecuado. Este artículo está dirigido al equipo que debe manejar portaciones de forma continua, una vez que la migración ha finalizado. Para un contexto más amplio sobre la arquitectura SIP en la que esto se enmarca, consulte el pilar de SIP trunking e interoperabilidad.

Qué es realmente la portabilidad numérica

La portabilidad numérica es una promesa regulatoria: cuando un suscriptor cambia de proveedor de voz, el número lo acompaña. La promesa tiene origen pro-competencia y ahora es un elemento fijo de la política de telecomunicaciones en todos los mercados relevantes. En Estados Unidos, el requisito proviene de la Sección 251 de la Telecommunications Act de 1996 (consulte la descripción general de Wireless Local Number Portability de la FCC). En el Reino Unido, proviene de las General Conditions of Entitlement de Ofcom. En la Unión Europea, está codificado en el Artículo 106 del European Electronic Communications Code. Australia, Brasil, India y la mayoría de los mercados de Asia-Pacífico tienen reglas paralelas administradas por sus respectivos reguladores.

En la práctica existen tres variantes de portabilidad. La portabilidad de proveedor es el caso común: el número permanece igual, el proveedor cambia. La portabilidad geográfica permite que el número se traslade con el suscriptor a una nueva ubicación física, lo cual NANP soporta solo dentro del mismo centro tarifario, pero varios mercados de la UE permiten de forma más amplia. La portabilidad de servicio permite que un número se mueva entre tipos de servicio, como de fijo a móvil, y sigue siendo poco frecuente fuera de un número reducido de jurisdicciones. Para ISP y operadores, la portabilidad de proveedor es el flujo de trabajo que consume tiempo operativo.

Lo que es portable es el número en sí, no el plan de servicio, el buzón de voz, las funciones de llamada ni las credenciales SIP. Un suscriptor que porta un número de un operador cedente a un operador receptor está comprando un servicio nuevo que comparte un identificador con el anterior. Esta distinción es la fuente de una cantidad sorprendente de confusión por parte del suscriptor y de un número sorprendente de tickets de soporte posteriores a la portación, razón por la cual la portación numérica se trata como una disciplina operativa en lugar de una tarea técnica.

Cómo funciona LNP en el North American Numbering Plan

NANP cubre Estados Unidos, Canadá y la mayoría de los territorios del Caribe. La base de datos central que hace posible LNP en toda esta cobertura es NPAC, operada por iconectiv mediante un contrato plurianual otorgado por NAPM (el comité de NANC que selecciona al LNPA). Cada número elegible para portación en NANP tiene un registro NPAC que mapea el número telefónico a un LRN que identifica el conmutador que actualmente atiende ese número. El LRN es hacia donde la red enruta después de que una portación se ha ejecutado.

Los actores

El operador cedente actualmente atiende el número y está obligado por las normas de la FCC y la CRTC a cooperar con la portación. El operador receptor asume el número y es responsable de iniciar el LSR, recopilar el LOA, validar el CSR, coordinar el corte y notificar al suscriptor. NPAC mantiene el mapeo autoritativo LRN-a-número telefónico. iconectiv administra NPAC, el LERG, el registro de Service Provider Identifier (SPID) y el programa de token Service Provider Code (SPC) que vincula los registros de autorización de números con la atestación STIR/SHAKEN.

El flujo

Una portación de entrada comienza cuando el suscriptor firma un LOA ante el operador receptor. El operador receptor valida el LSR contra el CSR obtenido del operador cedente y luego envía el LSR a través de un centro de compensación (NeuStar, iconectiv, TNS o Bandwidth, según la configuración del operador). El operador cedente revisa el LSR, confirma la titularidad de la cuenta y devuelve un FOC con la hora de corte acordada, típicamente expresada como una fecha y una ventana de cuatro horas. En el momento del corte, el registro NPAC para el número telefónico portado se actualiza para apuntar al LRN del operador receptor. A partir de ese momento, cada operador NANP que realice una consulta LNP sobre este número enruta la llamada hacia el operador receptor.

Portaciones mayoristas vs. de suscriptor

Para ISP y operadores, tanto la portación mayorista como la de suscriptor son relevantes. Una portación de suscriptor involucra a un único cliente final que se traslada de un proveedor a otro y sigue el proceso estándar de LSR. Una portación mayorista cubre un bloque de números que se mueve entre dos operadores ascendentes, frecuentemente como parte de una adquisición o un cambio de proveedor mayorista, y se administra en lotes a través de los mismos mecanismos de NPAC. Un ISP pequeño que termina servicio a través de un socio mayorista puede experimentar ambas situaciones simultáneamente: su proveedor ascendente cambia de operador (una portación mayorista que el ISP no solicitó) y un suscriptor decide irse al mismo tiempo (una portación de salida que el ISP sí solicitó). Coordinar ambas es operativamente complejo y es uno de los modos de falla cubiertos más adelante en este artículo.

Cómo funciona LNP fuera de Norteamérica

Todo mercado de voz regulado tiene alguna forma de portabilidad numérica, pero el modelo administrativo y el ritmo operativo difieren. Tres patrones dominan.

Reino Unido (Ofcom)

El Reino Unido operó históricamente un modelo liderado por el donante, donde el operador cedente (donante) controlaba la portación y las llamadas siempre se enrutaban primero al donante antes de ser reenviadas. Ofcom está implementando un modelo liderado por el receptor que replica la arquitectura NANP, con una base de datos central autoritativa y enrutamiento directo al operador receptor. El tiempo de respuesta de portación bajo el modelo liderado por el receptor es de un día hábil para suscriptores residenciales, con ejecución en el mismo día posible para clientes empresariales en algunos escenarios. El Reino Unido utiliza mensajes de portación basados en XML intercambiados a través de Openreach y los sistemas de los principales operadores.

Unión Europea (EECC)

Bajo el Artículo 106 del EECC, todos los estados miembros están obligados a implementar la portabilidad entre proveedores en un día hábil, sin costo para el suscriptor. Cada estado miembro administra su propia base de datos central (la OPTA en los Países Bajos, el registro BIPT en Bélgica, el sistema BNetzA en Alemania, entre otros), pero los conceptos operativos están alineados: el operador receptor inicia, el operador cedente valida, un registro central registra el cambio y el enrutamiento se actualiza. Muchos mercados de la UE utilizan ENUM (mapeo de E.164 a URI) como mecanismo de consulta de enrutamiento para números portados, lo que significa que la función del SBC en la capa de enrutamiento es ligeramente diferente de una consulta LRN en NANP.

Australia, Brasil, India y otros mercados de Asia-Pacífico

Australia (ACMA, liderado por el receptor, respuesta rápida), Brasil (ANATEL, base de datos central de portabilidad numérica) e India (TRAI, operadores regionales de portabilidad numérica móvil) mantienen cada uno sus propios registros centrales y flujos de portación. El patrón común en todos ellos es una base de datos central más un intercambio definido entre operador cedente y operador receptor. Donde cambia el comportamiento del SBC respecto a NANP es en el tipo de consulta realizada: una consulta LRN contra NPAC en NANP, una consulta ENUM en gran parte de la UE, una consulta a la base de datos central de portabilidad numérica en Brasil, y así sucesivamente. Cada tipo de consulta es técnicamente una llamada API diferente contra una fuente de verdad diferente, pero la pregunta de enrutamiento subyacente es la misma: ¿quién atiende este número en este momento?

Consideraciones transfronterizas

La portabilidad numérica es nacional por diseño. Un número de EE. UU. no puede portarse a un operador del Reino Unido, y viceversa. Los operadores que operan en múltiples países ejecutan flujos de trabajo de LNP separados por jurisdicción. El tráfico de voz internacional desde un número portado se enruta utilizando las mismas rutas de salida que cualquier otra llamada; el cambio de portabilidad es local al mercado de origen.

La mecánica de enrutamiento: dónde interviene el SBC

Antes de que existiera la portabilidad numérica, cada número telefónico tenía un hogar fijo: el NPA-NXX de los dígitos marcados le indicaba a la red exactamente qué conmutador lo atendía. El enrutamiento era estático y residía en el LERG. La portabilidad rompió esa suposición. Después de una portación, el NPA-NXX del número llamado sigue indicando el centro tarifario original, pero el conmutador real de servicio está en otro lugar completamente diferente. La red tiene que descubrir la nueva ubicación en cada llamada, que es donde interviene el SBC.

La consulta LNP

Una consulta LNP es una búsqueda contra la base de datos de portabilidad para obtener el identificador de enrutamiento actual de un número. En NANP, la consulta devuelve el LRN. En los mercados de la UE que usan ENUM, la consulta devuelve un URI al cual debe enrutarse la llamada. En cada caso, el SBC toma el número llamado del INVITE entrante, consulta la base de datos correspondiente (o una copia en caché) y reescribe la decisión de enrutamiento con base en el resultado.

La consulta puede realizarse contra la base de datos nacional en vivo, contra un espejo local actualizado periódicamente, o contra un proveedor externo que revende acceso a consultas (TransNexus, Neustar, iconectiv, Bandwidth, TNS). Para ISP y operadores más pequeños, el modelo común es la consulta como servicio de un tercero. El costo por consulta varía según proveedor y volumen, típicamente una fracción de centavo, pero a escala de operador los costos se acumulan, razón por la cual el almacenamiento en caché de consultas con TTL razonables es operativamente importante.

Manejo del indicador NPDI

El indicador NPDI en la señalización SIP indica que un nodo ascendente ya realizó una consulta LNP para esta llamada. Cuando el SBC detecta NPDI=yes en un INVITE entrante, el comportamiento correcto es respetar el resultado ascendente y omitir la consulta. Volver a consultar un número que ya fue resuelto aguas arriba desperdicia tiempo, cuesta dinero y puede causar inconsistencias de enrutamiento si las bases de datos ascendente y descendente difieren. Un SBC correctamente configurado siempre verifica NPDI antes de iniciar una consulta, y siempre establece NPDI en los INVITE salientes después de realizar su propia consulta para que los nodos descendentes puedan hacer lo mismo.

Dónde encaja en el flujo de enrutamiento

La consulta LNP típicamente se ejecuta en las etapas iniciales del establecimiento de llamada, después de la validación SIP básica y antes de la decisión de enrutamiento. El resultado de la consulta confirma la ruta original basada en NPA-NXX (el número no está portado, o fue portado de vuelta a su conmutador original) o reescribe la ruta hacia el nuevo operador de servicio. ProSBC implementa las consultas LNP a través de sus módulos API: el script de enrutamiento invoca una consulta HTTP o SIP contra el proveedor de LNP, analiza la respuesta y actualiza la decisión de enrutamiento antes de que la llamada avance. Para un recorrido arquitectónico completo de cómo las consultas externas se integran en el procesamiento de llamadas del SBC, consulte la guía de integración de REST API del SBC con el enrutamiento de llamadas.

Por qué el SBC es el lugar adecuado para esto

Dos razones. Primero, el SBC es el punto de ingreso natural: ya termina SIP, ancla medios, aplica reglas de manipulación de encabezados SIP y es el primer salto donde se aplica la lógica de enrutamiento de llamadas. Agregar una consulta LNP en esta capa mantiene las decisiones de enrutamiento en un solo lugar. Segundo, la arquitectura B2BUA le da al SBC control total sobre el INVITE saliente, incluyendo la capacidad de insertar NPDI, reescribir el Request-URI, establecer el LRN como número de enrutamiento y pasar el número llamado original sin modificar para la facturación descendente.

El flujo operativo: portación de entrada y de salida

La capa técnica es la mitad más sencilla. El flujo administrativo es donde la mayoría de las portaciones tienen éxito o fracasan, y también es donde los ISP sin personal dedicado de operaciones de voz sienten la presión. El flujo tiene dos caminos simétricos.

Portación de entrada (usted es el operador receptor)

Reciba el LOA firmado del suscriptor. Valide la solicitud contra el CSR obtenido del operador cedente; la discrepancia en el nombre de facturación o la dirección de servicio es la razón más común de rechazo de un LSR. Envíe el LSR a través de su centro de compensación con la fecha de corte deseada. Realice el seguimiento del FOC devuelto y resuelva cualquier código de rechazo que el operador cedente plantee (error tipográfico en el número de cuenta, discrepancia de dirección, cuenta congelada, saldo pendiente). Una vez que tenga el FOC, provisione el enrutamiento en su SBC, confirme la cobertura del plan de marcación, configure el buzón de voz y cualquier función de servicio que el suscriptor esté esperando, y notifique al suscriptor la hora de corte. En el momento del corte, verifique que las llamadas entrantes lleguen a la nueva plataforma y que el identificador de llamadas saliente se presente correctamente.

Portación de salida (usted es el operador cedente)

Reciba el LSR del operador receptor. Valídelo contra su CSR y responda dentro del SLA regulatorio obligatorio: las normas de la FCC requieren que las portaciones simples se completen en un día hábil; las portaciones empresariales complejas toman más tiempo. Emita el FOC con la hora de corte acordada, o rechace el LSR con un código específico si la documentación no coincide. Coordine internamente para asegurar que facturación cierre la línea en el momento del corte, que se conserven los CDR durante el período regulatorio requerido y que el número se libere limpiamente de las tablas de enrutamiento de su SBC.

Quién ejecuta cada paso

En un operador con personal suficiente, el flujo se divide: operaciones de voz gestiona el intercambio LSR/FOC, facturación gestiona el cierre de cuenta, operaciones del SBC gestiona el cambio de enrutamiento, y éxito del cliente gestiona la comunicación con el suscriptor. En un ISP más pequeño, la misma persona frecuentemente ejecuta tres o cuatro de estos pasos, que es donde se introducen los errores. Dos prácticas distinguen a los operadores que ejecutan un flujo de portación limpio. La primera es tratar la portación como un flujo coordinado con traspasos explícitos y un único responsable por portación: un ticket de seguimiento, una lista de verificación y una firma en cada paso. La segunda es automatizar el cambio de enrutamiento para que, en la hora del corte, la actualización de enrutamiento del SBC ocurra mediante una llamada API en lugar de una configuración manual a las 2 a.m. por parte de quien esté de guardia.

Modos de falla comunes

La mayoría de las fallas de portación son administrativas, no técnicas. El patrón a lo largo de miles de disputas de portación es que aproximadamente cuatro de cada cinco se remontan a discrepancias de datos, plazos incumplidos o propiedad poco clara, mientras que la capa técnica de enrutamiento representa el resto. Los modos de falla a continuación son los que los operadores encuentran con mayor frecuencia.

Discrepancia de CSR que causa rechazo de FOC

El nombre de facturación del suscriptor en el LSR debe coincidir exactamente con el CSR del operador cedente. “John A. Smith” y “John Smith” pueden tratarse como identidades diferentes. Lo mismo aplica para direcciones, números de cuenta y contactos autorizados. Un solo carácter discrepante es suficiente para rechazar el LSR, lo que le cuesta al operador receptor un ciclo de re-recopilación y re-envío de LOA. La solución es proceso: el operador receptor obtiene el CSR antes de enviar el LSR, lo compara línea por línea con el LOA y resuelve cualquier discrepancia con el suscriptor antes de enviar nada al operador cedente.

Ventana de corte perdida

El FOC establece una hora de corte específica. Si el operador receptor no tiene el enrutamiento provisionado en el SBC en ese momento, las llamadas entrantes al número portado fallan hasta que el enrutamiento esté funcionando. Los suscriptores toleran una portación única; no toleran horas de llamadas entrantes perdidas. La solución es provisionar el enrutamiento del SBC con anticipación y vincular la activación a la hora del FOC a través de la API del SBC, de modo que el cambio de enrutamiento sea controlado por evento en lugar de depender de una persona frente a un teclado.

Snapback (reversión de portación)

El operador cedente puede revertir una portación dentro de un plazo definido, típicamente 30 días en NANP, en casos de portación fraudulenta o en respuesta a una disputa del suscriptor. El operador receptor termina con un registro huérfano: el número está de vuelta en el operador cedente, pero las tablas de enrutamiento locales, los archivos de CDR y los registros de facturación aún hacen referencia al operador receptor. El manejo de snapback es un problema de proceso: una reconciliación periódica entre las tablas de enrutamiento del SBC y el mapeo autoritativo de NPAC detecta registros huérfanos antes de que causen fallas de enrutamiento.

Fallas en la consulta LRN

Si el SBC no logra realizar la consulta LNP (tiempo de espera agotado del proveedor, error de red, credenciales API expiradas, falla de caché sin respaldo), el enrutamiento recurre a la lógica basada en NPA-NXX y la llamada se entrega al centro tarifario original. Para números portados, ese es el destino incorrecto. La solución es la redundancia de consultas: configure proveedores LNP primario y secundario en el SBC, establezca un tiempo de espera corto (típicamente de 500 a 2 500 ms), registre cada falla de consulta en los CDR para monitoreo y defina una política de respaldo clara cuando ambos proveedores fallen. Permitir que las llamadas recurran al enrutamiento NPA-NXX es aceptable en algunas configuraciones de operador e inaceptable en otras; la política debe establecerse explícitamente.

Disputas inter-LATA e intra-LATA

Algunos ILEC más pequeños ocasionalmente se resisten a las portaciones intra-LATA, citando motivos tarifarios o regulatorios que generalmente son procedimentales en lugar de sustantivos. La vía de resolución es la escalación administrativa a través del centro de compensación y, en algunos casos, la FCC. La medida preventiva más efectiva es mantener la documentación del LSR precisa y completa, lo que elimina los motivos procedimentales para la resistencia.

Pérdida de buzón de voz y funciones

Los mensajes de buzón de voz, las funciones de llamada y las personalizaciones por número son específicas de la plataforma. No se portan. Los suscriptores razonablemente esperan que todo lo que tenían antes de la portación estará ahí después, y llaman a soporte cuando no es así. Establecer expectativas durante el paso de recopilación del LOA es la única solución duradera, junto con una lista de verificación de funciones en el momento del corte para asegurar que la nueva plataforma esté provisionada con las mismas funciones de llamada que el suscriptor tenía en la anterior.

Portación de DID versus portación de troncal

Cuando un suscriptor tiene una troncal con muchos DID, cada DID se porta individualmente a través de su propio LSR. Intentar portar una troncal de mil DID como un solo registro puede generar completaciones parciales, donde algunos DID llegan al operador receptor y otros permanecen con el operador cedente, rompiendo el enrutamiento entrante para la mitad de la troncal. Las portaciones mayoristas utilizan mecanismos de portación en bloque específicamente para evitar esto; las portaciones de suscriptor de inventarios grandes de DID requieren lotes coordinados.

STIR/SHAKEN y el rastro documental de portación

En NANP, la documentación de portación ya no es un artefacto puramente operativo. Bajo el marco de la FCC para autenticación de llamante, la atestación de nivel A requiere que el proveedor de servicio de origen tenga una relación directa y verificada con la parte que llama y registros precisos de la asignación número-a-cliente. El LOA, el CSR y el FOC son la evidencia de que el proveedor puede legítimamente atestar en el nivel A para llamadas originadas desde el número portado. Los proveedores que no pueden presentar documentación de portación limpia están siendo degradados cada vez más a atestación de nivel B o C por sus socios de firma ascendentes, con un impacto medible en las tasas de completación de llamadas.

La consecuencia práctica: el flujo de portación ahora alimenta directamente el flujo de cumplimiento. Conserve los LOA en archivo a largo plazo, vincúlelos al registro de portación en NPAC y almacénelos de manera que el equipo de cumplimiento pueda recuperarlos bajo demanda. Para un recorrido más detallado sobre los requisitos de atestación y el camino operativo de la firma de nivel C a nivel A, consulte la guía de atestación de nivel A de STIR/SHAKEN.

Qué buscar en un SBC para operaciones de LNP

Un SBC que opera en un entorno con actividad de portación activa tiene requisitos específicos. La mayoría se desprende de los puntos arquitectónicos ya cubiertos.

Motor de enrutamiento programable. Cada régimen de LNP es diferente. NANP usa NPAC y consultas LRN; la UE usa ENUM en muchos mercados; Brasil e India usan bases de datos centrales de portabilidad numérica con su propia semántica de consulta. Un SBC con una capa de enrutamiento programable puede implementar cada tipo de consulta sin esperar un ciclo de lanzamiento del proveedor. El motor de enrutamiento Ruby de ProSBC expone más de 100 parámetros de llamada y soporta consultas HTTP, Radius y SIP contra cualquier sistema externo, lo que hace sencillo agregar un nuevo proveedor de LNP o un nuevo formato de consulta.

Reconocimiento de NPDI tanto en ingreso como en egreso. El SBC debe detectar NPDI en las llamadas entrantes y respetar el resultado de la consulta ascendente, y debe establecer NPDI en las llamadas salientes después de realizar su propia consulta. Omitir esto convierte una consulta de un solo salto en una cascada de consultas de múltiples saltos.

Control de comportamiento LNP por NAP. Diferentes grupos de troncales tienen diferentes necesidades. Un NAP orientado a operador mayorista puede siempre confiar en el NPDI ascendente; un NAP orientado a suscriptor puede siempre consultar localmente; una troncal de Teams Direct Routing puede necesitar una política diferente. El SBC debe permitir al operador configurar el comportamiento LNP por NAP sin cambiar la política global.

Redundancia de consultas y registro de fallas. Proveedores primario y secundario, tiempos de espera cortos, registro de resultados de consulta en CDR y comportamiento de respaldo explícito. Las consultas LNP no son opcionales, por lo que el modo de falla debe definirse con anticipación y ser observable después del hecho.

Cambios de enrutamiento controlados por API. La hora del corte no debe depender de una persona. El SBC debe aceptar actualizaciones de enrutamiento a través de su REST API para que el flujo de portación pueda activar el cambio de enrutamiento exactamente cuando el FOC lo indica.

Detalle de CDR para auditorías de portación. Cada resultado de consulta, cada LRN, cada indicador NPDI, cada reescritura de Request-URI debe ser visible en el CDR para que el equipo de operaciones pueda reconstruir el enrutamiento de cualquier llamada disputada.

Preguntas frecuentes