Crazymax писал(а):На Um интерфейсе реализована нормальная коммутация пакетов в каналах PDCH.
Я же говорю про проблемы именно на уровне контроллера в платах PPXU. Почему получается загрузка плат на 5-10% со всеми занятыми каналами?
Занятыми где? На радиоинтерфейсе? На A-bis? Всеми - это сколько?
Crazymax писал(а):
- насколько мне известно как раз таки и получается что ресурсы на BSC освобождаются через определенный таймер, который измереяется в довольно большом кол-ве секунд. Точно размер таймера не знаю. Пока что сказали что он немного меньше таймера перехода READY->STANBY равного у нас в сети 35 секунд.
Все таймеры имеют своё название. Что это за загадочный таймер? При освобождении uplink TBF происходит стандартная процедура с двухсторонним подтверждением и никаких таймеров для пролонгирования TBF не используется (исключение составляет фиксированный таймер в сети = 400 миллисекунд задержки подтверждения последнего блока). Используются только таймера для обработки нестандартных ситуаций.
Освобождение downlink TBF регулируется таймерами (НАСТРАИВАЕМЫМИ ОПЕРАТОРОМ) Т3191 (1-30 с) - запускается на стороне сети после отправки последнего блока (срабатывает ТОЛЬКО при неполучении подтверждения последнего блока от MS, т.е. при правильной работе до конца своей жизни никогда не доживает); Т3192 - на стороне MS (0 - 1,5 сек) запускается при получении последнего блока, при срабатывании посылает подтверждение в сеть и освобождает ресурсы; Т3193 (100 миллисек - 4 с небольшим сек) - на стороне сети, запускается после получения подтверждения от MS, при срабатывании сеть освобождает ресурсы. Есть ещё таймер, который оператор может использовать, а может и нет. Регулируется параметром TIMEDTBFREL (0 - почти 5 сек) - таймер задержки отправки сетью последнего блока. Всё! "довольно большое кол-во секунд" выливается в 100 миллисек при желании. Действительно вносящие вклад в задержку - это Т3192, Т3193 и TIMEDTBFREL . Т3191 - для обработки нештатных ситуаций.
Crazymax писал(а):
Опережая будущие вопросы опишу ситуацию более широко.
По результатам драйв-тестов GPRS и статистики имеем нормальный ресурсы на Um интерфейсе (4 TS), по статистике на измеряемой БС проблем c нехваткой абиса нет. При этом на этих 4 TS мобильник работает чаще на MCS-1 или редко на MCS-3. У других операторов почти под 100% используется MCS-9 кодовая схема кодирования.
На контроллере, который обслуживает проверяемую БС, установлено 3 платы PPXU с малым процентом загрузки. Установка дополнительной платы по статистике увеличило долю использования более скоростных схем кодирования. Вот поэтому и возник вопрос как обеспечить почти 100% MCS-9. Плат в контроллер мы можем воткнуть до 6 штук, но учитывая текущую статистику использования кодовых схем, использование 6 карт PPXU все равно не обеспечит приоритетную долю MCS-9..
А что, схемы кодирования выше MCS-3 ВООБЩЕ не используются? По статистике? А на других базовых этого контроллера? Если вообще не используются, то скорее что-то с конфигурацией. Если изредка, но используются, то скорее всего где-то чего-то не хватает (скорее всего A-bis, Gb, плохой радиоканал). Как с голосовой нагрузкой? Если на какой-то BTSM большая. то высшие схемы кодирования на ней будут использоваться очень редко (MCS-9 занимает 5 PDT на A-bis на один PDCH). К тому же зависит от параметра GASTRABISTH - в числе прочего определяет порог свободных PDT на A-bis. при котором прекращается апгрейд схем кодирования.
).