Del drive test al diagnóstico: cómo leer una red sin perderse en los datos con un análisis de drive test ordenado

Después de un drive test es fácil terminar con miles de muestras, mapas de colores y la sensación de que la respuesta está ahí, en algún lugar. Casi nunca faltan datos. Lo que suele faltar es saber por dónde empezar.

Con los años aprendí a leer una ruta en un orden muy concreto, que me ahorra muchas horas:

🔹 Arranco por el síntoma que reportó el usuario o el KPI (una caída, un throughput bajo, un handover fallido) y ubico exactamente dónde y cuándo ocurrió. 🔹 En ese punto reviso RSRP y SINR juntos, porque buena cobertura con mala calidad casi siempre apunta a interferencia u overshooting, mientras que señal débil con buena calidad sugiere un hueco real. 🔹 Después bajo a los mensajes de capa 3 de los segundos previos al evento, como reportes de medición, comandos de handover o reestablecimientos de RRC. 🔹 Al final cruzo lo que vi en campo con los contadores de PM del OSS para esa celda y ese horario, y así confirmo si el problema es puntual o sistémico.

Hay trampas clásicas. Promediar todo el recorrido esconde justo los puntos que importan. Culpar a la cobertura cuando el SINR está gritando interferencia también es muy común, igual que olvidar la carga de la celda, que puede explicar un throughput bajo con señal excelente.

Hoy el drive test ya no trabaja solo. MDT, trazas de UE y datos de PM y CM permiten ver la red completa todo el tiempo, y alimentan los lazos cerrados de SON y las rApps en el SMO. Aun así, el criterio para leer esos datos sigue siendo el mismo de campo.

𝗟𝗼𝘀 𝗱𝗮𝘁𝗼𝘀 𝗵𝗮𝗯𝗹𝗮𝗻 𝗰𝘂𝗮𝗻𝗱𝗼 𝗲𝗹 𝗶𝗻𝗴𝗲𝗻𝗶𝗲𝗿𝗼 𝘀𝗮𝗯𝗲 𝗲𝘀𝗰𝘂𝗰𝗵𝗮𝗿𝗹𝗼𝘀.

#DriveTest #OptimizacionRF #RAN #5G #LTE #SON #ORAN #Telecomunicaciones