Драйв-тест в 3G сети! — Общие вопросы, касающиеся принципов работы UMTS-сетей

[orcinus_orca]

Подскажте, пожалуйста, какие параметры нужно анализировать при драйвтесте 3G сети. Сколько телефонов должно быть и в каком режиме они должны работать?
Что должно фигурировать в отчете - какие слайды и таблицы.
Может у кого есть пример отчета или требований - не поленитесь и скините на мыло: dentuso@tut.by

[Samara-Mobile.ru]

Более года я профессионально провожу драйв-тесты и бенчмаркинги сетей UMTS в Поволжье. Вот что содержат мои отчёты по 3G:

1) Условия проведения тестирования
Срок проведения тестирования
Объект тестирования
Время тестирования: световой день
Расположение антенн: внутри автомобиля
Средняя скорость движения автомобиля по городу: 50 км/час
Средняя скорость движения автомобиля по трассам: 100 км/час
Оборудование тестирования: Symphony (6MS) + QVS
Схема тестирования: к трём операторам подключены по две мобильные станции, одна из которых из которых тестирует услуги голосовой телефонии (вызовы с голосового сервера длительностью 120 секунд, пауза между вызовами - 10 секунд), а одна - услуги передачи данных (схема тестирования: Ping (www.yandex.ru) - HTTP (www.litres.ru) - FTP DL 5Mb (ftp://xxxxxxx.ru) - FTP UL 3Mb (ftp://xxxxxxx.overflow.ru))

2) Графическое отображение схемы тестирования, из которой видно какие модели телефонов использовались, что на что звонили/качали данные, какие телефонные номера использовались и т.д.


3) Потом идут общие выводы по результатм бенчмаркинга (для тех, у кого не хватает времени/желания читать весь отчёт с таблицами, графиками и рисунками)


4) Потом - большой раздел по бенчмаркингу телефонии

4.1) Таблица "Общие данные по тестируемым сетям":
число выявленных LAC
число выявленных RAC
число выявленных UMTS_sites
число выявленных UMTS_CID


4.2) Таблица "Общие показатели качества услуг телефонии":
CSSR (процент успешно установленных вызовов) %
CDR (процент вызовов, оборванных не по инициативе абонента) %
Среднее время установления вызова (сек.)
avg Speech Quality (AscomClass) (среднее значение оценки качества передаваемого голоса)
avg Speech Quality (MOS) (среднее значение оценки качества передаваемого голоса)
avg Speech Quality (PESQ) (среднее значение оценки качества передаваемого голоса)


4.3) Таблица и диаграмма "Распределение (в %) качества передаваемого голоса (AscomClass DL+UL)"


4.4) Таблица "Общие показатели качества услуг видеотелефонии":
avg videoMOS
avg Jerkiness
avg Blockiness
avg Blurriness
avg Contrast
avg FrameRate
avg FrameFreeze
avg FrameSckip


4.5) Таблица и диаграмма "Распределение (в %) качества видеозвонка (videoMOS)"


4.6) Таблица и диаграмма "Распределение (в %) Received Signal Code Power (RSCP)":

менее -115 dBm (отсутствие радиопокрытия)
-115 ч -110 dBm (неустойчивый приём на улице)
-110 ч -95 dBm (устойчивый приём на улице в открытом месте)
-95 ч -85 dBm (устойчивый приём в транспорте)
-85 ч -75 dBm (устойчивый приём в помещениях)
более -75 dBm (устойчивый приём в зданиях на первых этажах)


4.7) Таблица и диаграмма "Распределение (в %) Received Signal Strenght Indication (RSSI)":

менее -115 dBm (отсутствие радиопокрытия)
-115 ч -110 dBm (неустойчивый приём на улице)
-110 ч -95 dBm (устойчивый приём на улице в открытом месте)
-95 ч -85 dBm (устойчивый приём в транспорте)
-85 ч -75 dBm (устойчивый приём в помещениях)
более -75 dBm (устойчивый приём в зданиях на первых этажах)


