Sesiones largas

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.

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.

Dónde encaja el informe

El informe pertenece al diagnóstico operativo de la telemetría. No debe mezclar dos situaciones diferentes:

Sin comunicación alguna. El nodo no se conecta, no hay datos.
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\%

Coverage_{with\_data} < 5\%

N_{qualified} = 0

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.

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:

proporción de sesiones largas;
cuánto superan las sesiones largas la norma;
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

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

Resumen de la investigación de causa raíz

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

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

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

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

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.

Desglose detallado por tipo de corrector

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\%

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.

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.

Temas relacionados

Explorador de eventos

Última actualización el 23 de junio de 2026

¿Te resultó útil esta página?