Странности сети? — Общие вопросы, касающиеся принципов работы GSM-сетей

[DES]

Народ, я так и не понял, есть ли возможность установки динамического CRO в зависимости от нагрузки, который при перегрузке будет заставлять трубки делать Cell Reselect на другие ячейки, что упрощает потенциальное установление соединения. Кроме того, таким образом можно информировать мобильный терминал о перегрузке. Как было бы удобно, какой-нибудь салют или концерт, все (вообще) каналы перегружены, по всем С2 приходит отрицательный, сеть теряется. Абонент проинформирован о собственной недоступности.

Я слышал (так сказать "адна баба сказала" поэтому прошу снисхождения), что при возникновении таких перегрузок BSC начинает просто закрывать перегруженные соты, на какоето время или пока не снизится загрузка. каким образом? и правда ли это я не знаю. Поэтому хочется узнать мнение более опытных товарищей по форуму.

[Barabek]

при возникновении таких перегрузок BSC начинает просто закрывать перегруженные соты, на какоето время или пока не снизится загрузка. каким образом? и правда ли это я не знаю.

А смысл их "закрывать"? В них и без того не попасть. Они заняты. Как снизится нагрузка - добро пожаловать!

[DES]

А смысл их "закрывать"? В них и без того не попасть. Они заняты. Как снизится нагрузка - добро пожаловать!

Я понимаю, что смысл как раз в том чтобы не было таких вариантов как описано выше т.е. когда при попытке позвонить с соты где все SDCCH заняты мы слышим пи пи пи. Для того чтобы MS даже не рассматривала эту соту и садилась на соседние пусть с худшим сигналом но менее загрушенные. По моему так.

[ИльяШ]

Динамический CRO... Ведь CRO, в общем-то, ближе к механизмам энергетики. Оценка загрузки трафиком - задача уровнем выше. Это делает коммутатор. CR - процедура idle режима. Там не важна перегрузка - может ты и звонить-то не собираешься (и тебе тоже). При переходе в активный режим работают другие процедуры. Коль скоро речь идёт только о стадии запроса, то решение на предоставление SDCCH другой соты принимает MSC, но для этого: а) он всё-таки долен получить запрос от MS; б) эта фича должна быть включена и прописана. Системе не выгодно начинать процедуру "перевода" абонентов в idle режиме на другие соты в случае перегрузки на обслуживающей. Это лишнее, далеко не всегда оправдываемое использование ресурса. Инициируй MS - и система за тебя возьмётся (если "захочет")

Все абсолютно правильно. Idle режим.

Вопрос-то вот в чем. Представим себе довольно "штатную" ситуацию - концерт, парад, пробка, салют. Соответственно сеть перегружена по самые-самые помидоры. Но перегрузка очень локальная. При попытке связаться, вместо того, чтобы перебросить в другой сектор, MS должна получить рекомендацию об этом от BS и контроллера, но туда не достучаться, в этом секторе не продохнуть. MS получает отлуп. Близкая ситуация и при входящем.
Теперь включается динамический CRO. Телефон сам решает перевыбрать другую ячейку сам, ресурсы сети при этом не используются (когда в том же LAC), но звонок осуществиться может, в крайнем случае и переброшен, и входящий пройдет.
В чем тут неудобство? Почему такой механизм не реализовать?

[Barabek]

Идея понятна. Однако действительно, CRO имеет иное назначение.
Для защиты от локальных перегрузок существуют иные механизмы. Пример: "Traffic Reason Handover" у Нокии. Смысл в том, что BSC или MSC оценивает нагрузку на соту (в реальном времени) и при достижении определенного порога инициирует ряд хэндоверов с загруженной соты на более свободные. При этом, естественно, учитываются уровни сигналов [cоседние BTS]--->[MS]. В результате, регулирование нагрузкой происходит более плавно. А у "динамического CRO" мы получаем только два состояния: Сота "открыта" и "закрыта".
А в случае нехватки SDCCH - есть "динамический SDCCH".

