![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovЗаказной пост на тему: Можно ли назначить абонентам "категорию обслуживания" и при перегрузке некоторых (не важно каких) звеньев необходимых для работы "выбрасывать" низкокатегорийных, чтобы обслужить высококатегорийных. И если можно, используется ли это где нибудь?"
Короткий ответ: можно, но насколько мне известно почти нигде не используется.
Длинный ответ
В SIM-карте есть специальный elementary file (EF) под называнием ACC, который хранит информацию о доступных абоненту access class-ах. Предполагалось, что базовые станции передают по broadcast channel-у битовую маску access class-ов, которые она может обслужить, а SIM-карта сравнивает эту информацию с тем, что записано у нее в EF_ACC и принимает решение о том, может ли она использовать RACH (random access channel) для доступа к этой базовой или нет.
Идея, как я понимаю, заключалась в следующем: допустим, у нас битовая маска в 16 бит, каждый бит представляет один из классов доступа. Классы с 0 по 9 отведены для "обычных" пользователей (см. GSM 02.11, в свободном доступе я его, правда, не нашел), а классы с 10 по 15 - для спецслужб (пожарных, скорой, ...).
Чтобы обеспечить "приоритезацию" пользователей, базовая может держать биты 10-15 постоянно взведенными, а биты 0-9 взводить (не)случайным образом так, чтобы в каждый момент "допускать к кормушке" не более одного или двух классов пользователей. Учитывая, что абонент не может сам изменить ACC на своей SIM-карте, это давало бы "балансирование" нагрузки на базовую в стиле round-robin.
(Disclaimer: я человек, далекий от радиопланирования, соотв. дальше - мои измышления). Все это замечательно в теории, но как это использовать на практике в случае плотно покрытых городских областей, да не просто использовать "чтобы было", а получать это этого какую-то пользу - я не понимаю. Учитывая, что access class влияет только на доступ к RACH (по крайней мере, об этом говорит документация), речь не идет о том, что "модные" абоненты сбрасывают звонки "немодных". Речь идет только о том, кто первым получит запрошенный таймслот для голосового канала в случае, если толпа народу одновременно кинулась звонить, а этих самых таймслотов - ограниченное кол-во.
Я еще могу себе представить, что в случае какого-то стихийного бедствия оператор предоставляет свою сеть полностью в ведение спецслужб, отсекая от обслуживания классы 0-9, но на практике я никогда о таком не слышал.
Похоже, такие же проблемы с пониманием пиратствуют не только у меня - по крайней мере, я никогда не слышал об использовании этой функции в сети какого-то оператора.
PS
А если ли кнопки на мобильнике Президента - это государственная тайна, и я вам ее не раскрою :)
UPD:
Я таки нашел GSM 02.11, и вот что там написано про access class control:
Т.е. это все-таки не средство приоритезации пользователей, а механизм damage control :)
UPD 2: Есть еще GSM 02.67: "enhanced Multi-Level Precedence and Pre-emption service
(eMLPP) - Stage 1".
В нем описывается доп. услуга, которая может быть поддержана оператором и которую надо явно включать абоненту. Эта услуга действительно позволяет назначать абоненту "высокий приоритет". Обладатели этого статуса будут иметь возможность "выкидывать" из соты низкоприоритетных абонентов в случае, если все траффик-каналы заняты.
Подчеркну еще раз: это доп. возможность, которая должна поддерживаться оператором (читай - он должен купить и поставить правильные BSC, базовые, и, возможно, MSC). Какой-либо стандартной возможности получить "высокий приоритет", который будет работать всегда и везде - нет.
Короткий ответ: можно, но насколько мне известно почти нигде не используется.
Длинный ответ
В SIM-карте есть специальный elementary file (EF) под называнием ACC, который хранит информацию о доступных абоненту access class-ах. Предполагалось, что базовые станции передают по broadcast channel-у битовую маску access class-ов, которые она может обслужить, а SIM-карта сравнивает эту информацию с тем, что записано у нее в EF_ACC и принимает решение о том, может ли она использовать RACH (random access channel) для доступа к этой базовой или нет.
Идея, как я понимаю, заключалась в следующем: допустим, у нас битовая маска в 16 бит, каждый бит представляет один из классов доступа. Классы с 0 по 9 отведены для "обычных" пользователей (см. GSM 02.11, в свободном доступе я его, правда, не нашел), а классы с 10 по 15 - для спецслужб (пожарных, скорой, ...).
Чтобы обеспечить "приоритезацию" пользователей, базовая может держать биты 10-15 постоянно взведенными, а биты 0-9 взводить (не)случайным образом так, чтобы в каждый момент "допускать к кормушке" не более одного или двух классов пользователей. Учитывая, что абонент не может сам изменить ACC на своей SIM-карте, это давало бы "балансирование" нагрузки на базовую в стиле round-robin.
(Disclaimer: я человек, далекий от радиопланирования, соотв. дальше - мои измышления). Все это замечательно в теории, но как это использовать на практике в случае плотно покрытых городских областей, да не просто использовать "чтобы было", а получать это этого какую-то пользу - я не понимаю. Учитывая, что access class влияет только на доступ к RACH (по крайней мере, об этом говорит документация), речь не идет о том, что "модные" абоненты сбрасывают звонки "немодных". Речь идет только о том, кто первым получит запрошенный таймслот для голосового канала в случае, если толпа народу одновременно кинулась звонить, а этих самых таймслотов - ограниченное кол-во.
Я еще могу себе представить, что в случае какого-то стихийного бедствия оператор предоставляет свою сеть полностью в ведение спецслужб, отсекая от обслуживания классы 0-9, но на практике я никогда о таком не слышал.
Похоже, такие же проблемы с пониманием пиратствуют не только у меня - по крайней мере, я никогда не слышал об использовании этой функции в сети какого-то оператора.
PS
А если ли кнопки на мобильнике Президента - это государственная тайна, и я вам ее не раскрою :)
UPD:
Я таки нашел GSM 02.11, и вот что там написано про access class control:
4.1 Purpose
Under certain circumstances, it will be desirable to prevent MS users from
making access attempts (including emergency call attempts) or responding to
pages in specified areas of a GSM PLMN. Such situations may arise during
states of emergency, or where 1 of 2 or more co-located PLMNs has failed.
Broadcast messages should be available on a cell by cell basis indicating
the class(es) of subscribers barred from network access.
The use of this facility allows the network operator to prevent overload of
the access channel under critical conditions.
It is not intended that access control be used under normal operating
conditions.
Т.е. это все-таки не средство приоритезации пользователей, а механизм damage control :)
UPD 2: Есть еще GSM 02.67: "enhanced Multi-Level Precedence and Pre-emption service
(eMLPP) - Stage 1".
В нем описывается доп. услуга, которая может быть поддержана оператором и которую надо явно включать абоненту. Эта услуга действительно позволяет назначать абоненту "высокий приоритет". Обладатели этого статуса будут иметь возможность "выкидывать" из соты низкоприоритетных абонентов в случае, если все траффик-каналы заняты.
Подчеркну еще раз: это доп. возможность, которая должна поддерживаться оператором (читай - он должен купить и поставить правильные BSC, базовые, и, возможно, MSC). Какой-либо стандартной возможности получить "высокий приоритет", который будет работать всегда и везде - нет.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-11-13 04:06 pm (UTC)(no subject)
Date: 2006-11-14 08:17 am (UTC)(no subject)
Date: 2006-11-13 04:29 pm (UTC)Ну тогда Вам будет интересно знать, что приоретизация испытывалась во время 300 летия СПб одним из операторов :) Результаты мне не известны, знаю что работало.
Есть один прикол из этой области - если БС полностью загружена, то при совершении вызова под этой БС мы получим "network busy". Если мы попали в такую ситуацию, можно позвонить 112, завершить звонок и сразу же попытаться совершить обычный вызов. Тут дело в том, что при звонке на 112 в перегруженой соте один из абонентов будет сброшен для освобождения места под экстренный вызов. Я пробовал, работало :)
(no subject)
Date: 2006-11-13 05:16 pm (UTC)(no subject)
Date: 2006-11-13 05:19 pm (UTC)(no subject)
Date: 2006-11-13 05:26 pm (UTC)а рубрика - просто класс, читаю и радуюсь
(no subject)
Date: 2006-11-14 08:21 am (UTC)Достаточно ли при обращении по RACH выставить себе emergency acc class, или надо еще и звонить именно на 112? И кто сбрасывает одного из абонентов - BSC или MSC? И что при этом будет в качестве reason-а прекращения звонка?
/me полез за документацией по "любимым" коммутаторам.
(no subject)
Date: 2006-11-14 08:34 am (UTC)(no subject)
Date: 2006-11-13 07:19 pm (UTC)(no subject)
Date: 2006-11-14 08:24 am (UTC)Рассмотрим двух абонетов - A и B, которые
сидели на трубепользуются услугами оператора связи X. Допустим, что абонент A пользуется postpaid формой обслуживания, а абонент B - prepaid, причем сервис prepaid у оператора X реализован на IN-платформеНа практике, это означает, что в коммутации звонков абонента B принимает участие на одну "железку" больше, чем в коммутации звонков абонента А.
И если эта железка глючит/защищает себя от перегрузок при помощи "call gapping"/..., то абонент B будет чаще страдать от необслуженых вызовов, чем абонент А.
(no subject)
Date: 2006-11-14 03:19 pm (UTC)А еще вопрос, интересно как устроен gprs. Он задействует те же, я не знаю как назвать, каналы, наверное, что и голосовой трафик или какие-то другие? Скажем в новогоднюю ночь, когда вся сеть стабильно busy, gprs будет работать или тоже станет недоступен?
(no subject)
Date: 2006-11-17 10:21 pm (UTC)(no subject)
Date: 2006-11-19 12:59 pm (UTC)(no subject)
Date: 2006-11-15 12:58 pm (UTC)Тогда очень странно, что в такой изначально прекрасно продуманной системе нет нормального механизма приоритезации, при наличии досточно большого числа узких мест. :-(
(no subject)
Date: 2006-11-17 09:50 pm (UTC)(no subject)
Date: 2006-11-13 09:03 pm (UTC)(no subject)
Date: 2006-11-14 08:14 am (UTC)Male role model, все такое :)
(no subject)
Date: 2006-11-13 09:39 pm (UTC)Но нужная ли это настолько фича? Разве перед друзьями в новогоднюю ночь выпендрится. Или есть смысл?
(no subject)
Date: 2006-11-14 08:16 am (UTC)А дальше мы выходим в город, а вокруг нас - базовые, у которых все 16 бит "взведены". Спрашивается в задаче - "и шо це йому дало?"
:)
(no subject)
Date: 2006-11-14 09:44 am (UTC)(no subject)
Date: 2006-11-14 09:58 am (UTC)(no subject)
Date: 2006-11-14 10:19 am (UTC)(no subject)
Date: 2006-11-17 06:16 am (UTC)(no subject)
Date: 2006-11-17 06:15 am (UTC)(no subject)
Date: 2006-11-14 08:35 am (UTC)(no subject)
Date: 2006-11-14 04:33 am (UTC)> свою сеть полностью в ведение спецслужб, отсекая от обслуживания классы 0-9, но на практике я
> никогда о таком не слышал.
это было бы по меньшей мере глупо. а как в эти самые службы будут звонить бедолаги, терпящие бедствие?
насколько я в курсе..
Date: 2006-11-14 06:56 am (UTC)sms-центр при этом используется отдельный.
Re: насколько я в курсе..
Date: 2006-11-14 08:25 am (UTC)Re: насколько я в курсе..
Date: 2006-11-14 08:29 am (UTC)Re: насколько я в курсе..
Date: 2006-11-14 08:36 am (UTC)(no subject)
Date: 2006-11-14 07:13 am (UTC)(no subject)
Date: 2006-11-14 08:26 am (UTC)Оффтопик.
Date: 2006-11-14 07:25 am (UTC)А как вообще устроена документация на GSM? Структура, необходимость соответствия для MS/BS/whatever, доступность.
Re: Оффтопик.
Date: 2006-11-14 08:28 am (UTC)Точно не помню, но
Date: 2006-11-24 08:03 am (UTC)а ACC class используется также для overload handling. тоесть просто вырубаем часть пользователей при AGCH overload, у сименса покрайней мере.
Re: Точно не помню, но
Date: 2006-11-24 01:50 pm (UTC)Про overload handling - а кто управляет эти механизмом? Я правильно понимаю, что BSC? Т.е. он при обнаружении перегрузки просто начинает "играться" классами, "светя" одни и убирая другие случайным образом, или же там четко указывается, кого лишаем доступа к телу?
Re: Точно не помню, но
Date: 2006-11-29 02:19 pm (UTC)Directed Retry - отношения к приоритетам не имеет посему, о нем промолчим.
preemption - выкидываем менее приоритетного абонента из соты(ho/REL), если канал запросил высокоприоритетный абонент.
queueing - Если нет свободного TCH и нет возможности сделать Directed Retry, ставим в очередь, которая для каждого приоритета своя.
Все это может комбинироваться, ну покрайней мере, так заявляется.
Точно сказать не могу, но судя по тому, при preemption MSC->BSC шлет информацию о приоритетности, а Asub вроде стандартизирован(?) то подобный механизм должен быть и у других вендоров.
Подозреваю, для того чтобы узнать более надо рыть в сторону eMLPP.
По поводу overload handling. Все правильно управляет BSC, ставит запрет на доступ определенных ACC(0..5 или/и 6..9) при перегрузке по AGCH.
Re: Точно не помню, но
Date: 2006-11-29 02:41 pm (UTC)(no subject)
Date: 2010-02-24 09:14 am (UTC)