RLT counter — Планирование и оптимизация сетей GSM

[necovi4]

Доброе утро!
Подскажите, пожалуйста, какое оптимальное значение счетчика использовать на дорожных и городских сайтах?И вообще сушественно ли он влияет на статистику дропов

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

Call Restabilishment есть?

[necovi4]

4 и 6

[Lom64]

4 и 6 маловато будет.
скорее ~32-48 и 4-16 соответственно

[Дмитрий Михайлов]

Доброе утро!
Подскажите, пожалуйста, какое оптимальное значение счетчика использовать на дорожных и городских сайтах?И вообще сушественно ли он влияет на статистику дропов

Добрый вечер! Влияет и прямо и косвенно.
Можете количество дропов свести к минимуму, - установить тако-о-о-ое значение RLT, что абонент сам будет сбрасывать соединение, когда он ничерта не слышит. Как результат - "отличная статистика по дропам + злющие абоненты".

[udsv]

А что для абонента лучше?
Платить второй раз за соединение или несколько секунд тишины в трубе?

[Дмитрий Михайлов]

А спроси у своего соседа, что ему лучше:
1. платить за тишину, не надеясь на чудо - время разговора ведь считается (сентики-то капают)
2. перезванивать и платить за соединение (опять таки центики)
в обоих случаях -
Так что с RLT нужно обращаться нежно

[mpuh]

У многих операторов, что я видел, большинство секторов, попавших в логи Темса, имеют значение RLT=20. У МТС и Билайна разбросов по значениям больше, но большинство с вышеуказанным значением. Тестировал достаточно много трех операторов (центр, кавказ, сибирь). Если не включен Call Restabilishment, то можно ставить секунд до 5, больше нет смысла. Больше 10 секунд (20 sach) даже при включенной Call Restabilishment тоже нет смысла ставить. Но это все исходя из моего опыта и разделять город - не город тоже большого смысла нет, радиосеть есть радиосеть.

[Kabancheg]

В большинстве случаев при закручивании RLT счетчика кол-во DCR по причине Radio link Failure снижается, но возрастает кол-во DCR по причине MS_responce_time_expired, так что в итоге DCR без изменений.

[udsv]

Увеличивать RLTO для мобильника, т.е для подсчета некодируемых SACCH фреймов по DL смысла нет, согласен. Но увеличив этот счетчик на БТС т.е для подсчета битых фреймов по UL - результат превосходит ожидания. Проверенно практикой и общий % CDR снижается.

[Дмитрий Михайлов]

Увеличивать RLTO для мобильника, т.е для подсчета некодируемых SACCH фреймов по DL смысла нет, согласен. Но увеличив этот счетчик на БТС т.е для подсчета битых фреймов по UL - результат превосходит ожидания. Проверенно практикой и общий % CDR снижается.

это какой-то другой счетчик?

[Kabancheg]

Да, согласен. RLT из BTS(BASICS) для мобильника не приносит пользы никакой. Эффект возможен только при увеличении RLT для БТС, т.е. для группы PWRC, что и делалось мною, в результате чего возростал процент DCR по причине MS_responce_time_expired. Т.е. получалось что из-за отсутствия кадров от мобильника обрыва не происходило, но происходил обрыв из-за отсутствия ответа от мобильника о выполненных командах (мобильник выполняет все команды BSC с высолкой в сторону BSC подтверждения об удачном выполнении). Для снижения DCR по причине MS_responce_time_expired приходилось накручивать другой очень специфичный таймер.
Кстати по требованиям московских сименойдов менять RLT для БС (RDLNKTBS), т.е. в PWRC, можно только в связке с RLT для мобильника (RDLNKTO) и с трешхолдом увеличеия мощности до максимума PCRLFTH из PWRC.
Из трех случаев DCR по причине Radio link failure и Ms responce time expired снижаются только в одном в результате применения всей связки параметров, т.е трех таймеров и одного трешхолда.

[udsv]

Ну вообще то эти три параметра связаны между собой, так что правильно требовали.