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

[orcinus_orca]

Всем привет.
Возник вопрос как правильно считать "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)

Проблемы в том, что если считаешь по первой формуле то при большом трафике совсем нет перегрузок, в то же время как расчет по второй ыормуле дает порядка 50-70% для той же соты.
Когда делали своп с Сименса на Эриксон то сталкнулист с той же проблемой - при тех же настройках халфрейта - величина отказов по первой формуле значительно меньше, что былол на Сименсе, а по второй - значительно больше.

Может расшарите как считается в Ваших сетях?

[AseD_Qwest]

Обе формулы верные Subscriber Perceived TCH Congestion Rate - сервисные блокировки, реальные блокировки у абонента на экране "сеть занята"
TCH Congestion Rate - технические блокировки блокировки на HO, при вытеснении голосом каналов передачи данных. Мониторить надо оба

[orcinus_orca]

Т.е. если мы имеем "TCH congestion rate" то хэдоверы в эту соту будут неуспешными из-за того, что все каналы заняты. А что будет если абонент попытается сделать вызов в этой соте?
У нас например есть соты, где "TCH Congestion Rate" = 80%, но при этом "Subscriber Perceived TCH Congestion Rate" = 1%. Получается что хэндоверы будут неудачные из-за занятых трафиковых каналов, но при этом можно будет сделать вызов из этой соты без особых проблем. Так?

[V12]

Т.е. если мы имеем "TCH congestion rate" то хэдоверы в эту соту будут неуспешными из-за того, что все каналы заняты. А что будет если абонент попытается сделать вызов в этой соте?
У нас например есть соты, где "TCH Congestion Rate" = 80%, но при этом "Subscriber Perceived TCH Congestion Rate" = 1%. Получается что хэндоверы будут неудачные из-за занятых трафиковых каналов, но при этом можно будет сделать вызов из этой соты без особых проблем. Так?

Если все каналы в соте заняты, при этом кто-то пытается установить соединение, то посчитается блокировка, а затем будут предприняты действия на установление соединения или в соседней соте за счёт directed retry, или поставит в очередь (если опция включена) или выкинет GPRS(в случае хендовера) и поставит голос. В любом случае блокировка посчитается, хотя реального отказа не будет. Показатель в основном применяется для оценки свободности ресурсов в соте. Если в соте начинаются реальные отказы, то вместе с блокировками проседает CallSetup и здесь нужно уже расширяться.

[orcinus_orca]

Хорошо. Возможно ли такое в одной и той же соте:
TCH Congestion Rate=93.25% а Suscriber TCH Congestion rate=10.73%. Это реальные данные.
Как это объяснить?

[V12]

Хорошо. Возможно ли такое в одной и той же соте:
TCH Congestion Rate=93.25% а Suscriber TCH Congestion rate=10.73%. Это реальные данные.
Как это объяснить?

А трафик в соте какой? Сколько передатчиков в соте? Какой порог активации HR, % ресурса выделяемого динамически под GPRS?

[V12]

Хорошо. Возможно ли такое в одной и той же соте:
TCH Congestion Rate=93.25% а Suscriber TCH Congestion rate=10.73%. Это реальные данные.
Как это объяснить?

А трафик в соте какой? Сколько передатчиков в соте? Какой порог активации HR, % ресурса выделяемого динамически под GPRS?

Еще сколько СallSetup в соте?

[TOV]

Хорошо. Возможно ли такое в одной и той же соте:
TCH Congestion Rate=93.25% а Suscriber TCH Congestion rate=10.73%. Это реальные данные.
Как это объяснить?

Возможно. Это объясняется тем, что у вас Suscriber TCH Congestion rate=10.73%, а значит абоненты не могут дозвониться с первого раза и делают огромное количество повторных попыток, что и сказывается на TCH Congestion Rate + сота отбрасывает все попытки HO в нее из-за перегрузок. Если влючен AMR, то он тоже влияет на TCH Congestion Rate (по крайней мере в Сименсе).

[orcinus_orca]

Тогда такой вопро - надо ли поднимать кипеш и искать пути улучшения ситуации если "TCH Congestion rate" большой (допустим 20-30%), а "Suscriber TCH Congestion rate" маленький (допустим 1-2%)? Другими - по какому параметру настраивать и оценивать сеть?

[TOV]

Тогда такой вопро - надо ли поднимать кипеш и искать пути улучшения ситуации если "TCH Congestion rate" большой (допустим 20-30%), а "Suscriber TCH Congestion rate" маленький (допустим 1-2%)? Другими - по какому параметру настраивать и оценивать сеть?

Вообще-то дело вкуса, ИМХО. Я в первую очередь смотрю именно Suscriber TCH Congestion rate, т.к. он наиболее заметен абонентам. TCH Congestion rate больше влияет на HO (дропы) и GPRS.
Если Suscriber TCH Congestion rate большой (>2%) - надо расширяться.

[V12]

Тогда такой вопро - надо ли поднимать кипеш и искать пути улучшения ситуации если "TCH Congestion rate" большой (допустим 20-30%), а "Suscriber TCH Congestion rate" маленький (допустим 1-2%)? Другими - по какому параметру настраивать и оценивать сеть?

Если нужна качественная работа GPRS и голоса одновременно, то по первому(сеть раздуется до неимоверных размеров)

[TOV]

Ну, да, если первый параметр плохой, то кирдык всем сервисам, а если только второй, то некоторым.

[Manfred]

Пишу прогу для обработки статистики. Не подскажет ли кто, как расшифровать эти сокращения:

CNRELCONG
TFNRELCONG
THNRELCONG
TFCONGSHO
THCONGSHO
TFCALLS
THCALLS
TEHCONG

Спасибо.

[ysamarin]

Пишу прогу для обработки статистики. Не подскажет ли кто, как расшифровать эти сокращения:

CNRELCONG
TFNRELCONG
THNRELCONG
TFCONGSHO
THCONGSHO
TFCALLS
THCALLS
TEHCONG

Спасибо.

1. CNRELCONG
The Released Connections on SDCCH due to Radio Resource Congestion counters are incremented when a connection on SDCCH is released due to radio resource congestion, that is when there is congestion on TCH or congestion on transcoder resources.
2. TFNRELCONG/THNRELCONG (FR/HR)
The released connections due to radio resource congestion counters are incremented when a TCH connection used for signalling and allocated as a result of immediate assignment is released due to radio resource congestion, that is when there is congestion on transcoder resources.
3. TFCONGSHO/THCONGSHO (FR/HR)
The ’TCH congestion at handover’ counters are incremented when an allocation attempt of a channel for handover fails due to no idle channels are available.
4. TFCALLS/THCALLS
For every cell there are counters for the number of allocation attempts. They are incremented at every attempt to allocate a TCH in a resource type in the cell, to be used for signalling, data or speech, regardless of whether the allocation succeeded or failed. Allocation attempts are made at signalling connection setup, at assignment and at handover.
5. TEHCONG
Не нашёл.

[ysamarin]

Всем привет.
Возник вопрос как правильно считать "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