Análisis HSDPA con XCAP

CONCEPTOS BÁSICOS HSDPA: CANALES FÍSICOS, TRANSPORTE y CAPA MAC-HS 2Canales físicos:...........................................................................................2

HS-SCCH :................................................................................................2HS-DPCCH :..............................................................................................4

Canal de transporte HSDPA:........................................................................6HS-DSCH:................................................................................................6

Capa MAC-HS:.............................................................................................6ELEMENTOS DE INFORMACIÓN BÁSICA HSDPA EN XCAP....................................8

IEs del árbol HS-SCCH:.................................................................................9IEs del árbol HS-DSCH:................................................................................9IEs del árbol HS-DPCCH:.............................................................................10IEs del árbol MAC Info:...............................................................................11

METODOLOGÍA ANÁLISIS...............................................................................12INICIO: ESTADÍSTICAS DE LA SESIÓN DE PAQUETES.....................................12LOGGING MESSAGE....................................................................................12CREACIÓN DE TEMPLATES DE ANÁLISIS......................................................14

TEMPLATES R99.....................................................................................15TEMPLATES HSDPA.................................................................................17

CRITERIOS ANÁLISIS Y DIAGNÓSTICO.............................................................20ANEXO.........................................................................................................21

UTILIDADES SCANNER................................................................................21DETECCIÓN DE CABLES CRUZADOS..........................................................21POLUCIÓN DE PILOTOS...........................................................................22COBERTURA DE CELDA/SOBREALCANCES.................................................24

UTILIDADES RAMA “QUALCOMM” (R99)......................................................25DETECCIÓN DE VECINAS SIN DEFINIR.......................................................25

REVISIÓN CAPA TCP...................................................................................27

CONCEPTOS BÁSICOS HSDPA: CANALES FÍSICOS, TRANSPORTE y CAPA MAC-HS

El árbol de desglose HSDPA de XCAP ofrece la información más relevante sobre los distintos canales físicos, el canal de transporte HSDPA y la capa MAC-hs de HSDPA, presente en el NodoB y en el terminal.

Canales físicos:

HS-SCCH : o Canal DL de SF128 compartido entre todos los usuarios HSDPA de la celda. Los

usuarios deben leer primero este canal para ser capaces de decodificar los datos HSDPA, por lo que el nodo B transmite los canales HS-SCCH ciertos slots antes que los canales de datos.

o Lleva 5 informaciones básicas:1) A qué usuario van dirigidos los datos HSDPA2) Cuántos y qué códigos de SF16 llevan los datos dirigidos a ese usuario3) Con qué modulación se van a transmitir los datos (QPSK, 16QAM)4) Tamaño de la PDU MAC-hs (TB size) o cuántos bits de datos (antes de la

codificación de capa física, spreading y demás) llevan en total los códigos HSDPA indicados en 2).

5) Versión de redundancia (patrón de bits redundantes que se van a añadir durante la codificación de la MAC-hs PDU (TB size) para protección de errores en la transmisión radio).

Importante saber…

o En cada TTI (2ms), cada terminal debe leer todos los HS-SCCHs configurados en la celda para saber si alguno de los canales físicos HS-PDSCHs (códigos HSDPA SF16) llevan información de datos dirigida a él.

o Cada celda puede tener varios canales HS-SCCH configurados (hasta 4). Configuración de VDF-ES:

Celdas en f1 2 canales HS-SCCH Celdas en f2 3 canales HS-SCCH

El número de canales configurados equivale al número máximo de usuarios HSDPA a los que se les puede servir datos en paralelo, es decir, en el mismo TTI. El scheduler en el nodo B determinará como reparte entre estos usuarios los códigos, potencia e Iub disponibles (es decir, los que deja libres R99).

En este ejemplo hay configurados 3 HS-SCCHs:

¿Cómo decide a qué usuarios servir en cada tti, de entre todos los que hay en cada celda?

