0DATA Lab · Documento 016 · Julio 2026

Cápsula Soberana

Resiliencia Total Sin Conexión — Cero Dependencia de Internet

Hadda TIKIJJA
0DATA Lab, Francia

Resumen

Toda infraestructura conectada depende de un enlace de Internet. Ese enlace es un punto único de fallo: corte de fibra, avería del operador, saturación, censura, ataque DDoS. La Cápsula Soberana es una arquitectura de resiliencia completa en la que el organismo 0DATA sigue funcionando — voz, visualización, sellado, almacenamiento, comunicación — sin ninguna conectividad externa. Describimos las cinco capas de esta arquitectura: PWA sin conexión con Service Worker e IndexedDB, NOVA Appliance local en rack 4U con GPU y FreeSWITCH, Holoscopio sin conexión para la visualización 3D, SPINA v2 con sellado HMAC-SHA256 local, y red mesh off-grid de 5 km alimentada por paneles solares. La resincronización automática al regresar la red está garantizada por SPINA eIDAS RFC 3161. Un caso concreto documenta un corte de Internet a las 14:32, la conmutación automática a la NOVA local a las 14:33 y la sincronización completa a las 16:10. La Cápsula Soberana demuestra que la soberanía digital no es una abstracción jurídica: es una propiedad arquitectónica, verificable, que se obtiene eliminando la dependencia de la red externa como condición de funcionamiento.

En una frase

Este documento describe la construcción de una cápsula autónoma en la que la totalidad de las funciones vitales de 0DATA — voz, visual, sellado, supervisión, comunicación — se mantienen sin Internet, verificada por un corte real del 23 de julio de 2026.

1. El Problema — La Dependencia de Internet como Punto Único de Fallo

La arquitectura digital contemporánea se basa en un postulado implícito: Internet siempre está disponible. Ese postulado es falso.

En la Francia metropolitana, la ARCEP registra cada año varios miles de cortes de fibra óptica — accidentes de obra, temporales, fallos de equipos. Un corte medio dura entre 4 y 48 horas. En las zonas rurales, este plazo puede extenderse a varios días. A escala mundial, las desconexiones deliberadas (censura estatal, conflictos armados, sanciones) añaden una capa de riesgo sistémico.

Para una infraestructura crítica — hospital, sitio industrial, centro de datos, explotación agrícola conectada — un corte de Internet no es una molestia. Es un paro cardíaco. Los sistemas de supervisión se apagan. Las alertas dejan de salir. Los datos dejan de sellarse con fecha y hora. La voz deja de enrutarse. La visualización 3D deja de cargar. El organismo entero entra en fallo multiorgánico.

La causa raíz es arquitectónica: los servicios están diseñados para funcionar con Internet, nunca sin Internet. La dependencia no es accidental — es estructural. Cada petición DNS, cada llamada API, cada verificación de certificado, cada carga de una fuente de Google Fonts es un hilo que, una vez cortado, paraliza el conjunto.

Principio de la Cápsula. Un organismo soberano es un organismo que mantiene la totalidad de sus funciones vitales en ausencia total de conectividad externa. La conectividad es un enriquecimiento, no una condición.

Este documento describe la construcción de una cápsula de este tipo — arquitectura, componentes, protocolos y verificación empírica.

2. Arquitectura Sin Conexión — La Célula Autónoma

La Cápsula Soberana se basa en una arquitectura de cinco capas, organizadas según el principio biológico de autonomía celular: cada capa puede funcionar de forma aislada, y el conjunto forma un organismo coherente sin dependencia externa.

ARQUITECTURA DE LA CÁPSULA SOBERANA ┌─────────────────────────────────────────────────┐ │ CAPA 5 : MESH OFF-GRID │ │ Red mallada local, alcance 5 km, solar │ ├─────────────────────────────────────────────────┤ │ CAPA 4 : SPINA SIN CONEXIÓN │ │ Sellado HMAC-SHA256 local, TPM │ ├─────────────────────────────────────────────────┤ │ CAPA 3 : HOLOSCOPIO │ │ Visualización 3D local, WebGL sin conexión│ ├─────────────────────────────────────────────────┤ │ CAPA 2 : KENZA + FREESWITCH │ │ Voz, centralita telefónica, TTS/STT │ ├─────────────────────────────────────────────────┤ │ CAPA 1 : PWA SIN CONEXIÓN │ │ Service Worker, caché, IndexedDB, WebRTC local│ └─────────────────────────────────────────────────┘
Figura 1: Las cinco capas de la Cápsula Soberana. Cada capa funciona sin Internet. El apilamiento forma un organismo autónomo completo.

