60 min con el lab link-selector + 10 de entregable. No se simula: 4G no se puede fingir honestamente. Se diseña y se calcula.

Paso 0 · Requisitos del enlace (10 min)

Antes de comparar tecnologías, escribir qué se necesita:

Requisito Valor De dónde sale
Latencia máxima aceptable … ms ¿qué decisión toma pits con ese dato?
Throughput necesario … B/s spec de paquete (S2)
Cobertura requerida … mapa del venue
Presupuesto mensual de datos … MB plan contratado

La primera columna manda. Si nadie toma una decisión con un dato en menos de 2 s, no necesita enlace de baja latencia.

Paso 1 · Comparación en el lab (20 min)

En link-selector, evaluar tres arquitecturas contra los requisitos de arriba:

Arquitectura Latencia Cobertura Costo/carrera Consumo Punto único de falla
Solo LoRa … … 0 … …
Solo 4G … … … … …
Híbrido con failover … … … … …

La última columna es la que decide en la práctica.

Paso 2 · Máquina de estados del failover (15 min)

Dibujarla explícitamente — estados, transiciones y el número que dispara cada una:

[LoRa OK] --N paquetes perdidos seguidos--> [Degradado]
[Degradado] --T segundos sin recuperar--> [4G activo]
[4G activo] --M segundos de LoRa estable--> [LoRa OK]
              (banda muerta: M > T, para no oscilar)

Definir N, T y M con justificación, y responder por escrito: durante la transición, ¿se pierden datos, se encolan o se recuperan después de la SD? ¿Cómo sabe el receptor que hubo cambio de enlace?

Paso 3 · Presupuesto de datos (15 min)

Con la spec de paquete de la S2:

  1. Bytes por mensaje MQTT = payload + overhead del tópico + TCP/IP
  2. MB por hora, por día de carrera y por temporada
  3. Recalcular agrupando 5 muestras por mensaje. Anotar cuánto se ahorra y cuánta latencia se agrega
  4. Comparar contra el plan contratado y decir qué pasa si se excede a media carrera