En cada TTI, el scheduler crea una lista o cola ordenada con los usuarios de la celda que tengan datos en el buffer de acuerdo al algoritmo Proportional Fair. Este algoritmo intenta asegurar que todos los usuarios con datos en buffer, estén en buenas o malas condiciones radio, ocupan las primeras posiciones de la cola durante el mismo porcentaje de tiempo. Una vez ordenados, y según los códigos HSDPA y potencia disponibles, el scheduler determina cómo repartirlos entre los “x” primeros de la lista (siendo “x” el número de canales HS-SCCH configurados), bien a partes iguales, bien según otro método.

Ejemplo Proporcional Fair:

¿Cómo lo hace Huawei?

Huawei siempre da todos los códigos y potencia que necesite el 1er usuario de la cola, teniendo en cuenta que HSDPA puede usar la potencia y códigos que deja libres R99. Si después de considerar al 1er usuario aún le quedan recursos, entonces reparte códigos y potencia al 2º según lo que éste necesite, y así sucesivamente. Según esto, si el 1er usuario abarcara todos los recursos disponibles de la celda, es posible que 2ºs y 3ºs HS-SCCHs no estén sirviendo a nadie.

o En el mensaje RB setup se le dice al terminal cuáles son los HS.SCCH configurados, mediante los índices de los códigos SF128 asignados a canales HS-SCCH :

[ 2008 Jun 21 11:09:40.445 ] DL DCCH - radioBearerSetup

[………………………………]dl-HSPDSCH-Informationhs-scch-InfomodeSpecificInfo fdd :hS-SCCHChannelisationCodeInfo4,5,6[………………………………]

HS-DPCCH : o Canal UL dedicado, es decir, uno por conexión HSDPA. o Lleva la información de feedback HSDPA del terminal al nodo B. Contiene 2

informaciones básicas:

1) CQI: Indicador de calidad radio de la conexión. Es un valor de 0 a 30, cuanto mayor sea la calidad, mayor es el CQI. El CQI da “derecho” al terminal a recibir un mayor o menor throughput, y el scheduler usa esta información para decidir cuánta potencia y códigos le puede dedicar.

Aunque los fabricantes de chipsets no desvelen la fórmula del CQI, lo que sí sabemos es que el CQI reportado guarda relación con el Ec/Io del canal CPICH. Por tanto, zonas con mal EcIo no podrán conseguir un buen throughput HSDPA.

El modo en que cada terminal calcula el CQI es propietario y secreto. Lo que deben asegurar es que con el CQI reportado, el terminal será capaz de recibir un cierto throughput HSDPA (éste es un requisito 3GPP expresado mediante tablas CQI vs. TBS para cada categoría de terminal), con un máximo de 10% de retransmisiones. Ejemplo de tabla para categoría 6 (3.2Mbps):

El terminal sabe que la potencia con que recibirá los canales de datos HSDPA es:

PHSPDSCH=PCPICH+Γ+Δ in dB

Where Δ is the reference power adjustment. For details, refer to 3GPP TS25.214.

Γ is configured as follows:

Γ=Max(-6,Min(13,PCellMAX-PCPICH-MPOconstant))

Y de este modo, conociendo la potencia con qué recibiría los datos, y con la exigencia anterior del 10%, usa las tablas 3GPP de CQI vs. TBS para reportar el CQI.

Por ejemplo, se necesita CQI>15 para llegar a 1800Kbps en capa física (unos 1.4 en capa App), CQI > 22 para 3.2Mbps en capa física (2.8 Mbps en aplicación), CQI> 25 para 7.2 Mbps en capa física (6.5Mbps en capa aplicación).

2) Resultado de la decodificación de los datos recibidos en el proceso HARQ/TTI anterior.

Hay 3 valores: ACK, NACK, DTX. DTX se usa cuando no se recibió nada en el proceso anterior, es

decir, no hubo datos dirigidos a este usuario.

Canal de transporte HSDPA:

HS-DSCH: Es el canal downlink que lleva los datos de usuario. Este canal transporta las MAC-

hs PDUS, cuyo tamaño viene determinado por el TBS, que es indicado al usuario en el HS-SCCH.

o Los canales físicos que llevan la información de este canal de transporte son los canales HS-PDSCHs de SF16, que comúnmente conocemos con el nombre de códigos HSDPA. A mayor número de códigos, mayor TBS son capaces de transportar y mayor throughput HSDPA.