Пока писал, на ум пришло сравнение: Идею "динамического CRO" можно уподобить регулировке напора воды в кране методом периодического перекрытия крана на доли секунд

[ИльяШ]

Для защиты от локальных перегрузок существуют иные механизмы. Пример: "Traffic Reason Handover" у Нокии. Смысл в том, что BSC или MSC оценивает нагрузку на соту (в реальном времени) и при достижении определенного порога инициирует ряд хэндоверов с загруженной соты на более свободные. При этом, естественно, учитываются уровни сигналов [cоседние BTS]--->[MS]. В результате, регулирование нагрузкой происходит более плавно. А у "динамического CRO" мы получаем только два состояния: Сота "открыта" и "закрыта".
А в случае нехватки SDCCH - есть "динамический SDCCH".

Пока писал, на ум пришло сравнение: Идею "динамического CRO" можно уподобить регулировке напора воды в кране методом периодического перекрытия крана на доли секунд

А где я писал, что динамический CRO имеет только 2 состояния? Вполне их может быть и больше. Но только изменения должны происходить при критическом преиближении к перегрузкам, иначе действительно куда эффективнее работают механизмы, управляемые от коммутатора.
Но повторюсь, вы говорите о механизмах переаспределения нагрузки активных абонентов. Тут есть тонкость в том, что для такого перераспределения нужны дополнительные сигналы и ресурсы сети.
Я же говорю о режиме, когда сеть уже полумертвая, то есть звонок проходит раза с 10-15. СМС уходит раза с 3-5. Или еще круче СМС уходит раза с 10-20, а приходит только при попытке установления соединения. Или вы с таким ни разу не встречались? В таких ситуациях на помощь приходит активный нетмонитор с возможностью выбора канала, почему бы эту функцию не возложить на сеть.

[Privat]

А где я писал, что динамический CRO имеет только 2 состояния? Вполне их может быть и больше. Но только изменения должны происходить при критическом преиближении к перегрузкам, иначе действительно куда эффективнее работают механизмы, управляемые от коммутатора.

А сколько ещё может быть состояний? Нельзя забывать, что сота не знает сколько пассивных абонентов (idle) у неё имеется ---> она может только "закрыться" при "переполнении". Однако, жутко представить себе её поведение в граничном режиме.

Но повторюсь, вы говорите о механизмах переаспределения нагрузки активных абонентов. Тут есть тонкость в том, что для такого перераспределения нужны дополнительные сигналы и ресурсы сети.
Я же говорю о режиме, когда сеть уже полумертвая, то есть звонок проходит раза с 10-15. СМС уходит раза с 3-5. Или еще круче СМС уходит раза с 10-20, а приходит только при попытке установления соединения. Или вы с таким ни разу не встречались? В таких ситуациях на помощь приходит активный нетмонитор с возможностью выбора канала, почему бы эту функцию не возложить на сеть.

Тоже повторюсь, что без "постучаться" со стороны MS сеть ничего делать не должна. Должны планировщики: увеличение SDCCH либо жёстко, либо динамически. Но труба должна быть доведена до обмена с сетью. Иначе получим хаос и неконтролируемую (пусть частично) сеть. Терминатор смотрел?
[/quote]

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

Смещение границы эффективного значения сектора должно быть с учетом соотношения с/ш, что есть дополнительный вопрос в частотном планировании. Собственно, применение иерархии в структуре сети предоставляет возможность наиболее гибкой реализации перераспределения трафика, собственно, как частный случай масштабируемости решений...
Если рассматривать тривиальный случай в одном лэере, то на сервировочном секторе расширяется сигналка до максимально необходимого, а далее по условию реализуется Direct Retry на соседей. Важно понимать, что в однолэерной сети такое красиво выглядит только для Красной площади; для демонстраций это уже убогое решение, требующее задел в системе на побочные процессы, здесь как раз многоуровневые системы в очевиднейшей выгоде: демонстрации не по всему городу, поэтому директ назначается на верхние уровни, которые обслуживают большую территорию... понятен принцип?

[Barabek]