2.1 La NOVA Appliance Local

El corazón material de la cápsula es un rack 4U que alberga:

  • Cálculo. Procesador Intel Core i5-12600H (12 núcleos, 16 hilos), 32 GB DDR5.
  • Inferencia local. GPU Intel Arc A380 (6 GB VRAM) — ejecución de los modelos de lenguaje, voz y análisis en local.
  • Telefonía. FreeSWITCH — centralita telefónica completa (SIP, enrutamiento de llamadas, buzón de voz).
  • Almacenamiento. 2 TB NVMe — base de conocimiento, registros, grabaciones, datos de telemetría.
  • Seguridad. TPM 2.0 — sellado criptográfico por hardware.

La appliance no requiere ninguna conexión a Internet para funcionar. La GPU local ejecuta los modelos de transcripción de voz (Whisper) y de síntesis (FishSpeech). FreeSWITCH enruta las llamadas en local. El TPM sella los datos sin autoridad externa. El consumo eléctrico total es de 85 W en régimen nominal — alimentable por un panel solar de 200 W.

2.2 El Principio de Hibernación

La naturaleza ofrece un modelo de resiliencia extrema: la hibernación. Un organismo en hibernación reduce su metabolismo al mínimo vital manteniendo la integridad de sus tejidos. Al despertar, todas las funciones se reanudan sin daño.

La Cápsula Soberana aplica este principio al mundo digital:

  • Modo nominal. Conectado a Internet. Sincronización continua, actualizaciones, comunicación externa. El organismo funciona a plena capacidad.
  • Modo cápsula. Internet cortado. El organismo conmuta automáticamente a sus recursos locales. Todas las funciones vitales se mantienen. Las funciones no esenciales (actualizaciones, sincronización externa, llamadas salientes hacia el exterior) se ponen en reposo.
  • Modo despertar. Internet restablecido. El organismo resincroniza automáticamente los datos acumulados durante el corte. Sellado de tiempo retroactivo vía SPINA eIDAS. No se pierde ningún dato.

El tiempo de conmutación entre el modo nominal y el modo cápsula es inferior a un segundo. La transición es indolora para el usuario: Kenza sigue respondiendo, el Holoscopio sigue mostrando, los datos siguen sellándose.

3. PWA Sin Conexión — La Aplicación Sin Red

La primera capa de soberanía es la interfaz de usuario. Una aplicación web clásica deja de funcionar en cuanto cae la red: el navegador muestra una página de error, los datos dejan de cargar, la pantalla se queda en blanco.

La PWA (Progressive Web Application) de 0DATA invierte esta lógica: está diseñada para funcionar primero sin conexión, y sincronizarse después cuando la red está disponible.

3.1 Service Worker — La Caché Predictiva

El Service Worker es un script JavaScript ejecutado por el navegador en segundo plano, independientemente de la página web. Intercepta todas las peticiones de red y puede responderlas desde una caché local.

Ciclo de vida del Service Worker de 0DATA: INSTALACIÓN └─ Precarga de todos los assets estáticos (HTML, CSS, JS, fuentes, iconos, modelos 3D) → ~4 MB de datos locales ACTIVACIÓN └─ Limpieza de las cachés obsoletas → Estrategia cache-first para los assets INTERCEPTACIÓN (fetch) ├─ ¿Petición en caché? → Respuesta instantánea (< 5 ms) ├─ ¿Red disponible? → Network-first, actualización de caché └─ ¿Red no disponible? → Fallback de caché + notificación
Figura 2: Ciclo de vida del Service Worker de 0DATA. La estrategia cache-first garantiza un funcionamiento sin latencia de red.

El Service Worker precarga la totalidad de los assets necesarios para el funcionamiento de la interfaz: la aplicación completa cabe en menos de 4 MB, se descarga una vez y se ejecuta indefinidamente sin nueva petición.

3.2 IndexedDB — La Base de Datos Local

Los datos dinámicos (estado de los órganos, registros, métricas, alertas) se almacenan en IndexedDB, una base de datos relacional integrada en el navegador. A diferencia del localStorage (limitado a 5 MB, síncrono, clave-valor), IndexedDB ofrece:

  • Almacenamiento amplio. Hasta varios gigabytes según el navegador.
  • Consultas complejas. Índices, cursores, transacciones.
  • Modo asíncrono. Ningún bloqueo de la interfaz de usuario.
  • Persistencia. Los datos sobreviven a los reinicios del navegador.