o La configuración de VDF-ES en Huawei:

Celdas en F1: Máximo 10 códigos, mínimo 1 código. Celdas en F2: Máximo 10 códigos, mínimo 5 códigos.

El mínimo número de códigos sirve para garantizar que al menos siempre existen estos códigos disponibles para HSDPA, estando prohibido para R99 ocuparlos. El máximo no garantiza nada.

Capa MAC-HS:

Es la nueva capa MAC que añade la funcionalidad HSDPA en el terminal y en el Nodo B.

El principal beneficio de incluir una capa MAC en el nodo B es que permite:o Decisiones de scheduling en el nodo B, en lugar de la RNC, con lo cual se

recortan los retardos. o El TTI o mínimo tiempo en el que se mandan datos a través del interfaz

radio se reduce a 2ms. o La principal causa de las retransmisiones es la calidad del canal radio, es

decir, el trayecto entre Nodo B y terminal. Con HSDPA, las retransmisiones tienen lugar entre las capas MAC-hs de terminal y de nodo B, es decir, el terminal evalúa el CRC de los paquetes recibidos, y en caso de ser erróneo solicita la retransmisión al nodo B mediante un NACK. Estos paquetes erróneos nunca llegan a la RNC, y el número de paquetes retransmitidos por la RNC debe ser prácticamente 0. Sólo si se supera el número máximo de retransmisiones en capa MAC-hs (entre nodo y terminal), se pasaría el paquete erróneo a la capa superior del terminal (capa RLC) y esta capa se encargaría de solicitar la retransmisión mediante un NACK a la capa RLC de

la RNC. Cuando esto ocurre se incrementan los retardos y se reduce el throuhput.

o El throughput MAC-hs es muy similar al throughput RLC (siempre y cuando las retransmisiones en la capa RLC se mantenga a cero o casi cero) y da una idea clara del thp de aplicación que se va a conseguir.

La relación entre el throughput MAC-hs y el throughput del canal de trasnporte HS-DSCH (Physical Throughput served) es que en el throughput MAC-hs se están descontando los paquetes retransmitidos entre nodo B y terminal, es decir:

MAC-hs Throughput ≈ Physical Throughput Served * (1- HS-DSCH Retransmission rate)

ELEMENTOS DE INFORMACIÓN BÁSICA HSDPA EN XCAP

XCAP presenta varios árboles de desglose dentro del árbol dedicado a HSDPA (“Qualcomm HSDPA”). Dentro de cada árbol, se encuentran distintos elementos de información (IE) que se pueden visualizar en modo tabla, gráfico, mapa (siempre que el DT se haya hecho con GPS), etc… Cada IE contiene 1 dato por cada periodo de muestreo. El periodo de muestreo se elige al preparar el modelo:

Como el TTI de HSDPA es de 2ms, si elegimos un periodo de muestreo de 1s, XCAP proporcionará un valor cada segundo en cada elemento de información HSDPA, que será un resumen de lo ocurrido durante 1s/2ms=500 TTIs.

En general, basta con 1s de muestreo para analizar datos HSDPA.

IEs del árbol HS-SCCH:

Modulation scheme: QPSK, 16QAM

TB size: Tamaño del paquete de datos, MAC-hs PDU, enviados al terminal en cada TTI. Si dividimos este valor entre el TTI, es decir, entre 2ms, obtenemos el Phy Thp Scheduled.

Success Rate: % tiempo en que los datos HSDPA van dirigidos al usuario. Si este valor es pequeño, el thp HSDPA será bajo. Este valor es el opuesto al DTX que muestra el árbol de HS-DPCCH info, es decir :

HS-SCCH Success Rate = 100 – DTX Rate

Un valor menor del 40% no es deseable. Suele indicar muchos usuarios HSDPA,y/o escasos recursos en el nodo disponibles por alto tráfico R99. Para la segunda opción, conviene apoyarse en el valor del Phy. Thp. Scheduled, explicado más abajo. En cualquier caso, hay que consultar contadores.

Nº codes: Número de códigos HSDPA (SF16) asignados al usuario.

IEs del árbol HS-DSCH: New Trans Rate: % de nuevas

