?

Log in

No account? Create an account
dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
GSM: как устроен "быстрый" pre-paid изнутри (IN-платформы, SSP/SCP, ...) 
21st-Nov-2006 05:20 pm
Заказной пост для кучи народа, которая спрашивала, как устроен "подсчет денег на лету" и prepaid.

Я начну с того, что расскажу в двух словах о технологиях и системах, которые сделали возможным гибкий call control, и уже потом покажу, как на их основе реализуется prepaid-сервис.

Краткий экскурс в историю (мобильного) телекома

Сначала появились динозавры. Потом они вымерли, и появились люди.

Потом люди научились говорить. Потом им надоело говорить с соседями. И они придумали телефон.

У телефона были провода, они втыкались в коммутатор. На коммутаторе сидела барышня, и соединяла провода с другими проводами, чтобы нужные люди могли поговорить друг с другом.

Потом барышню заменили на педальнодекадно-шаговый механизм и получились первые АТС - автоматические телефонные станции.

(Все дальнейшее происходило в основном за пределами СССР).

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

Где-то в 60-х производители додумались хранить логику коммутации в виде сменных ППЗУ. Внедрение новых сервисов пошло веселее.

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

Где-то к середине 70-х производители коммутаторов разделили "сигнальную информацию" и "голосовой канал" - раньше и то, и другое бегало "по одному проводу". Появилась возможность сначала проверить, сможем ли мы соединить абонентов, а потом уже собственно создавать канал для голоса. Средства передачи сигнализации назвали Common Channel Signaling Network (CCSN). Поверх CCSN "накрутили" протокол передачи сигнализации.

Протокол этот сделали стандартным и общим для коммутаторов разных типов. Так появилась Signalling System 7, она же SS7, она же "седьмая сигнализация", она же "семерка".

Пришли 80-е. Абоненты (а может - отделы маркетинга?) скандировали: "Сервисы! Сервисы! Нам нужные новые модные сервисы!". Производители коммутационного оборудования напряглись и родили очередную умную мысль - логика предоставления сервисов может быть вынесена за пределы коммутатора! Она будет жить на отдельном application server-е, к которому коммутатор будет обращаться с просьбой "что-то сделать".

Если функциональность сервисов будет жить отдельно от коммутаторов, то мы сможем внедрять новые сервисы и улучшать старые не трогая коммутатор вообще.

Сказано-сделано. Такие application server-ы для телекома тут же были созданы и получили название IN - Intelligent Network. Что за фигня!, - подумали инженеры, - все знают, что акронимы должны быть из трех букв, а не из двух! Чтобы исправить положение, инженеры стали говорить, что в паре MSC-IN коммутатор занимается коммутацией и выполняет роль service switching point (SSP), а IN - управляет предоставлением сервисов, и выполняет роль service contol point (SCP).

Повторим, чтобы не запутаться: MSC - это пример SSP, а IN - это пример SCP . Вот и отлично, вот и свели все к любимым трехбуквенным сокращениям :)

Вот как это выглядит на картинке:


Как IN (SCP) взаимодействует с MSC (SSP)

Понятное дело, что интерфейс между SSP и SCP тоже некисло было бы иметь стандартным и унифицированным. Сделано это было следующим образом - собравшись в кучу, производители коммутаторов нарисовали блок-схему Стандартного Исходящего Звонка и блок-схему Стандартного Входящего Звонка, со всеми возможными вариантами и ответвлениями. По-английски такая схема называется call model.

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

Примерно так (это очень упрощенная т.н. Basic Call Model, на непонятные выноски внимания не обращайте):


После того, как Call Model была готова, договорились о следующем - на модели отмечается определенное количество так называемых detection points (DP), по достижении которых коммутатор должен проверить, не нужно ли ему в этом месте обратиться к SCP?

Для этого коммутатор обращается к внешней базе (для мобильных сетей это HLR), которая хранит список активных detection points для каждого абонента.

Обращаясь к SCP, коммутатор отдает ему всю известную на настоящий момент информацию о звонке, а SCP, возвращая управление, может ее "подправить" - например, изменить набраный абонентом номер.

Как с помощью всей этой фигни сделать prepaid?

У всех prepaid-абонентов активно сразу несколько detection points - сразу после набора номера, периодически в ходе звонка и после окончания звонка. Типичный звонок происходит таким образом:

Абонент набирает номер и нажимает кнопку "вызов".

Коммутатор перед началом коммутации звонка вынимает из HLR-а информацию о detection point-ах и адресе IN-платформы, которая их "обслуживает", после чего начинает исполнять call model.

Тут же коммутатор видит detection point "после набора номера" и передает управление IN. В базе IN хранится баланс prepaid-абонента, и IN проверяет, достаточно ли денег для установления звонка. Допустим, их достаточно, и IN резервирует ("вычитает в уме") деньги за, допустим, 5 секунд звонка по указанному направлению. После чего IN возвращает управление MSC, ничего не меняя в сигнальной информации.

Абонент разговаривает, а коммутатор периодически (допустим, раз в пять секунд) отрабатывает detection point "в процессе звонка" и передает управление на IN. Тот вычитает из баланса зарезервированные деньги за прошедшие пять секунд и пытается зарезервировать деньги на следующие пять секунд. Если деньги закончились, то IN возвращает управление MSC с просьбой перенаправить звонок на номер автоответчика "Бабло закончилось!".

Если же денег хватило вплоть до конца разговора, то после его завершения MSC отрабатывает detection point "конец звонка", опять отдает управление IN, который вычитает из баланса деньги за фактически использованное время из последнего пятисекундного интервала.