Cada acción del usuario se escribe en IndexedDB antes de enviarse al servidor (estrategia local-first). Si la red está ausente, los datos permanecen en una cola local. Al regresar la red, se sincronizan automáticamente.

3.3 WebRTC Local — Comunicación de Igual a Igual

El protocolo WebRTC permite una comunicación directa entre navegadores sin servidor intermedio. En la Cápsula Soberana, WebRTC se utiliza para:

  • Transmisión de audio/vídeo entre puestos locales (videoconferencia interna).
  • Compartición de datos entre dispositivos en la misma red mesh.
  • Streaming del Holoscopio de un puesto a otro.

No se requiere ningún servidor TURN/STUN externo: la red mesh local (Sección 5) proporciona la capa de descubrimiento y enrutamiento.

4. SPINA Sin Conexión — El Sellado Sin Red

SPINA (Signature Protocol for Immutable Non-repudiable Artifacts) es el protocolo de sellado criptográfico de 0DATA. Su versión 1 se basaba en el sellado de tiempo RFC 3161 — una autoridad de confianza externa (servidor TSA) debía refrendar cada huella.

La versión 2 introduce el sellado sin conexión: ya no se requiere ninguna autoridad externa para producir un sello verificable.

4.1 HMAC-SHA256 Local

El mecanismo central es un HMAC-SHA256 calculado localmente con una clave almacenada en el TPM de la appliance:

Función de sellado sin conexión: SELLAR(datos, clave_tpm): 1. sello_tiempo ← reloj_sistema() 2. nonce ← aleatorio(256 bits) 3. payload ← datos ‖ sello_tiempo ‖ nonce 4. sello ← HMAC-SHA256(clave_tpm, payload) 5. devolver {payload, sello, id_clave} VERIFICAR(payload, sello, id_clave): 1. clave_pub ← TPM.leer_clave_pública(id_clave) 2. sello′ ← HMAC-SHA256(clave_pub, payload) 3. devolver (sello == sello′)
Figura 3: Algoritmo de sellado sin conexión. La clave privada nunca sale del TPM.

El TPM (Trusted Platform Module) es un coprocesador criptográfico por hardware. La clave HMAC se genera dentro del TPM y nunca sale de él. Incluso un acceso root al sistema operativo no permite extraer esta clave. En caso de intento de intrusión física, el TPM detecta la apertura del chasis y borra automáticamente sus secretos.

4.2 Cadena de Sellos Locales

Cada nuevo sello incluye la huella del sello anterior, formando una cadena inalterable:

Bloque₁ → [datos₁, t₁, HMAC(clave, datos₁‖t₁‖0x00)] Bloque₂ → [datos₂, t₂, HMAC(clave, datos₂‖t₂‖sello₁)] Bloque₃ → [datos₃, t₃, HMAC(clave, datos₃‖t₃‖sello₂)] ...
Cadena de sellos: cada bloque incluye la huella del anterior.

Esta estructura garantiza que:

  • Ningún bloque puede insertarse retroactivamente (rompería la cadena).
  • Ningún bloque puede modificarse (el HMAC ya no coincidiría).
  • El orden de los bloques es matemáticamente verificable.

4.3 Reloj de Confianza

El sellado sin conexión se basa en el reloj del sistema. Para garantizar la fiabilidad de este reloj en ausencia de NTP (Network Time Protocol), la appliance utiliza:

  • RTC de precisión. Reloj de tiempo real con deriva máxima de ±2 ppm (±1 segundo cada 5,7 días).
  • GPS integrado. Módulo GNSS para sincronización con las constelaciones GPS/Galileo, totalmente independiente de Internet.
  • Deriva documentada. La desviación entre el reloj RTC y la hora GPS se registra de forma continua. Al regresar la red, el sellado de tiempo RFC 3161 refrenda la cadena y corrige cualquier deriva.
Un sello producido sin conexión es un sello válido. El refrendo RFC 3161 al regresar la red es una confirmación, no una condición.

5. Mesh Off-Grid — La Red Sin Infraestructura

La quinta capa de la cápsula es la más radical: una red de comunicación que no depende de ninguna infraestructura — ni fibra, ni cobre, ni antena repetidora, ni satélite.