transmisiones, o PDUs que se transmiten por 1ª vez.

Retrans. Rate: % de retransmisiones HSDPA, o PDUS que son retransmitidas. Las MAC-hs PDUS que lleguen con errores pueden ser retransmitidas hasta un máximo de 10 veces. (NOTA: En Huawei, lo tenemos configurado a 6). Si a la 6º vez, sigue estando mal el CRC, el paquete MAC-hs pasa a la capa RLC del terminal, y es esta capa la que pide la retransmisión, esta vez a la capa RLC de la RNC. Si esto ocurre, las retransmisiones en capa RLC serán distintas de cero y bajará el thp HSDPA.

Retrans. Rate = Retrans. No / (Retrans. No+ New Trans. No)

Phy. Thp (Served): Es el throughput medio real (incluyendo retransmisiones) que ve el terminal, considerando que no siempre está siendo servido por el scheduler del nodoB, es decir, considerando que no siempre los canales HS-SCCHs configurados llevan datos para él.

Phy. Thp (Scheduled): Es el throughput que el terminal recibiría si el scheduler le sirviera el 100% de los TTIs, o lo que es lo mismo, si siempre hubiera un HS-SCCH indicando que hay datos dirigidos a él. De este modo, hay una relación clara entre el thp served y el scheduled:

Phy. Thp Served = Phy. Thp. Scheduled * HS-SCCH Success Rate

El Thp scheduled guarda relación con la cantidad de Iub, potencia y códigos disponibles en el Nodo B. Si este valor es bajo, indica que en los TTIs en los que el usuario está siendo scheduleado el nodo B no llega a darle mucho thp por falta de recursos. El Thp scheduled guarda relación con el TB Size del árbol HS-SCCH Info :

Phy. Thp Scheduled = TB Size / TTI(2ms)

En ocasiones puede dar ligeramente superior al Iub disponible porque los datos dirigidos al usuario se almacenan en un buffer en el nodo B. Es posible que haya suficientes datos para mandar un TB Size grande, de modo que TB Size / 2ms sea superior al Iub. Pero en general, los Scheduled suelen ir a la par del número de E1s disponibles. Si es mucho menor de forma continuada pueden ocurrir dos cosas:

Mucho tráfico de R99 y faltan recursos (potencia, códigos o Iub, generalmente se trata del Iub, aunque hay que verificar los CQIs reportados para descartar potencia). Tendremos que verificar contadores en este caso.

Puede haber algún problema en capas superiores (RLC, TCP) de modo que se reduce el número de paquetes enviados al NodoB para ser transmitidos al terminal, es decir, no hay suficientes datos en buffer HSDPA para lograr thps altos.

DSCH BLER: Es muy similar al Retrans. Rate, a veces mayor y a veces menor, por lo que no está muy claro qué retransmisiones cuenta exactamente este IE.

IEs del árbol HS-DPCCH:

ACK Rate: % de ACKs, o de Pdus Mac-hs correctamente recibidas (con CRC correcto) durante el periodo de muestreo.

NACK Rate: % de NACKs, o de Pdus Mac-hs recibidas con errores (con CRC incorrecto) durante el periodo de muestreo.

DTX Rate: % de DTX, o de TTIs del periodo de muestreo en que los datos no iban dirigidos al usuario.

ACK Rate+NACK Rate+DTX Rate=100%

CQI: Valor CQI reportado por el terminal mayoritariamente durante el periodo de muestreo.

Average CQI: Valor CQI promediado en periodo de muestreo.Ave. Requested Physical Layer Rate: Es el thp al que tiene derecho el terminal según el CQI reportado. Es un dato que no proviene del nodo B, lo calcula XCAP en función de la tabla 3GPP de CQI vs. TBS.

IEs del árbol MAC Info:

MAC-hs throughput: Throughput en capa MAC-hs donde se descuentan las retransmisiones en capa física, entre nodo B y Terminal. Este throughput es el que se “entrega” a la capa RLC, quitándole las cabeceras MAC-hs y las cabeceras MAC-d. Es muy parecido al thp de Aplicación, siempre que las retransmisiones RLC sean nulas o casi nulas.