Ну чего, в самом деле зациклились на С2?
Да, идея временного запрета доступа к соте вполне может работать. Но, с таким же успехом можно задействовать и множество других параметров, например RxLevAccessMin, MSTXPowerMax, и пр. Кроме того, не стоит забывать и о том, что C2 не передается в BCCH, а вычисляется трубкой на основе четырех передаваемых переаметров (cell barred qualify, cell reselect offset, temporary offset, penalty time). А это наклдывает еще ряд сложностей на данную идею.

ps. Кстати, многоуровневая сеть, о которой вспомнил Алексей Березин, практически лишена проблемы временных локальных перегрузок. Так что, локальные перегрузки вполне можно считать "детской болезнью".

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

ps. Кстати, многоуровневая сеть, о которой вспомнил Алексей Березин, практически лишена проблемы временных локальных перегрузок. Так что, локальные перегрузки вполне можно считать "детской болезнью".

Можно так же с бескомпромиссной наглостью утвержать, что стройка сети в один один лэер - это детство планирования, ибо не технологично!

[Barabek]

Можно так же с бескомпромиссной наглостью утвержать, что стройка сети в один один лэер - это детство планирования, ибо не технологично!

Нет, конечно. Никого обижать не будем
Просто, в условиях города, многоуровневая организация - уже необходимость. И надеяться обойтись одним уровнем - утопия.

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

Нет, конечно. Никого обижать не будем
Просто, в условиях города, многоуровневая организация - уже необходимость. И надеяться обойтись одним уровнем - утопия.

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

[ИльяШ]

Читаю и не понимаю - что тут жуткого и непредсказуемого.

Система же вполне предсказуема - сначала выбираются все полноскоростные каналы - сектор переходит в полускоростной режим или перебрасывает разговоры в другие сектора - тут все в порядке и запас еще есть, динамика поддерживается за счет активного режима.

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

Я же не рассматриваю рядовые ситуации, которые происходят именно от кривого планирования сети. Берется именно обеспечение траффиком мероприятия, которое происходит несколько раз в год, например салют. Регулярно на салют выходит до миллиона людей, они все скапливаются на набережных и пытаются перезваниваться. Ради мероприятия перепланировать что-то или устанавливать оборудование бессмысленно, если только некоторое мобильное, которое не будет интерферировать с существующим. На день города на улицах было по оценкам 2.5 миллиона человек - перезваниваться можно было, чуть уйдя в глубь квартала, зная где находится сектор, который светит в противоположную сторону - связью можно было пользоваться или выбрав сектор монитором.

Просто считается, что обеспечение подобным мероприятий связью невозможно и затратно, хотя вроде как способы-то есть.

[Privat]

Читаю и не понимаю - что тут жуткого и непредсказуемого.
.........
Просто считается, что обеспечение подобным мероприятий связью невозможно и затратно, хотя вроде как способы-то есть.

Не цитирую весь пост, но имею ввиду его полностью. Из вышеизложенного вижу лишь желание видеть на дисплее, что сеть в данный момент в данном месте "лежит", что не считаю (мнение сугубо личное) необходимым и удобным по различным соображениям: в черте города и областных магистралей уже давно привык совершать звонки без вглядывания в экран, да и не всегда это удобно делать. А после набора можно и послушать "пик-пик-пик" - вывод очевиден. Далее: при таких подходах абонент может просто вывалиться из сети, а я часто в "салютных" ситуациях пользуюсь SMS, что при вываливании невозможно. А то, что в "эпицентре" события вываливание будет иметь место - это вне сомнения, т.к. соседние соты тоже перегружены. А SMS хоть через 40 минут, но дойдёт.

[ИльяШ]

Далее: при таких подходах абонент может просто вывалиться из сети, а я часто в "салютных" ситуациях пользуюсь SMS, что при вываливании невозможно. А то, что в "эпицентре" события вываливание будет иметь место - это вне сомнения, т.к. соседние сотZ ы тоже перегружены. А SMS хоть через 40 минут, но дойдёт.

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