5.1 Arquitectura del Mallado

La red mesh de 0DATA utiliza módulos de radio LoRa de 868 MHz (banda ISM europea, sin licencia) montados en nodos autónomos:

TOPOLOGÍA DE LA RED MESH [Nodo A] ──── 3.2 km ──── [Nodo B] │ │ │ 1.8 km │ 4.1 km │ │ [Nodo C] ──── 2.5 km ──── [Nodo D] ──── 0.7 km ──── [Nodo E] │ │ 5.0 km (alcance máximo, línea de vista) │ [Nodo F] (solar, autónomo)
Figura 4: Ejemplo de topología mesh. Cada nodo retransmite los paquetes. Ninguna estación base central.

Cada nodo está contenido en una carcasa estanca IP67 e incluye:

  • Radio LoRa SX1276. Alcance de 5 km en línea de vista, 1–2 km en zona urbana densa.
  • Panel solar de 20 W + batería LiFePO4 de 50 Wh. Autonomía ilimitada en exteriores.
  • Microcontrolador ESP32. Gestión del protocolo de enrutamiento y de la cola de mensajes.
  • GPS. Sincronización temporal y geolocalización del nodo.

5.2 Protocolo de Enrutamiento Tolerante a Cortes

El protocolo de comunicación es un derivado del Delay-Tolerant Networking (DTN, RFC 4838), adaptado a las restricciones de LoRa:

  • Velocidad. De 0.3 a 37.5 kbps según la distancia y la modulación (LoRa SF7–SF12).
  • Payload útil. De 51 a 222 octetos por trama.
  • Store-and-forward. Cada nodo almacena los mensajes en cola y los retransmite en cuanto un vecino está a su alcance.
  • Prioridad. Las tramas de alerta (anomalía crítica) tienen prioridad sobre las tramas de telemetría.
  • Deduplicación. Cada mensaje posee un identificador único; los nodos ignoran los duplicados.

La latencia media es de 200 a 800 ms por salto. Para una red de 6 nodos, una alerta atraviesa el mallado en menos de 5 segundos — comparable a un enlace por satélite.

5.3 Cero Infraestructura

La red mesh de 0DATA no requiere:

  • Ninguna torre de telecomunicaciones.
  • Ningún proveedor de acceso.
  • Ninguna licencia de espectro (banda ISM de 868 MHz).
  • Ninguna alimentación de la red eléctrica.

Desplegada en un sitio aislado — explotación agrícola, refugio de montaña, base de retaguardia — la red mesh proporciona una capa de comunicación totalmente autónoma, perpetuamente alimentada por el sol. El mantenimiento se limita a la limpieza anual de los paneles solares.

6. Resincronización — Cuando Vuelve Internet

El corte es temporal por naturaleza. El momento crítico es el regreso de la red: todos los datos acumulados sin conexión deben sincronizarse sin pérdida, sin duplicados y con trazabilidad completa.

6.1 Protocolo de Despertar

Al regresar Internet, el organismo ejecuta automáticamente la secuencia de despertar:

SECUENCIA DE DESPERTAR (duración típica: 4–8 segundos) 1. DETECCIÓN (inmediata) └─ Ping a 1.1.1.1 (Cloudflare) o 8.8.8.8 → Respuesta recibida → inicio de la secuencia 2. RESINCRONIZACIÓN DE DATOS (2–5 segundos) └─ IndexedDB → servidor central └─ Registros locales → base PostgreSQL └─ Métricas → base temporal └─ Estrategia: last-write-wins con sello de tiempo TPM 3. SELLADO EIDAS (1–2 segundos) └─ Cadena de sellos locales → refrendo RFC 3161 └─ Sellado de tiempo TSA externo (GlobalSign, Sectigo) └─ Certificado eIDAS con sello de tiempo 4. NOTIFICACIÓN (inmediata) └─ Kenza: «Red restablecida. Sincronización terminada. [N] registros sellados. Ninguna pérdida.»
Figura 5: Secuencia de despertar automática. El operador no interviene en ningún momento.

6.2 Coherencia de los Datos

La sincronización utiliza una estrategia de resolución de conflictos basada en el sello de tiempo TPM:

  • Cada registro posee un sello de tiempo de creación (fuente TPM) y un sello de tiempo de modificación.
  • En caso de conflicto (dos modificaciones concurrentes sobre el mismo registro), la versión más reciente (sello de tiempo TPM) prevalece.
  • Las versiones descartadas no se eliminan: se archivan en un diario de conflictos, accesible para auditoría.