MAC-hs Throughput ≈ Physical Throughput Served * (1- HS-DSCH Retransmission rate)

Phy. Thp Served = Phy. Thp. Scheduled * HS-SCCH Success Rate

METODOLOGÍA ANÁLISIS

Para el análisis de un drive test de HSDPA se recomienda abrir una serie de pantallas básicas de señalización, y crearse unos templates que vienen explicados más abajo.

Los pasos serían:

1) Abrir las Estadísticas de la sesión de paquetes.2) Abrir la mensajería RRC (Logging message)3) Abrir los templates recomendados.4) Iniciar el análisis :

bien buscando los FTPs con menor throughput y sincronizando el resto de pantallas,

bien mirando las gráficas de throughput y buscando los comportamientos “anómalos”

INICIO: ESTADÍSTICAS DE LA SESIÓN DE PAQUETES

Indispensable para localizar los FTPs que han ido mal y sincronizar las gráficas, mapas, tablas etc., con cada uno de estos FTPs problemáticos.

Pestaña Message Statistics PS Call Statistics

LOGGING MESSAGE

Lo normal es que sólo nos haga falta la mensajería RRC y NAS, dejando filtrada la parte RLC.

Se recomienda, por tanto, este filtro (botón Show Filter Tree: )

La mensajería RRC y NAS nos permite consultar:

MBRs solicitados por el terminal (PDP Context Request) MBRs asignados por el Core (PDP Context Accept) RB establecida por la RNC (RB Setup):

o En general, este mensaje contiene un montón de información de la parametrización elegida para HSDPA, canales físicos, y canales de transporte.

o Importante consultar que se nos ha asignado un H-RNTI (indicador de que tenemos HSDPA)

o También en este mensaje se puede ver si nos cambia a f2 en un nodo con 2 frecuencias:

Cambios de R99 a HSDPA y viceversa (RB Reconfiguration)

Cambios de HSDPA Serving Cell (Physical Channel Reconfiguration): tener continuos cambios de servidor puede ser indicador de que la zona necesita optimización y perjudica el thp HSDPA con ligeras bajadas de 1s o 1.5s de duración.

CREACIÓN DE TEMPLATES DE ANÁLISIS

Para el análisis con XCAP es conveniente crearse unos templates en modo tabla, mapas, gráficos, etc. Y es una buena costumbre tenerlos todos abiertos antes de comenzar el drive test.

Para crear un template, por ejemplo, de una tabla, basta con crear la tabla en XCAP con los IEs que nos interesen, y una vez creada, nos posicionamos sobre ella con el cursor, botón dcho. Create Template y darle un nombre al Template.

Es recomendable preceder el template por la palabra indicando el modo de visualización, por ejemplo, “TABLA- RADIO CONDITIONS”, o “GRAPH- RETX RLC”, o “MAPA – BLOQUEOS & CAÍDAS”.

La próxima vez que analicemos un drive test es sencillo recuperar todos los templates sin más que abrirlos desde la pestaña Message:

TEMPLATES R99

Se da por conocidos los IEs existentes en el árbol Qualcomm, el cual cubre aspectos de R99, de modo que no vamos a explicar lo que significan. Tan sólo recordar que aunque las conexiones sean HSDPA y/o HSUPA en lo que a TRB se refiere, al terminal siempre le configura un canal R99 DPDCH+DPCCH que es el que lleva

la SRB (todos los mensajes RRC), por tanto, este árbol contiene información importante para el análisis.

Se recomienda crear los siguientes templates y tenerlos abiertos durante la sesión de análisis:

TABLA CONDICIONES RADIO

Esta tabla permitirá echar un vistazo rápido a las condiciones radio, valores RSCP y EcIo, potencia del terminal, BLER y estado del AS. Siempre hay que tenerla a mano:

IEs:

Qualcomm A/N Finger Info Active Set Combined RSCPQualcomm A/N Finger Info Active Set Combined Ec/IoQualcomm A/N Finger Info Active Set Enabled PSCQualcomm Power Info TX PowerQualcomm BLER Info BLER TotalQualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Active Set Active PSC CountQualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Active Set Active PSC ListQualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Monitored Set Monitored PSC ListQualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Detected Set Detected PSC List

