В нашей сети используются контроллеры фирмы SIEMENS с софтом BR7.0. Для предоставления услуги GPRS в контроллерах установлены платы PPXU (ну и другое оборудование наверное ).
Если я правильно понял текущую ситуацию имеем следующее. При переходе MS в режим READY на плате PPXU абоненту выделяется различное кол-во физических каналов 16к (в зависимости от назначенного кодека). Эти каналы выделены ТОЛЬКО этому абоненту и на весь срок таймера (как мне сказали таймер чуть меньше чем таймер READY -> STANDBY). Таким образом мы получаем нагрузку на плату 5% со всеми занятыми физ каналами.
Теперь мегавопрос. Каким образом в технологии GPRS ориентированной на коммутацию пакетов на магистральном узле (контроллере) используется плата используящая технологию с коммутацие КАНАЛОВ?!?!
Если кто-нибудь может, просвятите пожайлуста почему платы PPXU работают так оригинально.
Платы PPXU в контроллере фирмы Siemens BR7.0 — Планирование и оптимизация сетей GSM
-
- Нетмониторщик
- Сообщения: 52
- Зарегистрирован: Вс, 28-01-2007, 19:34
- Нетмонитор: K790i
-
- Опытный нетмониторщик
- Сообщения: 135
- Зарегистрирован: Пт, 21-09-2007, 14:48
Ну во первых каналы PDCH на радиоинтерфейсе и PDT на A-bis могут разделяться несколькими MS (до 7 вверх и до 16 вниз, в общей сложности не более 16). Во вторых имеются специальные процедуры освобождения TBF, контролируемые таймерами. Для указания желания освободить TBF uplink MS начинает процедуру count down, когда явно указывает сети сколько блоков данных ещё осталось для передачи в данном TBF. По окончании передачи MS запускает таймер и в конечном итоге безусловно освобождает ресурсы.
Для указания желания освободить TBF downlink сеть явно указывает на передачу последнего блока (Final Block Indicator). При получении этого блока MS запускает таймер (контролируется сетью и может быть равен 0 секунд) и по таймауту освобождает ресурсы. Где же здесь КАНАЛЬНАЯ коммутация? При отсутствии блоков для передачи в MS или буфере PCU в BSC ресурсы практически немедленно освобождаются.
Для указания желания освободить TBF downlink сеть явно указывает на передачу последнего блока (Final Block Indicator). При получении этого блока MS запускает таймер (контролируется сетью и может быть равен 0 секунд) и по таймауту освобождает ресурсы. Где же здесь КАНАЛЬНАЯ коммутация? При отсутствии блоков для передачи в MS или буфере PCU в BSC ресурсы практически немедленно освобождаются.
-
- Опытный нетмониторщик
- Сообщения: 135
- Зарегистрирован: Пт, 21-09-2007, 14:48
-
- Нетмониторщик
- Сообщения: 52
- Зарегистрирован: Вс, 28-01-2007, 19:34
- Нетмонитор: K790i
На Um интерфейсе реализована нормальная коммутация пакетов в каналах PDCH.
Я же говорю про проблемы именно на уровне контроллера в платах PPXU. Почему получается загрузка плат на 5-10% со всеми занятыми каналами?
"При отсутствии блоков для передачи в MS или буфере PCU в BSC ресурсы практически немедленно освобождаются" - насколько мне известно как раз таки и получается что ресурсы на BSC освобождаются через определенный таймер, который измереяется в довольно большом кол-ве секунд. Точно размер таймера не знаю. Пока что сказали что он немного меньше таймера перехода READY->STANBY равного у нас в сети 35 секунд.
Я же говорю про проблемы именно на уровне контроллера в платах PPXU. Почему получается загрузка плат на 5-10% со всеми занятыми каналами?
"При отсутствии блоков для передачи в MS или буфере PCU в BSC ресурсы практически немедленно освобождаются" - насколько мне известно как раз таки и получается что ресурсы на BSC освобождаются через определенный таймер, который измереяется в довольно большом кол-ве секунд. Точно размер таймера не знаю. Пока что сказали что он немного меньше таймера перехода READY->STANBY равного у нас в сети 35 секунд.
-
- Нетмониторщик
- Сообщения: 52
- Зарегистрирован: Вс, 28-01-2007, 19:34
- Нетмонитор: K790i
Опережая будущие вопросы опишу ситуацию более широко.
По результатам драйв-тестов GPRS и статистики имеем нормальный ресурсы на Um интерфейсе (4 TS), по статистике на измеряемой БС проблем c нехваткой абиса нет. При этом на этих 4 TS мобильник работает чаще на MCS-1 или редко на MCS-3. У других операторов почти под 100% используется MCS-9 кодовая схема кодирования.
На контроллере, который обслуживает проверяемую БС, установлено 3 платы PPXU с малым процентом загрузки. Установка дополнительной платы по статистике увеличило долю использования более скоростных схем кодирования. Вот поэтому и возник вопрос как обеспечить почти 100% MCS-9. Плат в контроллер мы можем воткнуть до 6 штук, но учитывая текущую статистику использования кодовых схем, использование 6 карт PPXU все равно не обеспечит приоритетную долю MCS-9.
По результатам драйв-тестов GPRS и статистики имеем нормальный ресурсы на Um интерфейсе (4 TS), по статистике на измеряемой БС проблем c нехваткой абиса нет. При этом на этих 4 TS мобильник работает чаще на MCS-1 или редко на MCS-3. У других операторов почти под 100% используется MCS-9 кодовая схема кодирования.
На контроллере, который обслуживает проверяемую БС, установлено 3 платы PPXU с малым процентом загрузки. Установка дополнительной платы по статистике увеличило долю использования более скоростных схем кодирования. Вот поэтому и возник вопрос как обеспечить почти 100% MCS-9. Плат в контроллер мы можем воткнуть до 6 штук, но учитывая текущую статистику использования кодовых схем, использование 6 карт PPXU все равно не обеспечит приоритетную долю MCS-9.
- V12
- Известный нетмониторщик
- Сообщения: 666
- Зарегистрирован: Ср, 13-12-2006, 15:51
Gb не перегружен?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.
-
- Опытный нетмониторщик
- Сообщения: 135
- Зарегистрирован: Пт, 21-09-2007, 14:48
Занятыми где? На радиоинтерфейсе? На A-bis? Всеми - это сколько?Crazymax писал(а):На Um интерфейсе реализована нормальная коммутация пакетов в каналах PDCH.
Я же говорю про проблемы именно на уровне контроллера в платах PPXU. Почему получается загрузка плат на 5-10% со всеми занятыми каналами?
Все таймеры имеют своё название. Что это за загадочный таймер? При освобождении uplink TBF происходит стандартная процедура с двухсторонним подтверждением и никаких таймеров для пролонгирования TBF не используется (исключение составляет фиксированный таймер в сети = 400 миллисекунд задержки подтверждения последнего блока). Используются только таймера для обработки нестандартных ситуаций.Crazymax писал(а): - насколько мне известно как раз таки и получается что ресурсы на BSC освобождаются через определенный таймер, который измереяется в довольно большом кол-ве секунд. Точно размер таймера не знаю. Пока что сказали что он немного меньше таймера перехода READY->STANBY равного у нас в сети 35 секунд.
Освобождение downlink TBF регулируется таймерами (НАСТРАИВАЕМЫМИ ОПЕРАТОРОМ) Т3191 (1-30 с) - запускается на стороне сети после отправки последнего блока (срабатывает ТОЛЬКО при неполучении подтверждения последнего блока от MS, т.е. при правильной работе до конца своей жизни никогда не доживает); Т3192 - на стороне MS (0 - 1,5 сек) запускается при получении последнего блока, при срабатывании посылает подтверждение в сеть и освобождает ресурсы; Т3193 (100 миллисек - 4 с небольшим сек) - на стороне сети, запускается после получения подтверждения от MS, при срабатывании сеть освобождает ресурсы. Есть ещё таймер, который оператор может использовать, а может и нет. Регулируется параметром TIMEDTBFREL (0 - почти 5 сек) - таймер задержки отправки сетью последнего блока. Всё! "довольно большое кол-во секунд" выливается в 100 миллисек при желании. Действительно вносящие вклад в задержку - это Т3192, Т3193 и TIMEDTBFREL . Т3191 - для обработки нештатных ситуаций.
А что, схемы кодирования выше MCS-3 ВООБЩЕ не используются? По статистике? А на других базовых этого контроллера? Если вообще не используются, то скорее что-то с конфигурацией. Если изредка, но используются, то скорее всего где-то чего-то не хватает (скорее всего A-bis, Gb, плохой радиоканал). Как с голосовой нагрузкой? Если на какой-то BTSM большая. то высшие схемы кодирования на ней будут использоваться очень редко (MCS-9 занимает 5 PDT на A-bis на один PDCH). К тому же зависит от параметра GASTRABISTH - в числе прочего определяет порог свободных PDT на A-bis. при котором прекращается апгрейд схем кодирования.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..