Обработка и анализ UETR файлов — Общие вопросы, касающиеся принципов работы UMTS-сетей

[rusbloke]

Всем доброго времени суток.

Поиском ничего похожего не нашел, вот и решил создать тему.

Вобщем, интересует кто как анализирует UETR и CTR? Какие параметры? (например, различные измерения rrc и nbap measurement reports, или там события какие). Перечитал уже вдоль и поперек Ralf Kreher "Performance Measurements", эрекссоновские доки по теме и техспецификации 3gpp. Но вопросы, впрочем, остались.

Tак и не понял почему в файле так много записей CONNECTION. В доках сказано, что CONNECTION означает добавление/удаление UE из сканера (т.е. переход UE из idle в dedicated, или обратно). Если я, скажем, сижу с 3g-модема и качаю непрерывно 24 часа, будет не две записи CONNECTION Status 0 (во время подключения) и CONNECTION Status 1 (отключение модема), а намного-много больше. Может это как-то связано с постоянными переходами wcdma->hsdpa и наоборот. Вобщем, хз. Кто поделится толковым объяснением, буду очень признателен.

И еще. Какой тип экспортированных файлов обрабатываете: .bin.gz или .tab?

ЗЫ. Хотел как-то покороче написать...=)
Кто вобще не понял о чем речь: в 3g после трейсинга imsi получается файл uetr (user equipment trace recording). О нем и идет речь выше.

[rusbloke]

блин, ну неужели никто не занимается трейсингом абонентов в umts?

[Danikd]

блин, ну неужели никто не занимается трейсингом абонентов в umts?

Обычно занимаются трэйсом сетевых элементов через GPEH.

UETR это один из вариантов такого трейса но с привязкой к IMSI.

Теперь вопрос - а что именно интересует в этих трейсах? и с какой целью вы их хотите обрабатывать?

Обычно эти трейсы содержат запись информации с протоколов Iub, Iu и RNC _Internal.
Информации много и использовать ее можно по многим направлениям.

Спрашивайте более детально, поможем))))

[rusbloke]

Теперь вопрос - а что именно интересует в этих трейсах? и с какой целью вы их хотите обрабатывать?

Ну, вроде как понятно, что не ради праздного любопытства.

Обычно эти трейсы содержат запись информации с протоколов Iub, Iu и RNC _Internal.

да,да,да, а еще Iur и Uu...

Информации много и использовать ее можно по многим направлениям.

Например?

Спрашивайте более детально, поможем))))

Вопрос по количеству записей CONNECTION я уже задал.

Кто-нибудь вобще пробовал разбирать данный файл самостоятельно ручками, без использования, скажем, TEMS Investigation?

[Danikd]

Теперь вопрос - а что именно интересует в этих трейсах? и с какой целью вы их хотите обрабатывать?

Ну, вроде как понятно, что не ради праздного любопытства.

Обычно эти трейсы содержат запись информации с протоколов Iub, Iu и RNC _Internal.

да,да,да, а еще Iur и Uu...

Информации много и использовать ее можно по многим направлениям.

Например?

Спрашивайте более детально, поможем))))

Вопрос по количеству записей CONNECTION я уже задал.

Кто-нибудь вобще пробовал разбирать данный файл самостоятельно ручками, без использования, скажем, TEMS Investigation?

Структура файлов GPEH во всех деталях описана в документации /// в документе с индексом 104/1551-AXD 105 03/1 Uen D1

более сложная проблема с ивентами с интерфейсов их содержание кодируется с схеме ASN1.PER и для их декодирования нужна полная структура кодирования по 3GPP. (The "Protocol id" represented as: 0=RRC "3GPP TS 25.331 V7.7.0", 1=NBAP "3GPP TS 25.433 V7.7.0", 2=RANAP "3GPP TS 25.413 V7.8.0", or 4=RNSAP "3GPP TS 25.423 V7.7.0", 5=INTERNAL_EVENT (RNC internal protocol ID including RNC internal events and RNC internal measurements), 6=PCAP "3GPP TS 25.453 V7.6.0" or 7=SABP "3GPP TS 25.419 V6.2.0)

разобрать файл GPEH дело не сложное, вопрос в другом....что с этим делать...с содержимым

Насчет CONNECTION что-то непонятнен вопрос.....если на IMSI сделать UETR то все его ивенты будут собраны в GPEH файл.
переходы из Idle в Connected (FACH), с FACH на DCH и обратно полностью отражаются в RRC протоколе....так что не ясен вопрос.....точнее выражайтесь....коллега......

[Danikd]

Теперь вопрос - а что именно интересует в этих трейсах? и с какой целью вы их хотите обрабатывать?

Ну, вроде как понятно, что не ради праздного любопытства.

Обычно эти трейсы содержат запись информации с протоколов Iub, Iu и RNC _Internal.

да,да,да, а еще Iur и Uu...

Информации много и использовать ее можно по многим направлениям.

Например?

Спрашивайте более детально, поможем))))

Вопрос по количеству записей CONNECTION я уже задал.

Кто-нибудь вобще пробовал разбирать данный файл самостоятельно ручками, без использования, скажем, TEMS Investigation?