MAPA DE BEST SERVER

IE:

Qualcomm A/N Finger Info Active Set Enabled PSC

Es mejor eliminar la leyenda: pulsar sobre el mapa con el botón derecho :

Configure desmarcar Toggle Legend

Y también puede resultar interesante ver los SCs en modo numérico:

Configure Draw Text

GRÁFICA CAPA RLC

Esta gráfica es interesante cuando se analizan paquetes, pero no en todos los drive test se guarda información de esta capa mediante la máscara. Permite ver si a nivel de capa RLC hay problemas de excesivas retransmisiones y si se producen pérdidas de planos de usuario (aunque las pérdidas de usuarios es mejor consultarlas en la mensajería RLC).

Es importante porque los problemas de datos HSPA en ocasiones son originados en esta capa, con lo cual dejan de entenderse la RNC y el UE, mientras que a nivel de capa física y MAC-hs, MAC-e (en el nodo B) está todo bien.

Los problemas de capa RLC no provocados por un problema en capa física suelen ser problemas de producto o del terminal.

IEs:

Qualcomm RLC Info DL Throughput Qualcomm RLC Info UL Throughput Qualcomm RLC Info RLC DL Retxd

Qualcomm RLC Info RLC UL Retxd

Por ejemplo, abajo vemos que en los 2 FTPs destacados en rojo, las retransmisiones RLC DL están muy altas, cuando deberían tender a 0 dado que es HSDPA. Habría que revisar si la capa Física, CQI y demás, están mal y esa es la causa.

En la gráfica ejemplo, los FTPs señalados en rojo tienen peor throughput de capa RLC (el más parecido al throughput de aplicación) y excesivas retransmisiones RLC UL y DL. Las retransmisiones DL en HSDPA para la capa RLC deben tender a 0. Habría que echar un vistazo en este caso a la capa MAC-hs para ver si las retransmisiones RLC son consecuencia de un número alto de retransmisiones en capa MAC-hs (la capa anterior) o no. Quien quiera entretenerse con la capa RLC puede habilitar estos mensajes en la vista de mensajes, pero es una capa muy complicada:

Message Logging Message , o bien con el botón

Y habilitar mensajes (PDU) de capa RLC con el filtro:

TEMPLATES HSDPA

MAPA EVENTOS FTP

Para tener una visualización gráfica de dónde han terminado correctamente los FTPs y dónde han fallado, se recomienda abrir este mapa:

Event FTP Call Event

Hacer doble clic sobre la leyenda y dejar sólo marcadas los siguientes eventos:

Se obtiene el siguiente mapa de eventos:

GRÁFICA INFORMACIÓN HSDPA

IEs:

Throughput Info APP FWD Throughput Qualcomm HSDPA MAC Info MAC-hs ThroughputQualcomm HSDPA HS-DPCCH Info CQIQualcomm HSDPA HS-DSCH Info Phy. Throughput(Served)Qualcomm HSDPA HS-DSCH Info Phy. Throughput(Scheduled)Qualcomm HSDPA HS-DSCH Info Retransmission Rate (%)Qualcomm HSDPA HS-SSCH Info Success RateQualcomm HSDPA HS-SSCH Info Nr. Of codesQualcomm A/N Finger Info Active Set Enabled PSCQualcomm RLC Info Downlink Retransmissions

Se pueden sacar otros muchos datos de HSDPA, pero quizás estos sean los más relevantes para ver problemas.

CRITERIOS ANÁLISIS Y DIAGNÓSTICO

Lo deseable sería conseguir estos valores (valores peores no significan que no podamos dar 1.6Mbps, son referencias a puntos de medidas en los que el Thp HSDPA alcanzado ha ido muy bien):

CQI >= 24 Optimiza el uso del PA. HS-SCCH success rate > 50% Retransmisiones HS-DSCH < 20% Códigos > 8 Phy. Thp. Scheduled > 4500 kbps.

Las acciones recomendadas para conseguir estos valores son:

CQIs bajos Optimización downtilts/orientaciones de la zona. Revisión de vecinas.