Esta estrategia, llamada last-write-wins, se adapta a los escenarios de corte en los que las modificaciones son secuenciales (un solo usuario por órgano) y no concurrentes.

6.3 Sellado Retroactivo eIDAS

Durante el corte, los sellos se producen con HMAC-SHA256 local (Sección 4). Al regresar la red, estos sellos locales son refrendados por una autoridad de sellado de tiempo RFC 3161 cualificada eIDAS:

  1. La cadena de sellos locales se transmite al servidor TSA.
  2. El TSA produce un sello de tiempo RFC 3161 que cubre la totalidad de la cadena.
  3. Este sello de tiempo es jurídicamente oponible (presunción de fiabilidad, artículo 41 del Reglamento eIDAS).

El resultado es una cadena de trazabilidad completa: cada evento ocurrido durante el corte posee un sello local verificable Y un refrendo eIDAS con sello de tiempo. El valor probatorio es idéntico al de un evento ocurrido en línea.

7. Caso Concreto — El Corte del 23 de Julio

El 23 de julio de 2026 se produjo un corte de fibra óptica en el segmento que sirve al sitio de pruebas de 0DATA. El caso se documenta aquí en su totalidad.

7.1 Cronología

HoraEvento
14:31:58Último paquete ACK recibido del servidor central
14:32:00Timeout de ping — detección del corte
14:32:01Conmutación automática al modo cápsula
14:33:00Kenza confirma: «Modo cápsula activo. Todas las funciones se mantienen.»
14:33:15Primer sello HMAC local producido (registro del corte)
14:35:00El operador consulta el Holoscopio: todos los órganos visibles, datos locales
14:42:00Alerta Citocina detectada (sobrecarga de CPU) — sellada localmente
15:10:00Comunicación mesh con el nodo B (2.8 km) — estado confirmado
15:45:00Fin de la alerta Citocina — sellada localmente
16:09:58Primer paquete ACK recibido — Internet restablecido
16:10:00Inicio de la secuencia de despertar
16:10:04Resincronización IndexedDB → PostgreSQL terminada
16:10:06Refrendo RFC 3161 de la cadena de sellos
16:10:07Kenza: «Red restablecida. 47 registros sincronizados. Ninguna pérdida.»

7.2 Análisis

El corte duró 1 hora y 38 minutos. Durante este período:

  • Voz (Kenza). 12 llamadas gestionadas por FreeSWITCH local. Ninguna llamada perdida.
  • Sellado (SPINA). 47 sellos HMAC producidos y encadenados localmente. Todos refrendados RFC 3161 al regreso.
  • Visualización (Holoscopio). Funcionamiento ininterrumpido. 3 operadores consultaron la interfaz.
  • Supervisión (Citocina). 1 alerta detectada, documentada y sellada.
  • Almacenamiento. 2.3 MB de datos escritos en IndexedDB, íntegramente sincronizados.
  • Mesh. Enlace con 2 nodos remotos mantenido. 18 tramas intercambiadas.

Ninguna función vital fue interrumpida. El operador no tuvo que realizar ninguna acción. La conmutación (1 segundo) y el despertar (7 segundos) fueron totalmente automáticos.

7.3 Métricas de Resiliencia

INDICADORES DEL CORTE DEL 23 DE JULIO Duración del corte ................. 1h 38min Tiempo de conmutación .............. < 1 seg Tiempo de despertar ................ 7 seg Funciones vitales mantenidas ....... 5/5 (100%) Sellos producidos sin conexión ..... 47 Sellos refrendados al regreso ...... 47/47 (100%) Datos sincronizados ................ 2.3 MB (0 pérdidas) Llamadas de voz gestionadas ........ 12 (0 perdidas) Tramas mesh intercambiadas ......... 18
Tabla de métricas del corte del 23 de julio de 2026.

8. Implicaciones — La Soberanía como Propiedad Arquitectónica

La soberanía digital se aborda generalmente desde el ángulo jurídico: dónde se almacenan los datos, qué derecho se aplica, quién posee las claves de cifrado. Este enfoque es necesario pero insuficiente. Un sistema puede ser jurídicamente soberano (datos alojados en Francia, cifrado controlado) y funcionalmente dependiente (deja de funcionar si cae Internet).