4. Таблица и диаграмма "Распределение (в %) значений Ec/Io (интерференции):"

более -6 dB (отлично)
-6 ч -9 dB (хорошо)
-9 ч -12 dB (удовлетворительно)
-12 ч -15 dB (плохо)
менее -15 dB (очень плохо)


4.9) Таблица и диаграмма "Распределение (в %) голосовых кодеков AMR-DL (kbps):"


4.10) Таблица и диаграмма "Распределение (в %) голосовых кодеков AMR-UL (kbps):"


4.11) Диаграмма "Преобладание в радиопокрытии (по параметру RSSI):"


4.12) Диаграмма "Преобладание в радиопокрытии (по параметру RSCP):"


4.13) Диаграмма "Преобладание в качестве голоса (по параметру AscomClass):"


4.14) Диаграмма "Преобладание в скорости приёма данных по FTP-DL:"


4.15) Диаграмма "Преобладание в скорости передачи данных по FTP-UL:"


4.16) Таблица и диаграмма "Распределение (в %) искажений Jerkiness при видеозвонках:"


4.16) Таблица и диаграмма "Распределение (в %) искажений Blurriness при видеозвонках:"


4.16) Таблица и диаграмма "Распределение (в %) искажений Blockiness при видеозвонках:"



5) Большой раздел по бенчмаркингу услуг передачи данных

5.1) Таблица "Общие показатели качества предоставляемых услуг передачи данных:"

max FTP DL throughput (максимальная скорость закачки файла по FTP DL) kbps
max FTP UL throughput (максимальная скорость закачки файла по FTP UL) kbps
avg FTP DL throughput (средняя скорость закачки файла по FTP DL) kbps
avg FTP UL throughput (средняя скорость закачки файла по FTP UL) kbps
avg Ping Delay (среднее время задержки пинга) сек.
Ping success (успешное прохождение пингов и пинги с задержкой менее трёх секунд) %
Avg HTTP download time (среднее время закачки HTML-страницы) сек.
avg HTTP throughput (средняя скорость закачки HTML-страницы объёмом примерно 250kB) kbps
HTTP download success (успешность закачки HTML-страницы) %


5.2) Таблица и диаграмма "Распределение скорости закачки данных по FTP-соединению (kbps) на DL" и таблица и диаграмма "Распределение скорости закачки данных по FTP-соединению (kbps) на UL"


5.3) Таблица и диаграмма "Распределение значений Ping Delay (сек.)"

5.4) Таблица и диаграмма "Распределение типов модуляции:"


6) Рисунки (на формате А3) распределения AscomClass, RSSI, RSCP, Ec/Io, скоростей на FTP_DL, скоростоей наFTP_UL каждого из оператора связи на рассматриваемой территории
7) Рисунки преобладаний по: радиопокрытию (RSSI, RSCP), качеству голоса (AscomClass), скоростям передачи данных (FTP_DL throughput, FTP_DL throughput)

И ещё: все параметры, которые присутствуют в отчётах, созраняются в виде МапИнфошных слоёв. Отдельно по "своей" сети делаются слои с BTS_Lines и ServingLines (т.е. привязкой межементпоинтов к севрирующим секторам - ОЧЕНЬ нужная фича для определения перепутанных секторов и получения данных по направленям/площади реального сервирования каждого сектора).

З.Ы. пример отчёта прислать не могу по понятным причинам

[Алексей Березин]

У меня средние скорости движения по мегаполисам получаются порядка 25 км/ч, а вот в ночные объезды и правда около 50.
Средняя скорость по трассам в 100 км/ч - это самоубийство. Себя не жалко, так о других участниках движения подумай! При крейсерных 90 и пиковых 120...130 на обгонах все равно средняя скорость получается порядка 75...80. Что бы получить среднюю СОТКУ - это без башни нужно быть.