Bajos HS-SCCH success rate + Bajos Scheduled : Contadores, ver uso de recursos potencia, Iub y códigos del nodo. Suele ser Iub. OJO: Puede ser que no haya datos en buffer por problemas en capas superiores. Ver anexo.

Bajos HS-SCCH success rate + Alto Scheduled : Contadores, revisar número de usuarios y tráfico HSDPA en celda. Revisar el uso de códigos y potencia. Es posible que sea necesaria una f2.

Códigos anormalmente bajos : Revisar MBR de la conexión. Revisar tráfico de R99 de la celda. Revisar parametrización HSDPA de la celda por si hay errores.

Ejemplo:

Hay un cambio de best Server a mitad FTP. Se debe revisar los contadores de Iub, potencia y códigos de esta celda dado que el scheduled thp baja considerablemente. Además también vemos que los CQIs no son buenos, por lo que convendría realizar un scanner de la zona para optimizar sistemas radiantes. Ver anexo.

ANEXO

UTILIDADES SCANNER

Se recomienda realizar el análisis del scanner previo al análisis de cualquier drive test, bien sea de voz o datos, HSPA o R99. Muchas veces, si se entiende la calidad de la cobertura radio que estamos dando en una población, cluster, etc., se entienden muchos de los problemas que aparecen después en el drive test en dedicado.

DETECCIÓN DE CABLES CRUZADOS

Modo Mapa:

PSC Scanner DTI FA (10713) Top SC Top 1 SC

Es útil esconder la leyenda: botón dcho sobre el mapa: Configure Toggle Legend1Es útil representar los SCs sobre mapa en valores numéricos: botón dcho sobre el mapa: Configure Draw Text for Legend1.

POLUCIÓN DE PILOTOS

Podemos hacer el análisis de polución de pilotos de dos formas, por RSCP y por Ec/Io.

POR RSCP

Modo Mapa:

PSC Scanner DTI FA (10713) SC Pollution Diff & Threshold New

Con estos settings estamos sacando las zonas donde se reciben más de 1 piloto con RSCP > -90 dBm, y de modo que estos RSCPs se diferencian en 5 o menos de 5 dB.

Nos saldrán dos cálculos; Count y List. Si representamos en el mapa el campo “Count”, la leyenda nos dice el porcentaje de muestras donde hay 6 o más pilotos en esas condiciones, donde hay 5, donde hay 4, etc.

Dado que el AS es de tamaño máximo 3, si hacemos doble clic sobre la leyenda, y desmarcamos las muestras de 1,2 y 3 pilotos, se nos quedan las zonas más polucionadas por RSCP.

Zonas polucionadas (según el recorrido del DT, ojo):

Para ver quienes son los pilotos que llegan a estas zonas, abrimos en modo Tabla:

PSC Scanner DTI FA (10713) SC Pollution Diif & Threshold under 5.00 dB & above -90.00dBm List y Count.

En el mapa, doble click sobre las zonas polucionadas, y consultamos en la tabla de qué pilotos se trata. Debemos decidir qué pilotos no queremos que nos lleguen a esa zona añadiendo downtilt.

POR EcIo

Modo Mapa:

PSC Scanner DTI FA (10713) SC Pollution Diif & Threshold New:

Buscamos zonas donde hay más de un piloto en condiciones de entrar en AS (4dBs de diferencia de EcIo respecto a la best Server). El mínimo EcIo que deben tener los pilotos para ser considerados es -15dB.

Es conveniente antes de decidir inclinar una antena con este método comprobar lo que está cubriendo cada uno de sus sectores, ver punto 1.3.

COBERTURA DE CELDA/SOBREALCANCES

Identificamos el SC de la celda cuyo alcance queremos analizar, por ejemplo, 432 (3001CS1_01):

Modo Mapa:

PSC Scanner DTI FA (10713) SC SC 432 RSCP

Es recomendable cambiar la leyenda de RSCP aumentando el rango de valores que por

defecto nos da XCAP. Para ello, abrir Map Setting con el Botón de la barra de herramientas y configurar el número de rangos y los colores que queramos, por ejemplo con esta propuesta:

Podemos ver que el sector 1 del 3001CS llega demasiado lejos, cubriendo mejor a más distancia del nodo que cerca, necesita downtilt. Probablemente esto confirme lo que hayamos visto en el análisis de polución de pilotos y en el plot de best Server.