Еще важное замечание UETR - это Ue Traffic Recording (часто путают со словом TRACE), другими словами сбор информации ведется только при наличии RRC connection, не всех возможных транзакций определенного Ue (Paging, Random Access and etc.).
При интерактивном скачивании, тоесть использование протоколов HTTP , FTP и других похожих, возможны задержки и перерывы в передаче данных а это в свою очередь ведет к прекращению RRC connection и переходе в FACH или IDLE режимы....зависит от типов аппликаций и продолжительности перерывов.
UETR начинает сбор данных только после аллокации и занятия DCH под передачу данных HS или R99 и завершает сбор при освобождении DCH.
Так что наличие многих Connections видимо говорит о частых переходах из RRC в FACH или IDLE.

[srg21]

Кто-нибудь вобще пробовал разбирать данный файл самостоятельно ручками, без использования, скажем, TEMS Investigation?

Можно по подробнее. Как скормить логи UETR -> TEMS Investigation ?

[Danikd]

Кто-нибудь вобще пробовал разбирать данный файл самостоятельно ручками, без использования, скажем, TEMS Investigation?

Можно по подробнее. Как скормить логи UETR -> TEMS Investigation ?

Гиблое дело.....часами он это кушает и вешается....лучше спрашивайте у других....кто умеет GPEH файлы обрабатывать....

[avamarkov]

На самом деле GPEH это просто кладезь различной информации по тому что у тебя в WCDMA творится. Теперь по порядку, читать его есть много разных способов, т.е. прог, сам сейчас работаю с Actix Analyzer с фичей для чтения GPEH(все законно лицензионно, ломаного такого чуда пока не видел))), и пробовал в трайл Tems Presentation с данной фичей. Если сравнивать эти софты, то актикс это как конструктор из которого можно собрать от лопаты до самолета, все есть, все сообщения видны, если разбираешься в query и сути wcdma то можешь создать любой отчет, есть уже предустановленные запросы, но!!! закрытые для просмотра конструктором, поэтому списать текст запроса неоткуда, но разобраться можно. А темс это как лопата, можно только копать))), все просто и только предустановленные задачи, штук 5-6, типа оптимизация соседей и т.п. в общем очень скудный набор, но для реальной работы хватит. Есть еще Actix One, так он еще может осуществлять т.н. геолокацию, т.е. по измерениям GPEH и знанию географии родной сети и родного края показывает достаточно точно где произошло то или иное событие. очень интересная штука. Есть еще всякие менторы, оптимы, которы автоматом оптимизируют сети по анализу GPEH. То же интересные вещи. Но все же самое интересное это конечно актикс аналайзер. Вытащить от туда можно наверно все что угодно. например последнее что делал, это на каких дальностях кто с какого сектора работает(бывает и до 50 км)))), и сколько например в сети мобил поддерживающих UMTS900. И по слухам, некоторые европейские операторы даже думают отказаться от драйв-тестов wcdma сетей и заменить все это на глубокий анализ GPEH...Теперь про чтение вручную GPEH. это конечно можно, перекодировать в OSS из .bin в .txt или .tab и открыть в блокноте... в общем то полный аналог актиксовского браузера сообщений, но видимо не зря все это хозяйство у того же актикса стоит так дорого, главное это распарсить и в базу влить)))

[srg21]

Всё к этому и идёт. TEMS автоматик + анализ GPEH и человек который делает тесты скоро будет не нужен. Как минимум в городах на сети WCDMA. К счастью руководители наши пока этого не понимают, а то давно всех драйв-тестёров уже разогнали.

[Samara-Mobile.ru]

Всё к этому и идёт. TEMS автоматик + анализ GPEH и человек который делает тесты скоро будет не нужен. Как минимум в городах на сети WCDMA. К счастью руководители наши пока этого не понимают, а то давно всех драйв-тестёров уже разогнали.

Ню-ню... Стоимость одного девайса TEMS_Avtomatic перекрывает годовую зарплату драйв-тестера... А для города таких девайсов нужно штук пятьдесять. Во-вторых, Автоматики не ездят там, ГДЕ НУЖНО для выявления проблем. Ну, а в-третьих, это - идиотская мечта финансиста: ему невдомёк, что ни одна программа не заменит работу человека, особенно там, где надо думать. Даже если уволят всех драйв-тестеров, то кто будет анализировать логи хитропопых программ? ;-D

[srnd]

у Е/// для анализа gpeh/uetr/ctr вроде tems visualization предназначен. использую его. жаль только что позиционирования нет, а так хорошая вещь.

[udsv]

у Е/// для анализа gpeh/uetr/ctr вроде tems visualization предназначен. использую его. жаль только что позиционирования нет, а так хорошая вещь.

А получается несколько 15минуток склеивать? А то у нас на этой фазе замерзал и умирал.
Так то конечно ничего, прикольный - но тормоз.

[Danikd]

у Е/// для анализа gpeh/uetr/ctr вроде tems visualization предназначен. использую его. жаль только что позиционирования нет, а так хорошая вещь.

А получается несколько 15минуток склеивать? А то у нас на этой фазе замерзал и умирал.
Так то конечно ничего, прикольный - но тормоз.

Точно точно.....тормоз он сильный....с большим объемом данных просто вешается.....

[srnd]

из последних самое большое было 3427 файлов за 1 раз. общий объем 451М. 20100821.0745 первый и 20100823.0745 последний. парсилось наверное часа 3-4.
запросы обрабатывал конечно долго, может минуту, может две. но этой инфы по другому не получть, так что я ему это прощаю.