72,66
рейтинг
11 декабря 2012 в 13:19

Разработка → Как работает биллинг сотового оператора?


Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

Биллинг собирает информацию об использовании телекоммуникационных услуг, их тарификации, отвечает за выставление счетов абонентам и обработку платежей.

Есть 2 основных типа расчета:
  • Постоплата — выставление счёта за период по его итогам (postpaid)
  • И авансовая система (prepaid), когда деньги заносятся заранее.

Постоплата появилась исторически раньше, но предоплата оказалась удобнее для клиентов (контролируемее – чуть что не так, происходит отключение, а не выставляется большой счёт).

Постоплатная система


Когда абонент постополатной системы расчетов пользуется услугами оператора, то на коммутаторах генерятся специальные CDR (Charging Data Record) файлы. По сути, это обычные логи, в которых указан номер абонента, дата, время разговора/объем скачанного трафика и т.п. Биллинг же, в определенное время, (например, раз в сутки) подключается к коммутатору, закачивает себе CDRы, рассчитывает стоимость услуг и сохраняет всё в базе данных (обычно, Oracle). Затем в конце месяца абоненту выставляется суммарный счет.


Схема взаимодействия Postpaid платформы с ядром сети оператора.
CSN — circuit switching network; Представлена коммутаторами каналов (MSC).
PSN – packet switching network; Представлена коммутаторами пакетов и шлюзами (SGSN и GGSN соответственно).

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

Авансовая система


В случае авансовой тарификации оператору связи, помимо учета предоставленного объема услуг, требуется решать задачу отслеживания текущего счета абонента и в случае достижения нуля, информировать абонента/отключать предоставление услуги. Поэтому такие системы еще называют Online Charging System (OCS).

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


Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP


CAP (CAMEL Application Part) – протокол прикладного уровня стека SS7, реализующий интеллектуальные услуги в GSM/UMTS сетях (например, prepaid).


Место протокола в стеке SS7. На рисунке также представлен популярный вариант с использованием технологии SIGTRAN (расширение SS7, которое позволяет использовать протоколы “семёрки” поверх IP сети).

По этому протоколу OCS общается с сетью коммутации каналов. Вот пример тарификации исходящего голосового вызова:


Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.
  1. Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point — то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
  2. После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
  3. Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
  4. MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
  5. Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
  6. MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
  7. Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
  8. В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
  9. MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
  10. OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.


--- INVOKE ---
 A1     TAG    : A1h [1]
 1B     LEN    : 27
      --- INVOKE ID ---
 02       TAG    : 02h INTEGER
 01       LEN    : 1
 02       INVOKE ID  : 2
       === CAP ===
         --- INVOKE ---
         --- OPERATION ---
 02      TAG    : 02h INTEGER
 01      LEN    : 1
 23      OPERATION  : 35 = applyCharging
       --- APPL CHARG ---
 30        TAG    : 30h SEQUENCE
 13        LEN    : 19
         --- ACH BCC ---
 80      TAG    : 80h [0]
 0C      LEN    : 12
       --- TDC ---
 A0        TAG    : A0h [0]
 0A        LEN    : 10
         --- MAX C P D ---
 80          TAG    : 80h [0]
 03          LEN    : 3
 01 19 40        MAX C P D  : 4370


Это часть трейса. Видим, что по протоколу CAP послано сообщение applyCharging, максимальное время разговора (MAX CPD — Maximum Call Period Duration) равно 437,0 сек.


Продублирую картинку до ката: это пример общения по CAP протоколу. Можно оценить временные метки: платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.


А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

CAP-протокол может тарифицировать не только голосовые звонки – он так же способен тарифицировать интернет-соединения, SMS, MMS и так далее. Хотя на практике чаще всего для этих нужд применяются специально заточенные протоколы (DIAMETER/OSA).

OSA


OSA (Open Service Access) – открытый программный интерфейс разработанный консорциумом 3GPP и ETSI, часто используется для тарификации VAS-сервисов и мобильного интернета.

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:



  1. При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
  2. В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
  3. Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
  4. Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
  5. Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
  6. Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
  7. Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
  8. При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.



Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение


Изменение потребностей клиентов (в т.ч. увеличение объема передаваемых данных), создание новых типов услуг, влечет за собой эволюцию сети мобильного оператора, в первую очередь в области VAS-платформ и биллинговых систем.