UTILIDADES RAMA “QUALCOMM” (R99)

Antes de entrar en el análisis propiamente dicho de lo ocurrido en el DT, es decir, de las sesiones de voz o datos, es interesante realizar la detección de vecinas sin definir de la rama Qualcomm de XCAP y quedarnos con la idea de la zona geográfica donde han ocurrido estos problemas.

DETECCIÓN DE VECINAS SIN DEFINIR

En modo Tabla abrir:

Qualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Finding Missing Neighbours

Hay que rellenar la condición para que XCAP “entienda” qué significa para el operador que una celda deba ser vecina de otra.

Proponemos estos settings:

Es decir, una celda deberá ser vecina de otra si su Ec/Io es mayor que -15 dB y se diferencia de la celda dominante del AS en 4 dBs o menos de 4dB, durante al menos 2 segundos consecutivos. XCAP nos dará como resultado la lista de celdas que cumplen esta condición y que no estaban listadas en el Measurement Control con la lista de vecinas Intrafreq vigente en ese momento.

Por supuesto, se pueden probar otras opciones más o menos restrictivas a ver qué sale.

El resultado en el árbol de desglose tiene esta pinta:

Se interpreta como sigue: “Siendo best Server en el AS el SC40, se detecta como vecina no definida el SC280”, etc…

Para representarlo, se recomienda abrir dos vistas (incluyendo todos los ADSC en una sola vista):

1- Modo mapa: Qualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Finding Missing Neighbours Ejemplo vecinas missing ADSC40 MNSC 280

2- Modo Tabla: Qualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT Finding Missing Neighbours Ejemplo vecinas missing ADSC40 MNSC 280

El modo mapa nos da una idea de si la vecina es necesaria allá donde se detecta, o bien se trata de un sobrealcance que hay que corregir. También complementa lo visto en el scanner para tener una idea más clara de los problemas radio que hay en el cluster medido.

La tabla nos da una idea de lo “insistente” (necesaria) que es esta vecina no definida y del EcIo que presentaba al ser detectada. Por ejemplo, en esta tabla se ve que durante 8,7 y 3 segundos seguidos se ha detectado la celda SC26 cuando la best Server era la SC50. Los EcIo son malos, pero no hay que olvidar que la condición de que entren en esta lista es que sus EcIOs se lleven 4dBs de diferencia a lo sumo, por tanto, en esta zona, el SC50 tampoco está bien y definir estas vecinas puede salvar caídas.

También podemos revisar el RSCP de la vecina no definida para saber con qué nivel de señal está llegando.

Por ej. Para la vecina no definida SC280:

Qualcomm Pilot Ser Ver. 3 (List Search) Pri_ANT All Set RSCP PSC 280

Ojo: en ocasiones XCAP nos reportará vecinas como no definidas, cuando realmente sí lo están. Esto se debe a que desde que se recibe un “AS update” hasta que se recibe el “Measurement Control” modificando la lista de vecinas, pasa un tiempo. Si durante este tiempo se detecta una vecina que no está en la lista vigente, XCAP la reportará como no definida, aunque realmente lo que ocurre es que el terminal y XCAP aún no han actualizado la nueva lista.

REVISIÓN CAPA TCP

En ocasiones podemos ver nodos que funcionan correctamente, pero algún FTP tiene un thp anormalmente bajo sin ninguna explicación radio (retransmisiones en capa física bien, retransmisiones en capa RLC bien). Podemos consultar la siguiente ventana para ver si se están produciendo ACKs selectivos a nivel TCP, o SACKs.

Cuando son muy numerosos, indican pérdidas de paquetes TCP, y este protocolo interpreta que hay congestión en la red de transporte, routers, etc. y reacciona reduciendo el tamaño de las ventanas de transmisión y con ellas, el throughput. Si llegan pocos paquetes TCP, en HSDPA veremos HS-SCCH success rates muy bajas (del orden del 20%) y scheduled Thps también muy bajos (menores que el Mbps, incluso del orden de valores de R99).

La capa TCP se abre mediante el botón Packet message.