---
title: 'Sesiones largas'
description: 'Nodos de la flota cuyas sesiones de comunicación duran un tiempo anormalmente largo respecto a su propia norma, con umbrales IQR por nodo, una puntuación de gravedad y un análisis de causa raíz basado en incidentes.'
section: AI Analytics
weight: 7
related:
- ai-analytics/fleet-reports/events-explorer
---
import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';
El informe **Sesiones largas** analiza las sesiones de comunicación de telemetría en toda la flota de nodos de medición e identifica los dispositivos, ubicaciones, días y tipos de corrector en los que las comunicaciones funcionan de forma inestable o tardan un tiempo excesivo en transmitir los datos.
El encabezado del informe muestra siete KPI: empresa, cobertura de la flota, disponibilidad de datos, número de nodos con anomalías, número de sesiones anómalas, duración máxima de sesión, número total de incidentes horarios y el periodo de análisis. La cifra principal es el recuento de nodos con anomalías respecto al total de la flota; los incidentes son agrupaciones horarias en las que cinco o más nodos presentan sesiones largas de forma simultánea.
El informe responde a preguntas operativas prácticas:
- qué nodos tienen sesiones de comunicación demasiado largas;
- qué sesiones se consideran anómalas para este nodo concreto;
- dónde el problema es local: antena, tarjeta SIM, alimentación, módem, lugar de instalación;
- dónde el problema parece un incidente de la estación base o del operador de red móvil;
- si existen incidentes horarios masivos en toda la flota;
- qué días fueron los más problemáticos;
- qué tipos de corrector caen con más frecuencia en sesiones largas;
- cuánta energía se gastó aproximadamente en retransmisiones o transmisiones prolongadas;
- qué nodos requieren una visita de campo con antena externa, repetidor o verificación de la SIM;
- dónde conviene comprobar el operador de red móvil o la calidad de la cobertura en una ubicación concreta.
El informe no evalúa la corrección de la medición comercial de gas y no es un dictamen pericial
sobre la elusión de la medición. Analiza únicamente las sesiones de comunicación: duración,
frecuencia de anomalías, magnitud de los incidentes, calidad de la señal y la causa probable de
las sesiones largas.
## Dónde encaja el informe
El informe pertenece al diagnóstico operativo de la telemetría. No debe mezclar dos situaciones diferentes:
1. **Sin comunicación alguna.** El nodo no se conecta, no hay datos.
2. **Hay comunicación, pero las sesiones son demasiado largas.** El nodo transmite datos, pero lo hace lentamente, de forma inestable o con reintentos.
Este informe analiza la **segunda** situación. Cuando no hay comunicación, archivo ni datos en absoluto, utilice el informe Nodos con más problemas; cuando necesite comprobar si los datos de un solo nodo son aptos para la medición, utilice Analítica de consumo.
## Para quién es el informe
| Rol | Qué obtiene del informe |
| --------------------------- | ----------------------------------------------------------------------------------------------- |
| Responsable de operaciones | panorama general de la flota, número de nodos con anomalías, incidentes masivos |
| Ingeniero de comunicaciones | lista de nodos con mal RSSI, sesiones largas y problemas locales |
| Despachador | lista priorizada de tiques y días problemáticos |
| Cuadrilla de campo | nodos principales para verificación de antena, SIM, alimentación y lugar de instalación |
| Ingeniero de integración | diagnóstico de disponibilidad de datos, cobertura de la API y casos de datos de sesión ausentes |
| Especialista en compras | desglose comparativo por tipo de corrector |
| Analista de flota | hipótesis de causa raíz: estación base, operador, firmware, nodo local |
## Lo que el informe no hace
El informe no debe:
- demostrar que un módem concreto está averiado sin una visita de campo;
- tratar una sesión larga como prueba directa de un dispositivo defectuoso;
- culpar automáticamente al servidor o al operador de red móvil;
- mezclar «sin datos» con «sin anomalías»;
- comparar la duración de las sesiones de todos los nodos con un único umbral común;
- considerar estadísticamente fiable un periodo corto con pocas sesiones;
- extraer conclusiones sobre la calidad de un modelo de dispositivo sin tener en cuenta el número de dispositivos en la muestra;
- sustituir un estudio radiotécnico del lugar de instalación;
- tratar la estimación de pérdida de batería como una medición precisa;
- usar el comentario de la IA como fuente de diagnóstico.
## Términos clave
| Término | Significado |
| ---------------------- | ---------------------------------------------------------------------------------------- |
| Sesión de comunicación | un episodio de conexión del dispositivo al sistema de transmisión de datos |
| Duración de la sesión | tiempo desde el inicio de la sesión hasta su finalización |
| Sesión normal | una sesión cuya duración se encuentra dentro de la norma individual del nodo |
| Sesión larga | una sesión cuya duración supera el umbral IQR individual del nodo |
| `IQR` | rango intercuartílico: `Q3 − Q1` |
| `Q1` | primer cuartil de las duraciones de sesión |
| `Q3` | tercer cuartil de las duraciones de sesión |
| `UpperFence` | cota superior de la norma: `Q3 + 1.5 × IQR` |
| `RSSI` | nivel de señal de radio, dBm |
| `CSQ` | índice de calidad de señal GSM, convertible a dBm |
| `Btm` | tensión de batería o indicador de alimentación del dispositivo |
| `Long share` | proporción de sesiones largas entre todas las sesiones de un nodo |
| `Severity score` | evaluación final del nivel de problema de un nodo por sesiones largas |
| Incidente | agrupación horaria en la que aparecieron sesiones largas simultáneamente en varios nodos |
| `RCA` | análisis de causa probable: estación base, red, servidor, firmware, nodo local |
| `Battery loss` | estimación aproximada de la energía gastada por el exceso de duración de transmisión |
## Lógica general del informe
El informe se construye como un análisis de sesiones de comunicación a escala de toda la flota.
```text
Lista de nodos de la flota
→ obtener las sesiones de comunicación
→ comprobar la disponibilidad de datos
→ norma de sesión individual para cada nodo
→ búsqueda de sesiones largas mediante IQR
→ calcular la puntuación de cada nodo
→ agrupar las sesiones largas en incidentes horarios
→ determinar la causa probable RCA
→ distribuir las hipótesis entre los nodos
→ nodos con más problemas
→ desglose por tipo de corrector
→ desglose por días y meses
→ recomendaciones para operaciones
```
El principio principal:
```text
una sesión larga se define respecto a la norma de un nodo concreto,
no respecto a un umbral fijo común para toda la flota.
```
Esto importa porque distintos dispositivos, regiones, operadores de red móvil y modos de sondeo pueden tener distintas duraciones normales de sesión.
## Parámetros de ejecución
| Parámetro | Significado |
| ------------------------------------------- | ------------------------------------------------------------------------------ |
| Fecha desde / Fecha hasta | límites de la ventana de análisis |
| Ventana de análisis, días | ventana de reserva usada cuando las fechas están vacías (por defecto 30) |
| Nodos por tipo de corrector | tamaño de muestra por tipo; `0` significa todos los nodos de la flota |
| Mínimo de sesiones por nodo para IQR | número mínimo de sesiones que un nodo necesita para calificar (por defecto 30) |
| Número de nodos problemáticos en el informe | tamaño de la tabla de los N principales (por defecto 50) |
| Análisis LLM | narrativa de IA opcional que explica los resultados |
| Empresa de servicios | restringe el análisis a la flota de un único proveedor |
## Datos de entrada
### Datos principales
| Datos | Para qué se necesitan |
| --------------------------- | ------------------------------------------------------------- |
| Lista de nodos | determinar la flota de análisis |
| Tipo de corrector | construir el desglose por modelo |
| `Equipment ID` | obtener las sesiones de un dispositivo concreto |
| Sesiones de comunicación | núcleo del informe |
| Hora de inicio de la sesión | agrupación por días, meses y horas |
| Duración de la sesión | el indicador principal analizado |
| `RSSI` / `CSQ` | estimación de la calidad de la señal de radio |
| `Btm` / batería | estimación de la influencia de la alimentación |
| Organización / ubicación | atribución del incidente: cliente local, estación base, flota |
### Conjunto mínimo requerido
Para un análisis correcto de un nodo se necesita lo siguiente:
- identificador del dispositivo;
- al menos el número mínimo de sesiones;
- duración de cada sesión;
- marca de tiempo de cada sesión.
Si falta la duración de la sesión, esa sesión no participa en el análisis IQR.
## Disponibilidad de datos: la compuerta de datos
Antes de calcular las anomalías, el informe comprueba si el análisis puede realizarse en absoluto. El bloque de disponibilidad de datos muestra el tamaño de la flota, el tamaño tras el filtro de empresa, cuántos nodos devolvieron datos de sesión y cuántos de ellos superaron el mínimo de sesiones para IQR. Es un diagnóstico **de importancia crítica**: sin él, «sin anomalías» se confunde fácilmente con «sin datos para analizar».
### Principales indicadores de disponibilidad
| Indicador | Fórmula / valor |
| ----------------------------------------- | -------------------------------- |
| Nodos en la flota | `N_park` |
| Nodos en la muestra | `N_sampled` |
| Nodos con datos de sesión | `N_with_data` |
| Nodos que superaron el mínimo de sesiones | `N_qualified` |
| Total de sesiones | `N_sessions` |
| Llamadas a la API | `N_calls` |
| Errores de la API | `N_errors` |
| Tasa de error de la API | `N_errors / N_calls × 100%` |
| Cobertura de datos | `N_with_data / N_sampled × 100%` |
| Cobertura de la muestra IQR | `N_qualified / N_sampled × 100%` |
### Tasa de error de la API
$$
APIErrorRate =
\frac{N_{errors}}{N_{calls}} \times 100\%
$$
### Cobertura de datos
$$
Coverage_{with\_data} =
\frac{N_{with\_data}}{N_{sampled}} \times 100\%
$$
### Cobertura por nodos aptos para IQR
$$
Coverage_{qualified} =
\frac{N_{qualified}}{N_{sampled}} \times 100\%
$$
### Estados de disponibilidad
| Estado | Condición | Qué significa |
| -------------- | ------------------------------------------------- | ----------------------------------------------- |
| `OK` | existe muestra suficiente para IQR | el informe puede leerse como operativo |
| `DEGRADED` | la muestra es pequeña pero el análisis es posible | las conclusiones son prudentes |
| `INCONCLUSIVE` | muchos errores o cobertura críticamente baja | las conclusiones sobre anomalías no son fiables |
| `NO_DATA` | no hay datos de sesión | el análisis es imposible |
| `NO_FLEET` | no hay nodos tras el filtrado | no hay nada que analizar |
### Condiciones críticas
El análisis se considera imposible si:
$$
APIErrorRate \ge 50\%
$$
o:
$$
Coverage_{with\_data} < 5\%
$$
o:
$$
N_{qualified} = 0
$$
«Sin anomalías» y «sin datos para analizar» son estados diferentes. Si faltan los datos de sesión,
el informe no debe afirmar que no se encontraron anomalías.
## Mínimo de sesiones por nodo
Para un análisis IQR fiable, cada nodo debe tener un número suficiente de sesiones.
### Umbral mínimo
Por defecto:
$$
N_{sessions,station} \ge 30
$$
Si un nodo tiene menos sesiones, la norma individual se considera estadísticamente poco fiable y el nodo no supera el filtro IQR.
### Por qué se necesita un mínimo
El IQR utiliza estimaciones de cuartiles. Con un número pequeño de observaciones, el cuartil se vuelve inestable:
- una sesión larga aleatoria puede sobreestimar el umbral;
- un periodo de comunicación corto puede subestimar el umbral;
- resulta imposible distinguir la norma del nodo del azar.
## Norma individual de duración de sesión
### Por qué la norma es individual
No se puede usar un único umbral común para toda la flota, p. ej. «todas las sesiones de más de 10 minutos son malas». Distintos nodos tienen distintas condiciones de comunicación:
- distintos tipos de corrector;
- distintos operadores de red móvil;
- distinto RSSI;
- distintos volúmenes de archivo;
- distintos horarios de sondeo;
- distintos lugares de instalación;
- distintas antenas.
Por tanto, para cada nodo se calcula su propia norma estadística.
### Selección de duraciones válidas
Para cada nodo se toman únicamente las duraciones positivas:
$$
D = \{d_i \mid d_i > 0\}
$$
donde:
- `d_i` — duración de la i-ésima sesión en segundos.
### Cuartiles
Las duraciones se ordenan de forma ascendente.
$$
D_{sorted} = sort(D)
$$
Primer cuartil:
$$
Q1 = percentile(D, 25\%)
$$
Mediana:
$$
Q2 = median(D)
$$
Tercer cuartil:
$$
Q3 = percentile(D, 75\%)
$$
### Rango intercuartílico
$$
IQR = Q3 - Q1
$$
### Cota superior de la norma según la valla de Tukey
Para cada nodo se calcula una cota superior individual de la norma:
$$
UpperFence = Q3 + 1.5 \times IQR
$$
Esta es la clásica regla de las vallas de Tukey para la detección de valores atípicos.
### Sesión larga
Una sesión se considera anormalmente larga si:
$$
d_i > UpperFence
$$
donde:
- `d_i` — duración de la sesión;
- `UpperFence` — el umbral individual de este nodo.
Si un nodo suele tener sesiones cortas, su umbral será bajo. Si un nodo suele tener sesiones más
largas, su umbral será más alto. El informe identifica una anomalía **respecto a la propia norma
del nodo**.
## Indicadores básicos del nodo
Para cada nodo se calculan los siguientes indicadores.
### Número total de sesiones
$$
N_{total} = count(D)
$$
### Número de sesiones largas
$$
N_{long} = count(d_i > UpperFence)
$$
### Proporción de sesiones largas
$$
Pct_{long} =
\frac{N_{long}}{N_{total}} \times 100\%
$$
### Duración media de todas las sesiones
$$
AvgDuration =
\frac{\sum d_i}{N_{total}}
$$
### Duración media de las sesiones largas
$$
AvgLongDuration =
\frac{\sum_{d_i > UpperFence} d_i}{N_{long}}
$$
### Duración máxima
$$
MaxLongDuration =
max(d_i \mid d_i > UpperFence)
$$
### RSSI medio
$$
RSSI_{avg} =
\frac{\sum RSSI_i}{N_{RSSI}}
$$
donde `N_RSSI` es el número de sesiones con un valor de RSSI disponible.
## Puntuación de problema del nodo
### Significado de la puntuación
La puntuación muestra cuán problemático es un nodo en términos de sesiones largas. Tiene en cuenta tres dimensiones:
1. **proporción de sesiones largas**;
2. **cuánto superan las sesiones largas la norma**;
3. **número absoluto de sesiones largas**.
Este enfoque evita sobrestimar un valor atípico puntual y evita subestimar un nodo con un gran número de sesiones moderadamente largas.
### Componente A — proporción de sesiones largas
$$
A =
min(100,\;4 \times Pct_{long})
$$
Interpretación:
| Proporción de largas | A |
| -------------------: | --: |
| 5% | 20 |
| 10% | 40 |
| 25% | 100 |
| >25% | 100 |
### Componente B — duración relativa
$$
B =
min
\left(
100,\;
8 \times \frac{AvgLongDuration}{max(1, MedianDuration)}
\right)
$$
donde `MedianDuration` es la duración mediana de sesión del nodo.
Interpretación:
| AvgLong / Median | B |
| ---------------: | --: |
| 2× | 16 |
| 5× | 40 |
| 10× | 80 |
| 12.5× | 100 |
### Componente C — número de sesiones largas
$$
C =
min(100,\;N_{long})
$$
Es decir, 100 o más sesiones largas aportan la contribución máxima de este componente.
### Puntuación final
$$
Score =
0.5 \times A
+
0.3 \times B
+
0.2 \times C
$$
donde:
- `A` — proporción de sesiones largas;
- `B` — duración relativa de las sesiones largas;
- `C` — número absoluto de sesiones largas.
La puntuación final está acotada en el rango:
$$
0 \le Score \le 100
$$
### Interpretación de la puntuación
| Score | Nivel |
| ----: | ------------------------------------- |
| ≥ 80 | nodo de comunicación crítico |
| 60–80 | prioridad alta |
| 40–60 | prioridad media |
| 20–40 | observación / verificación programada |
| < 20 | señal débil |
La puntuación no demuestra una causa. Una puntuación alta indica que el nodo supera con frecuencia
o de forma intensa su propia norma de duración de sesión. **La causa se determina por separado
mediante RCA.**
## Estimación de pérdida de batería en sesiones largas
### Significado
Una sesión larga aumenta el tiempo de transmisión y puede consumir batería adicional. El informe ofrece una estimación **aproximada** del gasto energético excedente. No es una medición precisa de la batería, sino una estimación operativa.
### Tiempo de transmisión excedente
Para cada sesión larga se calcula el exceso sobre la norma mediana del nodo:
$$
ExtraTime_i =
max(0,\;d_i - MedianDuration)
$$
Tiempo excedente total:
$$
ExtraTime_{total} =
\sum_{i \in LongSessions} ExtraTime_i
$$
### Corriente de transmisión
Para la estimación aproximada se utiliza una corriente base de transmisión:
$$
I_{TX} = 340 \; mA
$$
### Pérdida de batería
$$
BatteryLoss_{mAh} =
\frac{I_{TX} \times ExtraTime_{total}}{3600}
$$
donde:
- `ExtraTime_total` — en segundos;
- `I_TX` — corriente en miliamperios;
- resultado — en mAh.
Para mostrar en Ah:
$$
BatteryLoss_{Ah} =
\frac{BatteryLoss_{mAh}}{1000}
$$
### Limitación
Esta estimación no tiene en cuenta:
- el perfil de corriente real del modelo concreto;
- el modo de reposo;
- los reintentos a nivel del módem;
- la potencia del transmisor;
- la temperatura;
- la edad de la batería;
- la capacidad de la batería;
- la calidad de la red en el momento de la transmisión.
Por tanto, debe leerse como una **estimación de orden de magnitud**, no como una medición de laboratorio.
## RSSI y CSQ
### RSSI
`RSSI` muestra el nivel de señal de radio en dBm. Cuanto más cerca está el valor de cero, más fuerte es la señal.
Interpretación aproximada:
| RSSI | Calificación |
| ----------: | ------------ |
| ≥ −65 dBm | señal buena |
| −65…−75 dBm | aceptable |
| −75…−85 dBm | débil |
| < −85 dBm | muy débil |
### CSQ
Algunos dispositivos no transmiten el RSSI en dBm, sino el `CSQ` — el índice de calidad de señal GSM. Si el valor parece un CSQ, puede convertirse:
$$
RSSI_{dBm} =
-113 + 2 \times CSQ
$$
Ejemplo:
$$
CSQ = 29
$$
$$
RSSI = -113 + 2 \times 29 = -55 \; dBm
$$
### Señal débil local
Si:
$$
RSSI_{avg} < -85 \; dBm
$$
y las anomalías del nodo no coinciden con incidentes masivos de la flota, la causa puede clasificarse como:
```text
señal débil en el lugar de instalación
```
## Agrupación de sesiones largas en incidentes
Las anomalías se agrupan en ventanas horarias. Si varios nodos recibieron sesiones largas en la misma hora, esto **no es un problema local del nodo**, sino un incidente de red, servidor u operador. La hipótesis se determina automáticamente por la amplitud de la cobertura: el número de nodos, modelos y clientes en la ventana.
### Por qué se necesita la agrupación
Si las sesiones largas aparecieron en muchos nodos en la misma hora, lo más probable es que no sea un problema local de un solo dispositivo. Podría ser:
- un problema de la estación base;
- una sobrecarga local del operador;
- un incidente masivo de red;
- una operación de servidor programada;
- una peculiaridad del firmware de un modelo concreto.
### Cubo horario
Cada sesión larga se ubica en un cubo horario:
$$
Bucket(t) =
floor\left(
\frac{t}{1h}
\right) \times 1h
$$
Es decir, todos los eventos dentro de una hora caen en un mismo cubo.
### Incidente
Un cubo horario se considera un incidente si al menos:
$$
N_{stations,bucket} \ge 5
$$
nodos se ven afectados.
### Indicadores del incidente
Para cada incidente se calculan:
| Indicador | Fórmula |
| -------------------------------- | -------------------------------- |
| número de nodos | `count(unique station_id)` |
| número de modelos | `count(unique equipment_type)` |
| número de clientes / ubicaciones | `count(unique customer_id)` |
| número de sesiones | `count(long sessions in bucket)` |
| RSSI medio | `average(RSSI)` |
| modelos principales | `top equipment types by count` |
## RCA: atribución de la causa del incidente
El resumen de la flota identifica al principal culpable —torre de telefonía, servidor, red, firmware o nodo local—, ofrece una atribución de culpa entre los nodos con anomalías y elabora un plan de acción. Una narrativa de IA opcional al final explica las cifras en lenguaje sencillo, pero no las modifica.
El RCA es la clasificación de la causa probable de las sesiones largas.
### Hipótesis posibles
| Hipótesis | Significado |
| ----------------- | --------------------------------------------------- |
| `Server driver` | fallo del controlador de recopilación masiva |
| `Server routine` | operación o mantenimiento regular del servidor |
| `Network outage` | fallo del operador de red móvil |
| `Cell tower` | problema con una estación base o ubicación concreta |
| `Firmware` | problema del modelo de dispositivo / firmware |
| `Local signal` | señal débil en el lugar de instalación |
| `Battery low` | baja alimentación / degradación de la batería |
| `Isolated device` | avería local de un nodo concreto |
| `Mixed causes` | causas mixtas |
### Incidente amplio de servidor
Un incidente se clasifica como de servidor si se ven afectados simultáneamente muchos nodos, muchos modelos y muchos clientes. De forma condicional:
$$
N_{stations} \ge ServerWideStations
$$
$$
N_{models} \ge ServerWideModels
$$
$$
N_{customers} \ge ServerWideCustomers
$$
En el informe, esto significa:
```text
incidente amplio de la flota, no parecido a un problema local de un solo nodo.
```
### Caída de la red del operador
Si se ven afectados varios modelos y varios clientes, pero la magnitud no alcanza la de un fallo de servidor:
$$
N_{models} \ge 3
$$
y:
$$
N_{customers} \ge 3
$$
entonces la hipótesis es:
```text
fallo de la red móvil / incidente del operador
```
### Problema de la estación base
Si se ven afectados muchos nodos, pero pertenecen a una o dos ubicaciones / clientes:
$$
N_{customers} \le 2
$$
y:
$$
N_{stations} \ge CellMinStations
$$
entonces la hipótesis es:
```text
problema de la estación base o problema de cobertura local
```
### Problema de firmware o de modelo
Si se ve afectado un único modelo, pero en distintos clientes:
$$
N_{models} = 1
$$
y:
$$
N_{customers} \ge 3
$$
entonces la hipótesis es:
```text
peculiaridad del firmware / modelo de dispositivo
```
### Causas mixtas
Si las condiciones no arrojan una clasificación inequívoca, el incidente recibe el estado:
```text
causas mixtas
```
## Rutina recurrente del servidor
A veces los incidentes masivos de servidor ocurren a la misma hora del día.
### Condición
Si hay al menos tres incidentes amplios de servidor a la misma hora del día:
$$
N_{server\_incidents,same\_hour} \ge 3
$$
pueden clasificarse como:
```text
rutina del servidor
```
### Significado
Esto puede indicar una tarea nocturna regular, mantenimiento del archivo, un proceso por lotes o una operación masiva que afecta a la duración de la sesión.
## Atribución de causa por nodo
Tras buscar incidentes de la flota, el informe determina qué predomina en cada nodo: incidentes externos o un problema local.
### Proporción de anomalías de un nodo que caen en incidentes de la flota
$$
InIncidentPct =
\frac{N_{long,in\_incidents}}{N_{long}} \times 100\%
$$
### Si la mayoría de las anomalías coincidieron con incidentes de la flota
Si:
$$
InIncidentPct \ge 70\%
$$
entonces la causa dominante del nodo se toma del incidente de la flota:
```text
network_outage / cell_tower / firmware / server
```
Esto significa:
```text
el dispositivo probablemente no es el principal culpable; sufrió junto con los demás.
```
### Comprobación de batería baja
Si las anomalías no se explican por incidentes de la flota, se comprueba la alimentación. Sea:
$$
Btm_{first}
$$
el primer valor de batería disponible en las sesiones largas, y:
$$
Btm_{last}
$$
el último valor disponible. La caída:
$$
BtmDrop =
Btm_{first} - Btm_{last}
$$
La hipótesis `battery_low` es posible si:
$$
Btm_{first} < 3500 \; mV
$$
y:
$$
BtmDrop > 200 \; mV
$$
### Comprobación de señal débil local
Si:
$$
RSSI_{avg} < -85 \; dBm
$$
entonces la hipótesis es:
```text
señal débil en el lugar de instalación
```
### Avería aislada del nodo
Si:
- las anomalías no coinciden con incidentes de la flota;
- la batería no explica el panorama;
- el RSSI no es críticamente débil;
entonces la causa se clasifica como:
```text
avería local del nodo
```
## Distribución de hipótesis en la flota
Para cada nodo se selecciona la causa dominante. Cuando la mayoría de los nodos sufrieron incidentes de la flota, el nodo en sí no tiene la culpa; solo una minoría presenta un problema local aislado. Esto cambia el plan de acción: el esfuerzo principal se dirige a las estaciones base y al operador, no a una visita de campo masiva a cada nodo con anomalías.
El informe muestra cuántos nodos se atribuyen a cada causa dominante.
### Fórmula de la proporción de hipótesis
$$
Share_{hypothesis} =
\frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\%
$$
### Grupos de causas
Para el resumen de gestión, las hipótesis pueden agruparse:
| Grupo | Incluye |
| --------------------------------- | ----------------------------------------------------------------- |
| red / servidor | `server_driver`, `server_routine`, `network_outage`, `cell_tower` |
| problemas locales del dispositivo | `isolated_device`, `local_signal`, `battery_low` |
| modelo / firmware | `firmware` |
| mixto | `mixed` |
### Interpretación
| Predomina | Qué hacer |
| ----------------- | ------------------------------------------------------------------------------------ |
| `Cell tower` | comprobar la cobertura, el operador y las antenas externas en los clientes afectados |
| `Local signal` | visita de campo al nodo concreto, antena, repetidor, lugar de instalación |
| `Isolated device` | diagnóstico de módem, SIM, alimentación y firmware |
| `Firmware` | comprobar la versión del software y contactar con el proveedor |
| `Server routine` | comprobar los procesos regulares de la plataforma |
| `Network outage` | consultar al operador de red móvil por hora y zona |
## Nodos con más problemas
La tabla de nodos con más problemas clasifica los nodos por una puntuación compuesta (0–100) construida a partir de la proporción de sesiones largas, su duración media y su cantidad. Al hacer clic en una fila se despliegan las sesiones más largas del nodo con los valores de RSSI y `Btm` — útil para planificar una visita de campo.
### Propósito
La tabla muestra adónde ir o qué comprobar primero.
### Columnas de la tabla
| Columna | Significado |
| ------------------ | -------------------------------------- |
| Nodo | nombre e ID del nodo |
| Corrector | tipo de dispositivo |
| Sesiones | número total de sesiones válidas |
| Largas | número de sesiones anormalmente largas |
| Proporción | porcentaje de sesiones largas |
| Media larga | duración media de las sesiones largas |
| Sesión máxima | peor sesión encontrada |
| `RSSI` medio | calidad de la señal de radio |
| Pérdida de batería | energía excedente estimada |
| Score | puntuación compuesta del problema |
### Cómo leer el top
Una puntuación alta puede surgir por distintos motivos:
- una gran proporción de sesiones largas;
- sesiones individuales muy largas;
- un gran número absoluto de sesiones largas;
- una combinación de estos factores.
Para planificar una visita de campo, no lea solo la puntuación, sino también:
- el `RSSI`;
- la hipótesis RCA;
- la pérdida de batería;
- la sesión máxima;
- si cae en incidentes de la flota;
- el tipo de corrector.
## Días con más problemas
Todas las sesiones anómalas se agrupan por día natural. El día con mayor número de anomalías es, muy probablemente, donde se produjo un incidente de la flota. Cada día se despliega en la lista de nodos con sus anomalías, la sesión máxima y los enlaces. Esto es útil para investigar eventos masivos y comprobar su recurrencia.
### Propósito
El desglose por días muestra los días en que las sesiones largas aparecieron de forma masiva en toda la flota.
### Indicadores del día
| Indicador | Significado |
| --------------- | ------------------------------------- |
| Fecha | día natural |
| Sesiones largas | número de sesiones largas del día |
| Nodos | cuántos nodos se ven afectados |
| Media larga | duración media de las sesiones largas |
| Sesión máxima | peor caso del día |
| Peor nodo | nodo con la sesión máxima |
### Interpretación
| Panorama | Causa posible |
| --------------------------- | ---------------------------------------------------------------------- |
| muchos nodos en un solo día | incidente de red o de flota |
| un nodo todos los días | problema local |
| un pico en fin de semana | red del operador / trabajos de mantenimiento |
| picos a la misma hora | tarea regular o programación |
| crecimiento mensual | degradación de la red, sobrecarga estacional, cambio de modo de sondeo |
## Desglose por tipo de corrector
El bloque de cobertura muestra qué se comprobó de la flota para cada tipo de corrector: cuántos nodos hay en la muestra, cuántos devolvieron datos, cuántos superaron el IQR y cuántos presentan anomalías. Si un tipo muestra «norma», los datos llegaron pero no se encontraron anomalías. «Sin datos» significa que el tipo no devuelve la duración de sesión en la API — para algunos modelos esto es normal.
Despliegue un tipo para ver todos sus nodos con anomalías; despliegue un nodo para ver sus sesiones largas concretas con hora, duración, RSSI y `Btm`. El color de resaltado de la sesión depende de cuánto más larga es la sesión que la norma del nodo.
### Propósito
El desglose por tipo de corrector muestra qué modelos caen con más frecuencia en sesiones anormalmente largas.
### Indicadores por tipo
| Indicador | Significado |
| ------------- | ------------------------------------------ |
| En muestra | cuántos nodos de este tipo hay en la flota |
| Con datos | cuántos nodos devolvieron datos de sesión |
| Superaron IQR | cuántos nodos tienen el mínimo de sesiones |
| Anomalías | número de sesiones largas |
| Estado | norma / anomalías / sin datos |
### Limitación importante
**No se pueden comparar directamente los tipos de corrector solo por el número de anomalías.** Hay que tener en cuenta:
- cuántos dispositivos de este tipo hay en la flota;
- cuántos de ellos devolvieron datos;
- cuántos superaron el mínimo de sesiones;
- dónde están instalados;
- en qué redes operan;
- si tienen el mismo horario de sondeo;
- si están concentrados en un único cliente.
### Proporción de anomalías normalizada por tipo
Para una comparación correcta se puede usar:
$$
TypeAnomalyRate =
\frac{N_{long,type}}{N_{sessions,type}} \times 100\%
$$
o:
$$
TypeAffectedRate =
\frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\%
$$
## Desglose por tiempo: dinámica y meses
El gráfico de dinámica diaria muestra cuántas sesiones anómalas se produjeron en toda la flota cada día de la ventana. Se aprecian «estallidos»: días de mala comunicación en toda la red. Un pico que coincide con el registro de incidentes suele ser una serie de problemas de la estación base en una única ubicación.
El desglose por meses naturales ayuda a apreciar estacionalidad o una tendencia a largo plazo. Un pico mensual masivo corresponde a la misma serie de incidentes vista en la dinámica diaria; un crecimiento gradual en el tiempo es candidato a una degradación de la comunicación o de la batería.
### Propósito
El desglose por meses muestra la estacionalidad o una tendencia a largo plazo de las sesiones largas.
### Indicador del mes
$$
N_{long,month} =
count(long\_sessions \; in \; month)
$$
### Proporción del mes
Si necesita mostrar una proporción:
$$
Share_{month} =
\frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\%
$$
### Interpretación
| Panorama | Explicación posible |
| --------------------------- | ------------------------------------------------------ |
| pico mensual brusco | cambio de red, fallo masivo, carga estacional |
| crecimiento gradual | degradación de la comunicación o de la batería |
| pico invernal | condiciones meteorológicas, carga de red, alimentación |
| pico tras una actualización | firmware, ajustes, horario de sondeo |
## Resaltado por color de cada sesión
Cuando se despliega un nodo, sus sesiones largas individuales se resaltan según la intensidad del sobrepaso del umbral individual, y se muestran los valores precisos de RSSI y `Btm` en el momento de cada sesión larga. Esto es lo que necesita la cuadrilla de campo: un RSSI bajo apunta a un problema de señal de radio, mientras que una tensión de batería normal descarta la batería.
### Razón de sobrepaso
$$
Ratio_i =
\frac{d_i}{UpperFence}
$$
### Interpretación
| Ratio | Color / nivel |
| ----: | ---------------- |
| 1–2× | sobrepaso leve |
| 2–5× | sobrepaso medio |
| ≥5× | sobrepaso fuerte |
Esto ayuda a distinguir rápidamente las sesiones moderadamente largas de las extremas.
## Qué hacer según los resultados del informe
### Si la causa es una estación base
Comprobar:
- la calidad de la cobertura en la ubicación;
- un operador de red móvil alternativo;
- una antena externa;
- un repetidor;
- la recurrencia de los incidentes por día;
- los nodos vecinos en la misma ubicación;
- la sobrecarga de red en horas concretas.
### Si la causa es un nodo local
Comprobar:
- la antena;
- la tarjeta SIM;
- el módem;
- la alimentación;
- la batería;
- los conectores;
- el lugar de instalación;
- las interferencias;
- la versión del firmware;
- los ajustes del horario de transmisión.
### Si la causa es una señal débil
Acciones:
- medir el RSSI in situ;
- intentar reubicar la antena;
- comprobar la orientación de la antena;
- comprobar un operador alternativo;
- instalar una antena externa o un repetidor.
### Si la causa es la batería
Acciones:
- comprobar el `Btm` in situ;
- sustituir la batería si es necesario;
- comprobar la corriente de consumo;
- comprobar la frecuencia de reintentos;
- comprobar si el dispositivo está sobrecargando la red con reintentos.
### Si la causa es el modelo / firmware
Acciones:
- agrupar los nodos por versión de software;
- consultar las notas de versión del proveedor;
- solicitar los problemas conocidos;
- comparar con otros modelos en las mismas ubicaciones;
- probar el modo de comunicación en laboratorio.
## Comentario de la IA
El comentario opcional de la IA lee el RCA y redacta un plan de visita de campo breve y legible para la cuadrilla. Esto es una **explicación en lenguaje natural, no una fuente de diagnóstico** — todas las cifras y causas las determinan las fórmulas y reglas anteriores.
### Qué puede hacer la IA
- resumir brevemente el RCA;
- explicar el principal culpable probable;
- destacar los nodos principales;
- formular un plan de visita de campo;
- explicar el desglose por modelos.
### Qué no puede hacer la IA
La IA **no puede**:
- cambiar el umbral IQR;
- cambiar la lista de sesiones largas;
- cambiar la puntuación;
- determinar la causa real sin datos;
- sustituir un estudio radiotécnico;
- sustituir una visita de campo;
- servir como base probatoria.
El análisis es determinista. El comentario de la IA debe leerse únicamente como texto explicativo
— todas las conclusiones numéricas las determinan las fórmulas y reglas.
## Errores típicos de interpretación
### Error: sesión larga = dispositivo defectuoso
Incorrecto. Una sesión larga puede deberse a la red, la estación base, una señal débil, una rutina del servidor, la antena local, la tarjeta SIM o la batería.
### Error: muchas anomalías en un modelo = el modelo es malo
Incorrecto. Hay que normalizar por el número de dispositivos, el número de sesiones, las ubicaciones y los operadores de red móvil.
### Error: sin anomalías = todo está bien
Incorrecto si no hay datos de sesión o la cobertura es demasiado baja.
### Error: un RSSI alto descarta un problema de comunicación
No siempre. Puede haber problemas del operador, sobrecarga, firmware, recepción del lado del servidor, reintentos o errores de protocolo.
### Error: pérdida de batería = consumo exacto de batería
Incorrecto. Es una estimación construida sobre el tiempo de transmisión excedente y una corriente nominal.
### Error: una única sesión extremadamente larga convierte al nodo en el problema principal
No siempre. La puntuación tiene en cuenta no solo el máximo, sino también la proporción, la duración media y el número de sesiones largas.
## Criterios mínimos para un informe completo
Un informe se considera metodológicamente completo si contiene:
- el periodo de análisis;
- la cobertura de la flota;
- el estado de la compuerta de datos;
- el número de nodos de la flota;
- el número de nodos sondeados;
- el número de nodos con datos de sesión;
- el número de nodos que superaron el umbral IQR;
- el número de sesiones en la muestra;
- el número de sesiones largas;
- el número de nodos con anomalías;
- la duración máxima de sesión;
- el número de incidentes horarios;
- la distribución de hipótesis RCA;
- la fórmula del umbral IQR;
- la fórmula de la puntuación del nodo;
- la fórmula de pérdida de batería;
- las reglas de clasificación RCA;
- la tabla de nodos con más problemas;
- el desglose por días;
- el desglose por tipo de corrector;
- el desglose por meses;
- la advertencia sobre la naturaleza aproximada de la pérdida de batería;
- la advertencia sobre el papel de la IA;
- las recomendaciones de acción.
## Fórmula consolidada del informe
Para cada nodo:
$$
D = \{d_i \mid d_i > 0\}
$$
$$
IQR = Q3(D) - Q1(D)
$$
$$
UpperFence = Q3(D) + 1.5 \times IQR
$$
$$
LongSessions =
\{d_i \mid d_i > UpperFence\}
$$
$$
Pct_{long} =
\frac{|LongSessions|}{|D|} \times 100\%
$$
$$
A = min(100,\;4 \times Pct_{long})
$$
$$
B =
min
\left(
100,\;
8 \times
\frac{AvgLongDuration}{max(1, MedianDuration)}
\right)
$$
$$
C = min(100,\;|LongSessions|)
$$
$$
Score =
0.5A + 0.3B + 0.2C
$$
Estimación del consumo excedente de batería:
$$
ExtraTime_{total} =
\sum_{d_i \in LongSessions}
max(0,\;d_i - MedianDuration)
$$
$$
BatteryLoss_{mAh} =
\frac{340 \times ExtraTime_{total}}{3600}
$$
Agrupación de incidentes:
$$
Bucket(t) =
floor(t / 1h) \times 1h
$$
$$
Incident =
Bucket \; where \; N_{unique\_stations} \ge 5
$$
## Cláusula de exención recomendada
```text
El informe detecta sesiones de comunicación anormalmente largas respecto a la
norma individual de cada nodo. El resultado se utiliza para priorizar el
diagnóstico de comunicaciones, antenas, tarjetas SIM, alimentación, operadores y
estaciones base. El informe no es prueba de la avería de un dispositivo concreto
sin una visita de campo y no evalúa la corrección de la medición comercial de gas.
```
## Relación con otros informes
| Si necesita entender | Use |
| -------------------------------------------------------------------- | ----------------------- |
| qué nodos mantienen la comunicación mucho tiempo y agotan la batería | este informe |
| qué nodos no tienen comunicación ni archivo | Nodos con más problemas |
| si se puede cerrar el periodo de un nodo concreto | Analítica de consumo |
| si hay sospecha de submedición | Nodos sospechosos |
| por qué un nodo concreto es sospechoso | Elusión de la medición |
| cuándo sustituir las baterías | Pronóstico de batería |
Esta separación evita que las sesiones largas de comunicación se mezclen con conclusiones comerciales, metrológicas y periciales.