От объема DL файлов объемом около 5 МБ я отказываюсь для оценки скоростей - становится непрезентабельно при нынешних скоростях.

[Samara-Mobile.ru]

У меня средние скорости движения по мегаполисам получаются порядка 25 км/ч, а вот в ночные объезды и правда около 50.

К сожалению, приходится ехать в общем потоке... 25 км/ч никак не получается... Да и потом, при такой скорости (в 25 км/ч) объезд города затянется с недели до двух-трёх, а время командировки - ограничено.

Средняя скорость по трассам в 100 км/ч - это самоубийство. Себя не жалко, так о других участниках движения подумай!

У меня забота - чтобы железо работало. О безопасности дорожного движения думает водитель. И, потом, проехать за световой день 600-700 км на меньшей скорости - невозможно.

От объема DL файлов объемом около 5 МБ я отказываюсь для оценки скоростей - становится непрезентабельно при нынешних скоростях.

Не совсем понятно: Вы считаете пятимегабайтный файл для тестирования скорости загрузки по даунлинку - это мало или много?

[Алексей Березин]

У меня средние скорости движения по мегаполисам получаются порядка 25 км/ч, а вот в ночные объезды и правда около 50.

К сожалению, приходится ехать в общем потоке... 25 км/ч никак не получается... Да и потом, при такой скорости (в 25 км/ч) объезд города затянется с недели до двух-трёх, а время командировки - ограничено.

Средняя скорость по трассам в 100 км/ч - это самоубийство. Себя не жалко, так о других участниках движения подумай!

У меня забота - чтобы железо работало. О безопасности дорожного движения думает водитель. И, потом, проехать за световой день 600-700 км на меньшей скорости - невозможно.

Можно подумать, я на летающей тарелке циркулирую. Все только разумеющиеся факты...
Так вот, как я понял, речь идет о средней скорости, а она извлекается из статистики, как и все остальные парамтры...
При движении со скоростью X средняя никогда не будет X, собственно, аналогично и со скоростями загрузки данных в т.ч. и за сессию.

От объема DL файлов объемом около 5 МБ я отказываюсь для оценки скоростей - становится непрезентабельно при нынешних скоростях.

Не совсем понятно: Вы считаете пятимегабайтный файл для тестирования скорости загрузки по даунлинку - это мало или много?
[/quote]

Уже мало. Уже склоняюсь к необходимости применения двух устройств на каждого оператора: одно на события (успешность), другое на скрости (загрузка большого файла) + разумеется SPICH Scan RSCP хотя бы для порядка веще и детального разбора полета в случае наобходимости.

[orcinus_orca]

Спасибо за подробный отчет.
Есть только пара вопросов:
1. Вы тестируете: ping -> Upload -> Download. Не разумней ли использовать две мобилки: одна пинг - PDP success Rate, а вторая для скорости измерения закачки?
2. Если сначала скачивать данные, а потом закачивать не получится ли та, что скачали в одной соте, а закачали в другой. К тому же скорость закачки 64kbps, поэтому можно уехать в другой сайт? Данные получаются не совсем корректными.
3. Надо ли тестить HSDPA/HSUPA или достаточно при приемке сайта? Ведь он в двиижении не работает?
4. Можно поподробнее по поводу качества голоса? Можно ли анализировать сеть по RxQuality или SQI?
5. Каковы брать пороги для Call Setup Success Rate, Duration of Call Establishment, PDP 384kbps DL throughput and PDP UL Throughput.

[Samara-Mobile.ru]

Так вот, как я понял, речь идет о средней скорости, а она извлекается из статистики, как и все остальные парамтры...

Вот это - единственный параметр, который определяется "на глазок" Не, можно и из логов вытащить значения, но надо ли..?

Уже мало.