Если тематика протоколов семейства AAA вам интересна, то позже я расскажу про RADIUS, DIAMETER и другие интересные вещи.

Ссылки


3GPP: www.3gpp.org/index.php
ETSI: www.etsi.org
OSA: www.3gpp.org/ftp/Specs/html-info/29198-01.htm
ISUP: www.asknumbers.com/SS7ISUPMessages.aspx
Автор: @ansaril3

Комментарии (43)

  • +7
    Спасибо. С удовольствием почитаю про RADIUS и DIAMETER.
  • 0
    я бы подтёр адресок SGSNa на всякий случай ;)
    • +1
      Это тестовый SGSN, спрятан за NAT'ом =)
    • +1
      а что можно сделать?) его всё равно нет в публичном интернете, а есть только в grx и своихх gprs-ных vrf-ах, а среди операторов адреса SGSN не сильно закрытая информация.
      • +1
        ну как минимум я первым делом посмотрел, чей это адрес.
        Хотя конечно тайну из этого никто не делает.
        • 0
          хм. я конечно сразу угадал, что это билайн, но что билайн армения — не додумался))
  • +1
    Вопрос для общего развития: Почему при снятии абон платы за сутки анлимит интернета (например у мегафона) и при достижении нуля на счете в течении дня (просто кончились деньги на счету), оплаченная услуга GPRS так же перестает работать?
    • 0
      Я думаю, что это сугубо алгоритмическая ошибка тарификатора. Анлимы не всегда были, и было правило, что при нуле вырубается всё. Появились анлимы, а правило это не пофиксили. Бага короче говоря, либо сознательная политика.
    • 0
      Сторого говоря, логика отключения зависит от биллинг модели на конкретной OCS. Я бы на вашем месте посмотрел в договор, по-хорошему, там должна быть описана такая ситуация.
  • 0
    AAA — интересно. Ещё интересно было бы ещё почитать о различных DPI. Опыт применения, плюсы/минусы.
  • +1
    А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

    Ну не совсем так…
    SSF (тут MSC) запрашивает квоты с целью резервирования средств под конкретную сессию, с целью избежания перерасхода средств (например смс в очереди, или конференц звонок, для них придет еще один «IDP»).
    Во время звонка SSF сообщает сколько абонент фактически использовал от ресурсов выделенных в последней квоте.
    Защиту от слишком длинных звонков проще делать на коммутаторе…

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

    Схема взаимодействия prepaid-платформы с сетью оператора

    А CAP? Как же CAP на SGSN? много где используется. Да, не поддержана оценка контента, но тем не менее, используется…

    Спецификация OSA как таковая умерла… Рекомендованный протокол — DIAMETER Gy по рекомендации 32.299… (про Gx тоже можно повспоминать)
    • 0
      strib, спасибо за развернутый комментарий.
      Про квоты и резервирование я специально не стал в этой статье упоминать, т.к. это отдельная большая тема.
      CAP для тарификации пакетной передачи данных, действительно, много где используется (CAMEL phase 3), я об этом сказал в последнем абзаце раздела CAP. Хотя, DIAMETER мне лично нравится больше =)
      • 0
        ansaril3, всегда пожалуйста. Пишите еще, с интересом почитаю )
      • 0
        у нас есть йода, он периодически допиливает диаметр словарь в вайршарке, а то некоторые AVP не декодируются.
        • 0
          xmlками не поделитесь?
  • 0
    Спасибо за материал.

    Иллюстрация позиция САР в стеке SS7 весьма знакома :) но у меня другой вопрос: в плане роуминга как используется DIAMETR/RADIUS может сталкивались?

    Я бы еще не совсем согласился с вами, что CDR'ы — это обычные логи, т.к. во-первых все таки организованны в бинарную структуру, а во-вторых могут быть переконвертированы в другие форматы для передачи биллинг информации и расширенные по полям.
    • 0
      Влезу :) В плане роуминга, при терминации сессии на HGGSN схема работы практически не меняется, только со стороны AAA и OCS\Rating учитывается LocationInformation (LAI\NAI\SAI).
      А терминацию сессии на VGGSN не встречал.
      • 0
        Кстати, по поводу схемы через гостевой VGGSN — он прекрасно описана в стандартах, но никто ее не использует. Я на последней тренинге достал спикера по поводу этой схемы, мол чего не используется, так вменяемого ответа так и не получил. Одной из возможных причин рассматривают, невозможность собрать CDR'ы/TAP'ы на своей стороне для статистики для финансового департамента, т.к. не всегда доверяют тому что приходит от DCH и своих роуминг партнеров. Спикер обещал даже уточнить следующий раз в GSMA :)
        • 0
          Организационные вопросы.
          1) DIAMETER есть не у всех. А у кого есть, со всякими VSA, различаются релизы, у некоторых он вообще RFC DCCA (в тяжелых слуаях SCAP),. Настраивать под всех — проще убиться. С точки зрения админа ААА\OCS\DPI этой схемой я заниматься бы не хотел.
          2) CAP. Смешно, но не у всех операторов есть CAP3, не говоря уже о CAP4.
          3) СОРМ
          4) Финансы и фрод менеджер хотят избежать рисков.
    • +1
      Ага, стек SS7 взял из вашей статьи (отличный цикл статей).
      В плане роуминга все работает достаточно прозрачно — «внешний» SGSN обращается к нашему GGSN (привязанному к определенной OCS), тот по определенным линкам передает на платформу location абонента, который анализируется.
      • 0
        Да нет, в целом саму схему я знаю просто не совсем понятны преимущества DIAMETR'а по сравнению с CAMEL'ом т.к. по-моему все те же процедуры. Единственно что я вижу в виде упрощений это изменение самой схему в сторону использования ресурсов гостевой сети, т.н. Local Breakout сценарий.
        • 0
          CAMEL не поддерживает оценку контента. Т.е. просто будет считаться объем передаваемый через APN. Маркетинг никогда на это не пойдет.

          С учетом того, что не у всех есть CAP3, а CAP 2 не поддерживает оценку SMS, то остается извращаться с заворотом MAP на OCS (между MSC и SMSC), использовать странные нестандартные протоколы, или прикрутить DIAMETER к SMSC и жить спокойно.

          А дальше стандартная практика унификации протоколов.

          Про CAP4 не говорю, он дорогой, вендоры за него обычно очень много хотят. Но по сравненияю с DIAMETER никаких преимуществ не дает, а расширять его сложнее.
          • 0
            не знаю что с camel, но в диаметре можно всё что угодно передать. любые параметры для отображения в детализации абонента. вот можно например в camel передать тип сети, в котором абонент сейчас находится? (gprs/edge/3g/lte)?
            • 0
              >детализации абонента. вот можно например в camel передать тип сети, в котором абонент сейчас находится?
              Разумется. LocationInformation передает тип сети.

              Зато CAMEL более или менее устоялся, а DIAMETER кто как хочет, тот так и трактует. Каждому свое место )
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      SMSC компании-хозяина звучит как-то устаршающе :)
      Тут все очень просто, легче показать на примере. Пускай СМС идет от абонента Beeline, абоненту МТСа:
      Сначала СМСка идет от абонента А (тот кто отправляет СМСку, Beeline) на SMSC (сокр. от СМС центр) той компании (Beeline) которой он принадлежит по MAP протоколу (MO Leg). Далее, SMSC обращается к OCS (Beeline) для тарификации, например, по CAP протоколу (SMSC — «можно отправлять СМСку такому-то абоненту?»; OCS — «Можно!»). Затем SMSC (Beeline) по MAP протоколу пересылает СМСку в сеть МТС (GMSC-MSC) и коммутаторы сети (МТС) доставляют сообщение на Б абонента (MT Leg). SMSC МТС не задействован.
      Таким образом, SMSC Б абонента даже не знает о входящих СМСках. Так что входящие СМСки не тарифицируются.
      • +1
        А техническая возможность сделать входящие SMS платными есть? Как организовываются платные входящие SMS в роуминге?
        • 0
          Техническая возможность всегда есть. Скажу больше, есть специальные антиспам платформы, на которые с коммутатора заворачивается входящий трафик.
          Входящие SMS бесплатны, даже в роуминге.
          • 0
            А SDP платформа у вас есть?
  • 0
    Еще бы показали листинг счета при использовании в роуминге. Мгновенный подсчет или все таки нет?
  • +1
    Спасибо, очень интересная статья.
    А чем объясняется задержки в тарификации услуг сотовой связи в роуминге? Почему ОПСОСы не могут списывать деньги со счетов в реальном времени если абонент в роуминге? Ведь тарифы роуминга (стоимость минуты и стоимость смс) заранее.
    • 0
      потому что не со всеми операторами есть camel роуминг. только и всего. что касается gprs, то нужно иметь возможность как минимум тарифицировать по cdr с ggsn, а лучше в онлайне по diameter например, но не все ggsn это могут.
      • 0
        А что зарубежные операторы используют между собой?

        Я ни разу не слышал о подобных проблемах у ребят пользующих зарубежных операторов.
    • +2
      попробовал кратко описать. habrahabr.ru/post/162269/
    • 0
      Задержки тарификации в роуминге, как ответили выше, связаны с тем, что не у всех операторов-партнеров есть CAMEL необходимой фазы.
      За Билайн могу сказать, что у нас CAMEL роуминг настроен по всем основным направлениям (за исключением совсем «диких» стран).
      • 0
        На счет билайна, кстати, да… В последних поездках с билайном за рубеж, подобных проблем не было… Но это похоже заработало 1.5-2 года назад. До этого эти проблемы были в полный рост…
  • 0
    Напишите про авторизацию абонентов на базовых станциях, предпочтения при выборе станции и прочее. в течении 2-х месяцев спецы билайна пытались найти с какой БС я совершаю вызовы, но всегда логи пропадали (постпейд).
    • 0
      Если в кратце, то решение о том, через какую базовую станцию будут передаваться данные для абонента, принимает контроллер базовых станций. У него есть сводная информация по мощности сигнала от ближайших базовых станций до абонента (как правило, телефон абонента «видит» в эфире сразу несколько БС). Контроллер постоянно обновляет и анализирует эти данные (по мощности/задержке и направлению сигнала, мы, кстати, можем определять примерное местоположение телефона абонента, без всяких GPS). При анализе учитывается не только мощность сигнала, но и, например, то к какой БС абонент подключен в текущий момент, она будет более приоритетна (что бы в случае примерно одинаковых сигналов от 2-х БС, не происходило постоянное переключение абонента между ними). Такой параметр гистерезиса задается в конфигах контроллера. Мои коллеги, занимающиеся сетью радиодоступа, по этой теме могут рассказать гораздо больше =) я занимаюсь VAS платформами.
      А аутентификация абонента происходит в не на самих базовых станциях (это всего-лишь приемник-передатчик), а в ядре сети оператора, с участием таких сетевых элементов, как HLR, EIR, AUC, MSC/VLR (или SGSN в случае регистрации в сети пакетной передачи данных — GPRS attach).
      • 0
        Возможно человек спрашивал про то, какую БС выберет мобильник при совершении звонка, а не как он будет менять их во время звонка. В этом случае решает-то всё мобильный телефон: по мощности принимаемого сигнала в одной Location Area и по мощности сигнал с учетом гистерезиса, который транслирует текущая БС, если хочется перейти в соседнюю LA, +учитывается приоритет ячейки, также транслируемый БС, ну и является ли ячейка barried, т.е. запрещенной к использованию.
        • 0
          Все верно. мобильник не мог подключится к БС при настройках 2g+3g(авто) появлялся режим «sos», отдельно в режиме 2g подключался. Специалисты не могли определить где я и на какой БС пытаюсь авторизоваться.
          • 0
            Поставьте Netmonitor и удивите полосатых своей осведомленностью )
            Он покажет ID секторов, которые видит ваш терминал…
  • 0
    Спасибо за интересную статью. Еще было бы очень интересно почитать, как это все происходит в сетях LTE. И как на практике устроена радиосеть LTE, какие функции возложены на каждый блок (eNodeB, MME, шлюзы) и как это все взаимодействует с сетями предыдущих поколений.
  • 0
    Уже куча времени прошло, но всё же:
    Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).

    Как GGSN определяет что абонент получил скачанные данные? Т.е. он должен отправлять какой-то запрос абоненту для подтверждения этой информации?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка