Resumen
- RFC 3132 definió paging como la señalización adicional para localizar y alertar a un móvil dormido cuando llegaba un paquete; el envío por el último salto quedaba fuera de esa definición.
- La batería y la señalización se reducían porque la red asumía memoria y búsqueda: conservaba una ubicación aproximada, paginaba un área y resolvía la discordancia entre fronteras radio y subredes IP.
Un destino válido podía no estar escuchando
La dirección IP seguía existiendo. El móvil no había anunciado necesariamente una desconexión. Sin embargo, había reducido la vigilancia de los canales radio para ahorrar batería y, con ello, su capacidad de recibir tráfico normal. Esa diferencia convirtió una operación de reenvío en una secuencia de control.
RFC 3132 apareció en junio de 2001 como memo Informational. Su problema no era cómo transportar un paquete una vez abierta la última conexión, sino cómo encontrar y alertar al host antes de que esa conexión existiera. Al paquete entrante le correspondía un papel doble: contenido para el usuario y detonante para que la red comenzara a localizarlo.
El texto reservó la palabra paging para esa búsqueda y alerta. Enviar el paquete por el último salto no era paging. Por tanto, había recibos diferentes: llegada al agente, página emitida, respuesta del móvil, restablecimiento del canal, actualización de movilidad y entrega final. Ninguno autorizaba a fingir que los demás ya habían ocurrido.
Ahorrar actualizaciones ensanchaba la zona de incertidumbre
Un host podía entrar en dormant mode y escuchar solo en intervalos coordinados. También podía atender un canal específico de paging sin mantener activo el canal de tráfico. Ambas opciones reducían consumo. Asimismo, el móvil podía comunicar su posición solo al cruzar el límite de una paging area, en lugar de hacerlo al cambiar de cada punto de acceso.
La paging area era un conjunto de accesos por los que buscar. No tenía por qué coincidir con una subred IP. Cuanto menos informaba el móvil, más aproximada era la memoria de la red. El ahorro del terminal se financiaba con estado en los agentes, fan-out de búsqueda, temporizadores y riesgo de que la posición envejeciera.
En enlaces sin paging radio, la RFC encontró otra situación. El móvil despertaba periódicamente en el canal de tráfico y el punto de acceso retenía los paquetes. Si se había movido, se reasociaba al despertar y el nuevo acceso podía recuperar el búfer del anterior. Dentro de ese modelo, la red ya conocía con precisión suficiente dónde entregar; un protocolo adicional de paging IP no aportaba ventaja.
La conclusión dependía de límites operativos. El tamaño y la duración del búfer eran decisiones de implementación. El RFC no garantizaba ausencia de pérdida ni describía toda tecnología posterior.
Con paging, el paquete buscaba antes de viajar
Los enlaces con paging separaban el canal de alerta del canal de tráfico. El móvil dormido podía escuchar el primero, quizá por ranuras, mientras dejaba inactivo el segundo. Cuando aparecía tráfico, la red enviaba una señal a la última zona reportada o elegida por una heurística. Si recibía respuesta, reanudaba la conexión; si vencía el temporizador, trataba al móvil como inalcanzable.
El diseño tenía una razón económica en espectro licenciado. Sacar señalización del canal de tráfico liberaba capacidad para usos productivos y evitaba cargar al cliente por overhead. RFC 3132 describía ese incentivo; no cuantificaba el ahorro.
La distinción también protegía el análisis: que el paging agotara su tiempo no demostraba por qué faltaba respuesta. El móvil podía estar fuera de cobertura, apagado, en otra zona, incapaz de autenticar el mensaje o simplemente haber sufrido pérdida radio. Un timeout era resultado del intento, no diagnóstico universal.
El caso difícil era una zona radio con varias subredes
Mobile IP y el paging radio observaban movimientos distintos. Para IP, cruzar una subred cambiaba la ubicación topológica. Para la radio, importaba cruzar una paging area. RFC 3132 comparó tres geometrías.
Si una zona y una subred coincidían, el sistema radio despertaba al host en la localización IP correcta. Si varias zonas cabían dentro de una sola subred, el router de acceso podía paginar varias sin que la dirección cambiara de significado.
Cuando una paging area contenía varias subredes, el supuesto se rompía. El terminal dormido podía cambiar de subred sin abandonar la zona radio. La capa 2 no generaba registro porque, desde su punto de vista, no había cambio de área. La capa IP mantenía una ubicación antigua. El primer paquete viajaba a esa subred y podía provocar una página respondida desde otra.
Era posible reparar la situación con más señalización Mobile IP, pero a costa de tiempo antes de entregar el primer paquete. Un intercambio específico hacia un agente de la zona podía optimizar la búsqueda. El documento no lo presentaba como una ley única; al contrario, afirmó que el verdadero problema era localizar al móvil que se había movido dormido y que IP paging era una solución entre varias posibles.
La topología real rechazaba los dibujos limpios
La RFC empezó con relaciones de subconjunto para poder razonar. Luego reconoció que las zonas podían solaparse y que terminales situados en el mismo lugar podían recibir identificadores distintos. También recogió evidencia anecdótica de operadores que no activaban registros de área y dependían de heurísticas.
Las redes con varias tecnologías agravaban la ambigüedad. El host podía haber entrado en un edificio, perdido cobertura en una interfaz y preferir otra más barata o rápida. Encontrar su geografía no resolvía la elección de acceso. El texto bosquejó un identificador de paging en IP que los puntos de acceso traducirían a señales específicas de cada radio.
ARP y Neighbor Discovery tampoco bastaban mientras el terminal no escuchara el canal de tráfico que esos procedimientos suponían disponible. El problema no era falta de dirección, sino falta temporal del medio para preguntar por ella.
La arquitectura posterior repartió la responsabilidad
RFC 3154 convirtió la intuición en requisitos. El protocolo debía escalar a millones de hosts, consumir poca energía y filtrar broadcasts, multicasts y anycasts para que un paquete colectivo no despertara una multitud. Debía distinguir dormido de inactivo, admitir varias formas de dormancia, ser independiente del protocolo de movilidad y aun así definir integración con Mobile IPv4 y Mobile IPv6.
La cartografía entre áreas y subredes debía ser arbitraria. Había que aprovechar paging de capa 2 sin volverlo obligatorio, tolerar pérdida de mensajes y fallos de agentes, y autenticar registros, información de área y páginas. El coste de seguridad no podía destruir la economía de energía.
El modelo separó Host, Tracking Agent, Paging Agent y Dormant Monitoring Agent. Uno sabía aproximadamente dónde buscar; otro detectaba el paquete; otro alertaba; el host restauraba el enlace enrutable. “Despertar” era una transacción distribuida, no una llamada indivisible.
Una evaluación de cinco propuestas siguió siendo un borrador
En 2002, un Internet-Draft evaluó cinco propuestas contra esos requisitos. Sus versiones -00 y -01 documentan análisis en curso y vacíos concretos: dependencia de una modalidad de Mobile IP, soporte incompleto de múltiples estados, fallos poco definidos, administración o escalabilidad sin resolver.
No fue un RFC. Tampoco RFC 3132 ni RFC 3154 afirmaron implementación o despliegue; ambas eran Informational. RFC 3344, RFC 6275 y RFC 3753 ayudan a ubicar la evolución de Mobile IPv4, Mobile IPv6 y su vocabulario, pero no prueban que esta arquitectura de paging fuera adoptada.
El ahorro no eliminó trabajo; lo cambió de sitio
La historia importante no es que los móviles dormían. Es que esa decisión volvió incompleta la palabra alcanzable. Una dirección correcta podía apuntar a un host que no oía. Una zona correcta podía ser demasiado grande para identificar la subred. Una página correcta podía no obtener respuesta. Una respuesta podía llegar antes que la ruta.
El host controlaba la dormancia. Los agentes controlaban memoria, detección y búsqueda. El operador elegía fronteras, filtros y expiraciones. Mobile IP reparaba el anclaje. La aplicación esperaba al final. La autoridad estaba distribuida porque el fenómeno también lo estaba.
RFC 3132 dejó una regla más amplia: cuando un sistema ahorra recursos dejando de observar continuamente, alguien debe asumir memoria, activación y prueba. El primer paquete no confirmó una entrega. Reveló la deuda que la red había aceptado a cambio del silencio del terminal.
Fuentes
- https://www.rfc-editor.org/rfc/rfc3132.txt
- https://www.rfc-editor.org/info/rfc3132
- https://www.rfc-editor.org/rfc/rfc3132.html
- https://www.rfc-editor.org/rfc/rfc3154.txt
- https://www.rfc-editor.org/info/rfc3154
- https://www.rfc-editor.org/rfc/rfc3154.html
- https://www.rfc-editor.org/rfc/rfc2002.txt
- https://www.rfc-editor.org/rfc/rfc3344.txt
- https://www.rfc-editor.org/rfc/rfc6275.txt
- https://www.rfc-editor.org/rfc/rfc3753.txt
- https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-00.txt
- https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-01.txt
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