Не согласен. Во-первых, кроме тестирования FTP-DL есть и другие задачи (пинги, загрузка HTML-страницы и тестирование FTP-UL). Да и само тестирование происходит во время движения. Поэтому долгое тестирование FTP-DL пойдёт во вред всему тестированию услуг передачи данных.
Во-вторых, нужно же ещё протестировать GPRS-Attach. Поэтому тут нужно выбрать нужное соотношение между длительностью тестирования каждой задачи и тестированием аттачей, детачей и т.п.

Уже склоняюсь к необходимости применения двух устройств на каждого оператора: одно на события (успешность), другое на скрости (загрузка большого файла) + разумеется SPICH Scan RSCP хотя бы для порядка веще и детального разбора полета в случае наобходимости.

В идеале, под каждую задачу нужно выделять свой девайс. Но это - из области фантастики

[Samara-Mobile.ru]

1. Вы тестируете: ping -> Upload -> Download. Не разумней ли использовать две мобилки: одна пинг - PDP success Rate, а вторая для скорости измерения закачки?

Повторюсь: в идеале под каждую задачу нужно выделять отдельную моблю, тестировать - остановившись хотя бы на пол-часа в зоне действия каждого CID. На практике такое никогда не получится (из-за отсутствия технической оснащённости измерительного оборудования и ограничения времени тестирования)

2. Если сначала скачивать данные, а потом закачивать не получится ли та, что скачали в одной соте, а закачали в другой. К тому же скорость закачки 64kbps, поэтому можно уехать в другой сайт? Данные получаются не совсем корректными.

Естественно, что на практике так и получается: начинается тестирование в одном CID, а заканчивается - в другом (третьем/четвёртом). Но:
а) скорости по каждому CID можно и из статистики выковырять
б) с точки зрения работы реальных абонентов (которые чатятся, интернет-серфингируют, получают мыло и т.п., находясь в маршрутке, метро, электричке, машине и т.д.) мы, драйв-тестеры, полностью восстаздаём реальную ситуацию с точки зрения пользователя мобильного интернета.

3. Надо ли тестить HSDPA/HSUPA или достаточно при приемке сайта? Ведь он в двиижении не работает?

Это как это HSDPA в движении не работает?
Про HSUPA ничего пока сказать не могу - у нас в Поволжье его пока ни у кого нет.

4. Можно поподробнее по поводу качества голоса? Можно ли анализировать сеть по RxQuality или SQI?

Примерно оценить качество голоса по этим параметрам можно. Но правильнее - пользоваться специально для этого разработанными методиками и стандартизированными параметрами (PESQ, MOS и т.д.)

5. Каковы брать пороги для Call Setup Success Rate, Duration of Call Establishment, PDP 384kbps DL throughput and PDP UL Throughput.

А это - как установит Ваше руководство

[Алексей Березин]

Кстати, а как с объемами логов?
В ТЕМСе один модем (или телефон в режиме модема) дует логи, как 5 телефонов в режиме разговора. Соответственно, при работе 4 модемов получаются уж совсем гигантские объемы. Я даже отключаю авторазбивалку логов, ибо 100000 событий получается мало, а разбиваю вручную по 500000...750000.

3. Надо ли тестить HSDPA/HSUPA или достаточно при приемке сайта? Ведь он в двиижении не работает?

Все замечательно работает. И HSDPA, и HSUPA.

Вот, с Ev-Do не так все гладко, вероятно, по причине TDMA структуры.

[Samara-Mobile.ru]

Кстати, а как с объемами логов?

У измерительного оборудования Ascom лог-файлы получаются на порядок меньше, чем у TEMS-a. Поэтому общий объём логов за 8-часовое непрерывное тестирование шестью мобилами (три - голос, три - данные) - примерно 300 мегабайт.

[Алексей Березин]

У меня 4.5 Гига за часов 20 чистого времени теста при трех модемах + сканер. Но сканер не дует логи, по сути минимально раздуваемое логи устройство.