Как считать "TCH Congestion Rate" на Ericssone? — Общие вопросы, касающиеся принципов работы GSM-сетей

[orcinus_orca]

Это TCH Block Rate.
Но согласен - это лучше чем ничего и можно ко всеи вендорам применять.

[Danikd]

Всем привет.
Возник вопрос как правильно считать "TCH congestion rate" на оборудование - Ericsson.
Я нашел две формулы:

Subscriber Perceived TCH Congestion Rate = 100 * (CNRELCONG + (TFNRELCONG + THNRELCONG + TFNRELCONGSUB + THNRELCONGSUB)) / TASSALL

и

TCH Congestion Rate = 100 * ((TFCONGSAS + THCONGSAS + TFCONGSASSUB + THCONGSASSUB) + (TFCONGSHO + THCONGSHO + TFCONGSHOSUB + THCONGSHOSUB)) / (TFCALLS + THCALLS)

Я думаю достаточно, хотя и грубо вычислять перегрузки по TCH, как отношение неуспешных попыток назначения каналов TCH по причине отсутствия радиоресурса к общему количеству попыток выделений каналов TCH, умноженное на 100 (для перехода к процентам).

Т.о. формула:
T_CONG[%]=((SUMM[CNRELCONG]+SUMM[TNRELCONG])/(SUMM[TASSALL]))*100

Возник вопрос....недавно пришлось столкнуться с вопросами оценки Call Congestion в сетях Эрикссон (R06, R07). Из прошлого опыта оценка этого индикатора ведется по формуле:
Call Congestion= 100*(TFNRELCONG+THNRELCONG+TFCONGSAS+THCONGSAS-CNRELCONG+TFNRELCONGSUB+THNRELCONGSUB+TFCONGSASSUB+THCONGSASSUB)/TASSALL - (не включая HO)

Но вот столкнулся с другой формулой предложенной другим оператором:
Call Congestion = 100* TFESTPGSMSUB/TASSALL

В соответствии с документами Эрикссона счетчик TFESTPGSMSUB срабатывает при условии - This counter counts the number of connections successfully established on the P-GSM 900 Band TCH/F.
По утверждениям заказчика документация не соответствует действительности, а реально замеряет Subscriber Perceived TCH Congestion (during Assignment). Что в принципе подтверждено замерами статистики (при увеличении числа TRXов на перегруженном секторе, значения счетчика обнулялись или резко уменьшались).

Кто может это подтвердить или опровергнуть?

[ysamarin]

Из прошлого опыта оценка этого индикатора ведется по формуле:
Call Congestion= 100*(TFNRELCONG+THNRELCONG+TFCONGSAS+THCONGSAS-CNRELCONG+TFNRELCONGSUB+THNRELCONGSUB+TFCONGSASSUB+THCONGSASSUB)/TASSALL - (не включая HO)

Но вот столкнулся с другой формулой предложенной другим оператором:
Call Congestion = 100* TFESTPGSMSUB/TASSALL

По утверждениям заказчика документация не соответствует действительности, а реально замеряет Subscriber Perceived TCH Congestion (during Assignment).

Кто может это подтвердить или опровергнуть?

Формула не точная, это действительно понятно.

[Danikd]

Из прошлого опыта оценка этого индикатора ведется по формуле:
Call Congestion= 100*(TFNRELCONG+THNRELCONG+TFCONGSAS+THCONGSAS-CNRELCONG+TFNRELCONGSUB+THNRELCONGSUB+TFCONGSASSUB+THCONGSASSUB)/TASSALL - (не включая HO)

Но вот столкнулся с другой формулой предложенной другим оператором:
Call Congestion = 100* TFESTPGSMSUB/TASSALL

По утверждениям заказчика документация не соответствует действительности, а реально замеряет Subscriber Perceived TCH Congestion (during Assignment).

Кто может это подтвердить или опровергнуть?

Формула не точная, это действительно понятно.

С чего сделан вывод???? есть инфа?? или так просто....не точно потому что не пользуюсь....

Оператор с 400 миллионами абонетнов пользуется и говорит что совместно с Эриксоном сделано....а вот документы не подправили чтобы другим не повадно было использовать....

Хотя и то что написано Эриксоном о счетчиках в блоке CELTCHFP. Описания какие-то левые и трудно понимаемые в отличие от других блоков....

[ysamarin]

Но вот столкнулся с другой формулой предложенной другим оператором:
Call Congestion = 100* TFESTPGSMSUB/TASSALL

Кто может это подтвердить или опровергнуть?

Формула не точная, это действительно понятно.

С чего сделан вывод???? есть инфа?? или так просто....не точно потому что не пользуюсь....

o.k. Я конечно могу и ошибаться, я не эриксоновод (я больше мотороловец)... Может быть в этом есть доля правды, во первых в знаменателе мы видим общее число количества попыток выделений каналов TCH обратно пропорционально будет зависимость к перегрузкам. Но TFESTPGSMSUB Overlaid Subcell будет отражать только TCH/F и без учета HO, когда пройден запрос на установление соединения (SCCP Message). Возможно кто-то и по сей день пользуется, и пусть оператор с миллионной базой, но я бы такой формулой однозначно не пользовался. Я думаю это старая версия простого подсчета TCH перегрузок, когда в былые времена был только FR

[Danikd]

Формула не точная, это действительно понятно.

С чего сделан вывод???? есть инфа?? или так просто....не точно потому что не пользуюсь....

o.k. Я конечно могу и ошибаться, я не эриксоновод (я больше мотороловец)... Может быть в этом есть доля правды, во первых в знаменателе мы видим общее число количества попыток выделений каналов TCH обратно пропорционально будет зависимость к перегрузкам. Но TFESTPGSMSUB Overlaid Subcell будет отражать только TCH/F и без учета HO, когда пройден запрос на установление соединения (SCCP Message). Возможно кто-то и по сей день пользуется, и пусть оператор с миллионной базой, но я бы такой формулой однозначно не пользовался. Я думаю это старая версия простого подсчета TCH перегрузок, когда в былые времена был только FR

Это как раз то что написано у эриксона.....читали....а вот знающие люди утвержают что ерунда написана....кто на эриксоне сидит....проверте