В следующей серии - рассказ о том, как это все работает в роуминге.
Comments 
21st-Nov-2006 03:34 pm (UTC)
Совершенно праздный вопрос. А нельзя ли prepaid сделать так: При поступлении звонка вычисляется стоимость секунды данного конкретного звонка, и исходя из остатка передается MSC максимальное количество секунд (если MSC умеет команду "отрубить через N секунд") или по исходу этого количества секунд передаем сигнал MSC с просьбой перенаправить звонок на номер автоответчика "Бабло закончилось!".
Если можно, то почему бы так не сделать, всмето того чтобы MSC и IN каждые пять секунд дергать друг друга, создавая трафик и нагрузку.
21st-Nov-2006 04:24 pm (UTC)
За время разговора может смениться его стоимость. Например, наступило или закончилось льготное время.
21st-Nov-2006 04:31 pm (UTC)
- И даже в этом случае количество минут можно выщитать наперед.
- обычно на припейде никто таким не заморачивается
21st-Nov-2006 05:20 pm (UTC)
А если он при этом сменит тарифный план? Да не, число подобных вариантов достаточно велико, я взял первое попавшееся. Есть такой вариант -- перерасчёт стоимости (например, досъём денег за какую-то услугу).
27th-Nov-2006 09:30 am (UTC)
А как біть если абоненту надо начислить одну сумму а потом наложить бонус в зависимости от наговоренного. Ну или несколько бонусов;)
21st-Nov-2006 04:32 pm (UTC)
Что-то мне сомнительно, чтобы MSC такие команды выполнял. Явно нетривиальная и небазовая функциональность.
21st-Nov-2006 07:06 pm (UTC)
Стандартный CISCOвский скрипт так и устроен. Одно плохо - сложные тарифные планы не работают.
22nd-Nov-2006 08:10 am (UTC)
А кто такой "стандартный CISCOвский скрипт"?
22nd-Nov-2006 10:32 am (UTC)
CISCO-вские NAS с функциями VoIP содержат в себе SCP, который умеет выполнять Tcl или VoiceXML. И вот в стандартной поставке есть скрипт 'prepaid_card.tcl' (с модификации которого, как правило, начинается каждый второй скрипт VoIP оператора), где у биллинга спрашивается credit_time и шедулиться call_shutdown по его истечению.
22nd-Nov-2006 02:02 pm (UTC)
Вот когда абонент этого NAS уедет в роуминг, и там у него (допустим) сработает call forward on busy, вследствии чего этому NAS-у прийдется считать деньги параллельно за обе "ноги" звонка сразу, тут мы и поглядим, насколько такое решение жизненно ;)
22nd-Nov-2006 02:35 pm (UTC)
А где ты у VoIP провайдера роуминг видел ?
22nd-Nov-2006 03:59 pm (UTC)
Это я параллели провожу в продолжени разговора о том, почему подход "сразу прикинем на сколько времени хватит денег" плохо применим к GSM :)
22nd-Nov-2006 08:09 am (UTC)
Нельзя.

Во-первых, абонент в ходе звонка может уехать в зону обслуживания другого MSC, и уже тот MSC будет продолжать обслуживать звонок, считать деньги и обрабатывать DP.

Во-вторых, бывают всякие call hold, call wait, transfer, которые будут требовать коррекции вычисленного значения и/или приостановки таймера.

В-третьих, и это самое главное - от MSC потребуется service-specific функциональность, и это самое паршивое. Это означает, что нельзя будет использовать MSC от одного поставщика, а IN - от другого.
21st-Nov-2006 04:16 pm (UTC)
А в роуминге будет гостевой регистр и передача TAP-файлов на родину...
Я, конечно, мог чего и пропустить - меня вот какой вопрос интересует. Каким макаром сейчас коммутаторы отдают CDR в обработку? Вот раньше я когда с EWSD работал - так там ставили Eicon-овскую карточку и по х.25 забирали AMA-файлы. Ну и колбасили их уже там где надо и как надо :) А сейчас как?
21st-Nov-2006 09:34 pm (UTC)
Anonymous
А разнообразно - от того же x.25 до ftp.
22nd-Nov-2006 07:38 am (UTC)
Т.е. так же, файликами? Или всё ж прогресс пошел дальше и отдаются прям непосредственно записи? Ну т.е. интересует вопрос, каким образом можно узнать приблизительный уменьшившийся баланс прям через очень короткий промежуток времени после звонка.
22nd-Nov-2006 08:02 am (UTC)
Или всё ж прогресс пошел дальше и отдаются прям непосредственно записи?

Если хочется получать "записи" - то надо изображать из себя SCP и получать всю инфу в реальном времени :) Про это тоже будет отдельный пост ...

22nd-Nov-2006 08:28 am (UTC)
почти на всех станциях есть порты, куда валится статистика в реальном режиме времени, аналог start/stop записей в RADIUS. Правда никто не гарантирует, что туда попадает все. Ну а по X.25 (когда же он сдохнет то наконец...) потом можно забрать файлик и сравнить.
22nd-Nov-2006 08:01 am (UTC)
А в роуминге будет гостевой регистр и передача TAP-файлов на родину...

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

А для (анонимного) prepaid абонента такого роуминга не будет. Т.к. народ будет наговаривать на многие килобаксы и просто выкидывать симку.

Следующий пост будет о том, как работает prepaid в роуминге.

Вот раньше я когда с EWSD работал - так там ставили Eicon-овскую карточку и по х.25 забирали AMA-файлы. А сейчас как?

А примерно так же. Разве что в коммутаторах появилось ethernet, tcp/ip и ftp :)
Для любителей FTAM/CMISE появился заапгрейдженный вариант - стэк протоколов Q3.
This page was loaded Oct 19th 2018, 6:54 am GMT.