Эта статья рассказывает о том, как устроен “подсчет денег на лету” и услуга предоплаченной (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, который вычитает из баланса деньги за фактически использованное время из последнего пятисекундного интервала.
Читайте также о том, как это все работает в роуминге