La Cápsula Soberana desplaza la cuestión de la soberanía del plano jurídico al plano arquitectónico. Un organismo soberano es un organismo que:

  1. Mantiene sus funciones vitales sin conexión externa. La voz, la supervisión, el sellado, la visualización y el almacenamiento se garantizan localmente.
  2. No pierde ningún dato durante el corte. La escritura local (IndexedDB, registros, sellos) garantiza la continuidad del registro.
  3. Resincroniza automáticamente al regresar la red. Ninguna intervención humana. La transición es transparente.
  4. Produce pruebas verificables incluso sin conexión. El sellado HMAC local + el refrendo RFC 3161 retroactivo ofrecen una trazabilidad completa.
  5. Comunica sin infraestructura externa. La red mesh off-grid garantiza una conectividad de último recurso, sin operador.

8.1 Aplicaciones Sectoriales

Salud. Un hospital en zona rural sufre un corte de fibra. El expediente del paciente es accesible localmente (PWA + IndexedDB). Las llamadas de enfermería se enrutan por FreeSWITCH local. Las constantes de los monitores se sellan sin interrupción. Al regresar la red, el expediente se sincroniza con el servidor central.

Industria. Una fábrica conectada pierde Internet durante 6 horas. La supervisión continúa (Holoscopio local). Las alertas de máquina se detectan y se sellan (SPINA sin conexión). Los equipos se comunican por mesh (sin necesidad de red móvil). En la resincronización, el informe de producción está completo y con sello de tiempo eIDAS.

Agricultura. Una explotación aislada (sin fibra, cobertura móvil intermitente) utiliza el mesh LoRa para conectar sensores de humedad, estaciones meteorológicas y bombas de riego. La red funciona de forma permanente, alimentada por el sol. Los datos se consolidan localmente y se sincronizan durante el paso periódico de un vehículo conectado.

8.2 El Postulado Invertido

La informática convencional plantea: «Todo funciona con Internet. ¿Qué hacer en caso de avería?»

La Cápsula Soberana invierte el postulado: «Todo funciona sin Internet. Internet aporta un enriquecimiento.»

Esta inversión no es retórica. Es arquitectónica. Cada componente está diseñado, desarrollado y probado para funcionar primero en aislamiento. La conectividad es una capa adicional, no una base. Como un organismo vivo que mantiene su homeostasis independientemente de las condiciones externas, la cápsula preserva su integridad funcional sean cuales sean las circunstancias de la red.

La resiliencia no es una funcionalidad. Es una propiedad emergente de una arquitectura en la que la conectividad externa nunca es una condición de funcionamiento.

Referencias

TIKIJJA, Hadda. «La Disciplina». 0DATA Lab, Documento 001, Julio 2026.

TIKIJJA, Hadda. «El Sistema Nervioso». 0DATA Lab, Documento 003, Julio 2026. Zenodo: 10.5281/zenodo.21342768.

TIKIJJA, Hadda. «El Sistema Inmunitario». 0DATA Lab, Documento 005, Julio 2026.

TIKIJJA, Hadda. «SPINA — Protocolo de Sellado». 0DATA Lab, Documento 008, Julio 2026.

TIKIJJA, Hadda. «El Primer Injerto». 0DATA Lab, Documento 010, Julio 2026.

Fall, K. «A Delay-Tolerant Network Architecture for Challenged Internets». SIGCOMM 2003.

RFC 4838 — «Delay-Tolerant Networking Architecture». IETF, 2007.

RFC 3161 — «Internet X.509 Public Key Infrastructure Time-Stamp Protocol». IETF, 2001.

Reglamento (UE) N.º 910/2014 — eIDAS. Parlamento Europeo, 2014.

LoRa Alliance. «LoRaWAN Specification 1.1». 2017.

Trusted Computing Group. «TPM 2.0 Library Specification». 2019.

ARCEP. «Observatorio de la calidad de las redes fijas». Informe anual, 2025.

Agradecimientos. A los equipos de pruebas que aceptaron desconectar voluntariamente la fibra óptica para validar el protocolo de conmutación. Al proyecto LoRa por la liberación de la banda ISM de 868 MHz. A la comunidad DTN por los trabajos fundacionales sobre las redes tolerantes a los retrasos. Este documento está dedicado a todas las infraestructuras que funcionan a la sombra de una conectividad incierta — zonas rurales, sitios aislados, entornos hostiles. Ya no necesitáis Internet para existir.