Микро БС — Планирование и оптимизация сетей GSM

[mpuh]

"Но самое интересное, что небольшое кол-во соединений устанавливалось из 1800-го. почему, непонятно..." - если на секторе есть BCCH и SDCCH почему бы не создаться условиям, когда телефон все же "сядет" на 1800. Вот тебе и некоторое количество вызовов в 1800. [/quote]

[mpuh]

Речь идет о пейджинге, как на него RACH влияет?

А как телефон отвечает сети на какой соте он сидит?

Я имел ввиду, что Paging сообщение посланное на 1000 ячеек вернется только с одной. т.о. мне трудно представить как RACH может сильно повлиять на пейджинг?

А сколько таких телефонов будет отвечать на пейджинг (смс или входящий звонок), или устанавливать соединение (голос или данные) если нагрузка на сектор очень большая??? Может ведь и не хватить RACH или AGCH... Мож ошибаюсь конечно.

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

Так ведь при penalty_time=31 - оффсет вычитается из С1, т.е. C2 для 1800 всегда отрицателен... Так почему все-таки некоторые MS сидят в idle mode в 1800. Или из-за каких-либо особенностей аппартов они не считают C2, а принимают решение по C1. Может это телефоны фазы 1 ?

Кроме фазы 1 еще и выполнение penalty_time=31 - значение вполне конечное.

[Waveman]

Так ведь при penalty_time=31 - оффсет вычитается из С1, т.е. C2 для 1800 всегда отрицателен... Так почему все-таки некоторые MS сидят в idle mode в 1800. Или из-за каких-либо особенностей аппартов они не считают C2, а принимают решение по C1. Может это телефоны фазы 1 ?

Кроме фазы 1 еще и выполнение penalty_time=31 - значение вполне конечное.

Алексей, конечное значение penalty time от 1 до 30, 31 - значит бесконечность, если бы все было так просто.... Т.е. все время для DCS работает отрицательный offset, равный 63. Конечно ,теоретически возможна ситуация, когда C1 для 900-го диапазона отрицателен. Но! rxlev_access_min для 900 равен 5, для 1800 равен 20, т.е. практически нереально.
Остаются телефоны , не поддерживающие C2, но ведь при таких rxlev_access_min - условия при которых С1 для 1800 станет больше С1 для 900 - маловероятны. А звонков из 1800-ки устанавливается примерно 5%. Может еще какие будут соображения?

[Waveman]

Очень интересно почему, на бумаге все красиво получается.

Все хендовера и прочи директы - это не есть хорошо в принципе.
Причина, наверное, в градусе угла зрения: рассматриваем статичный трафик на некий момент времени, а имеем ниминуемую циркуляцию трафика в системе (с течением времени), которая не может в момент времени идеально развести трафик по ее элементам (секторам).

Совершенно верно!

После включения assignment_redirection число хэндоверов увеличилочь в полтора раза, к тому же при assignment имеем почти слепой хэндовер. (т.к. решение принимается по одному MR Report). Вообще разумнее было бы запретить хэндоверы по power budget из 1800 в 900, или создать еще больший перекос в параметрах.
Изначально преследовалась цель уменьшения количества drop call, т.к. в 1800 обрывов происходит в 5 раз меньше (чище диапазон, больше частот, лучше ЧТП).. в результате увеличившееся кол-во хэндоверов нивелировало этот выигрыш.

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

Алексей, конечное значение penalty time от 1 до 30, 31 - значит бесконечность, если бы все было так просто.... Т.е. все время для DCS работает отрицательный offset, равный 63.

Странно, есть же постоянный оффсет и так... зачем же во временном вводить параметр бесконечности? С июня будет время, посмотрю учебники, может, есть какая-то разница...

Конечно ,теоретически возможна ситуация, когда C1 для 900-го диапазона отрицателен. Но! rxlev_access_min для 900 равен 5, для 1800 равен 20, т.е. практически нереально.

А теперь это все рассматриваем с течением времени...
Учитываем медленные замирания и... размер списков. Понятно, к чему я?

Остаются телефоны , не поддерживающие C2, но ведь при таких rxlev_access_min - условия при которых С1 для 1800 станет больше С1 для 900 - маловероятны. А звонков из 1800-ки устанавливается примерно 5%. Может еще какие будут соображения?

Как вариант, схемы CR...