Фиксированый ТС под GPRS, насколько это хорошо? — Планирование и оптимизация сетей GSM

[kadet]

Суть вопроса, есть ли смысл в сети где только GPRS (ежа нет), фиксировать 1 тс под ГПРС, насколько это критично.
сеть моторола.

Вопрос возник по одной причине, после фиксации 1 тс, выправили один параметр -недоступность PDTCH=0, но искиривили другой Channel Reqs Reject - он вырос

[ash]

перегрузки по сектору в голосовом трафике есть ?

[Sila2]

Фиксированные ТС фиксированно отъедают ресурс PCU, уменьшая возможность её динамического перераспределения
Горячиться с этим не следует, одного фиксированного (дедикейт) ТС в секторе достаточно для уверенной возможноссти получить GPRS соединение.
Есть второй уровень = дефолт ТС это те, которые сформированы под GPRS. но могут быть отданы и под голос. Позволяет быстрее отдавать ресурсы для GPRC

Если с назначеием дедикейт вырос Channel Reqs Reject, значит, как минимум в ЧНН, сектор испытывает большую нагрузку.

Поиграйся, если есть возможность, с параметрами DR. Сделай так, чтобы HR включался раньше.

[kadet]

Спасибо за рекомендации
2 ash - нагрузка в пределах нормы, под контролем

[Sila2]

Спасибо за рекомендации
2 ash - нагрузка в пределах нормы, под контролем

В пределах нормы - хороший ответ

Если, по норме, в ЧНН на голосе 2% отказов - забуть о пакете в это время. Весь твой радиоинтерфейс сжирает голос, а пакет будет теплиться толькона дедикейт ТС. Все пользователи - на один ТС, скорость будет обхохочешься, макс 59.2 кбитс/c на всех

Если нужен более-менее приличный интернет, нормы должны назначаться не по голосу, а по сумме = пакет + голос

[TOV]

Если нужен более-менее приличный интернет, нормы должны назначаться не по голосу, а по сумме = пакет + голос

Нужен! Поясните как считать совместно, плз.

[tre]

T.Halonen, et al - GSM, GPRS and EDGE Performance - Evolution Towards 3G-UMTS. 2nd edition - там вроде бы неплохо рассмотрен рассчет голос+данные

[Sila2]

Если нужен более-менее приличный интернет, нормы должны назначаться не по голосу, а по сумме = пакет + голос

Нужен! Поясните как считать совместно, плз.

tre Спасибо прочитаю, но сейчас о 2,5 G

Считать, в общем не сложно.
Сложнее определиться с исходными данными. Какую скорость хотим получить и когда? В ЧНН или ночью? От чего плясать будем?

Допустм хотим получить 128 кбит/c на пользователя. Грубо это 3 TSL = 1 канал 128 к бит.
Знаем голосовую нагрузку и отрулили её нужным количеством ТRx. 15% абонентов пользуются и-нетом, но им нужно не по одному, а по три TSL 15 на 3 = 45%. Добавляем 45 -50 процентов TRx.

Понятно, это не расчет, это прикидка.

Дальше - практика. Заряжаем Темс, или что есть, на закачку файла, скажем 500 к байт весом, через каждые 5 минут, и ставим его на показательной по пакетной нагрузке БС., в интересующее нас время. Смотрим скорость, анализируем, работаем над ошибками.

Сказанное относится к радиоинтерфейсу. DAP-s в A-bis и РСU и т.д тема отдельнаяю

[kadet]

Еще раз спасибо всем.
Немного конкретики, сеть не располагает возможностью организации Ежа и тем более 3Г, т.е. рассматриваем только ГПРС (моторола) . Под передачу данных определены 4 ТС, которые бегают между голосом и данными, но в приоритете голос. переНагрузка по голосу рассматриваем в пределах до 1 %, но в связи с тем что идут жалобы по передачу данных решили зафиксировать по 1 тс под ГПРС (не на всей сети а выборочно секторно)
Идея такова чтобы абоны могли стабильно завершать сессию. Вроде все хорошо, кроме параметра см. выше
выправили один параметр -недоступность PDTCH=0, но искиривили другой Channel Reqs Reject - он вырос

[TOV]

выправили один параметр -недоступность PDTCH=0, но искиривили другой Channel Reqs Reject - он вырос

Уточните что за параметр Channel Reqs Reject, как считается?

[kadet]

The CHANNEL_REQS_REJECT statistic tracks the number of rejections by the PCU for packet channel
or resource requests. The PCU rejects such requests because the resources are unavailable.

[Fixer]

Суть вопроса, есть ли смысл в сети где только GPRS (ежа нет), фиксировать 1 тс под ГПРС, насколько это критично.
сеть моторола.

Вопрос возник по одной причине, после фиксации 1 тс, выправили один параметр -недоступность PDTCH=0, но искиривили другой Channel Reqs Reject - он вырос

Всё зависит от того , что Вы хотите получить . Если Вы хотите обеспечить своим абонентам комфортное использование GPRS и адекватную тарификацию при округлении трафика , конечно , выделять фиксированный таймслот под GPRS имеет смысл . Нужно только не забывать при этом провести расширение радио на перегруженных секторах ( или HR ) и добавить DPROCи в PCU . Дело в том , что один DPROC может обрабатывать 120 тс , но одновременно активных может быть только 30.

[kadet]

Если Вы хотите обеспечить своим абонентам комфортное использование GPRS и адекватную тарификацию при округлении трафика , конечно , выделять фиксированный таймслот под GPRS имеет смысл . Нужно только не забывать при этом провести расширение радио на перегруженных секторах ( или HR ) и добавить DPROCи в PCU . Дело в том , что один DPROC может обрабатывать 120 тс , но одновременно активных может быть только 30.

хороший вопрос, наверное тут работа двух отделов так сказать, мой интерес обеспечить более менее (понятно что не супер) приемлимое качество, при котором абон будет работать с нами. Голосовой трафик контролирую, т.е. перегруз не допускаем. по емкости PСU занимаються другие ребята

Нашли еще одну проблему, на абис интерфейсах используем оборудование уплотнения, которое со свое стороны видимо нам начала давать свое ограничение по переключению PDTCH в голосовые

Вообщем проблем становиться еще больше (кризис тому виной)

[V12]

Еще раз спасибо всем.
Немного конкретики, сеть не располагает возможностью организации Ежа и тем более 3Г, т.е. рассматриваем только ГПРС (моторола) . Под передачу данных определены 4 ТС,

и Вы хотите, чтобы при таком ресурсе у Вас все работало? У Вас 2-3 абонента сядут песню качать и "заткнётся" Ваш GPRS. Под GPRS нужно 100% динамически делать.

[Sila2]

А что за уплотнение в А-bise, уж не CellTrо ?