Мобильные операторы получают массу данных и метаданных, по которым можно узнать очень многое о жизни отдельно взятого абонента. А поняв, как обрабатываются и как хранятся эти данные, вы сможете отследить всю цепочку прохождения информации от звонка до списания денег. Если же говорить о модели внутреннего нарушителя, то здесь возможности и подавно огромные, ведь защита данных вообще не входит в задачи систем предбиллинга мобильного оператора.
Для начала нужно учитывать, что абонентский трафик в сети телеком-оператора генерируется и поступает с разного оборудования. Это оборудование может формировать файлы с записями (файлы CDR, логи RADIUS, текст в ASCII) и работать по разным протоколам (NetFlow, SNMP, SOAP). И нужно контролировать весь этот веселый и недружный хоровод, снимать данные, обрабатывать и передавать дальше в биллинговую систему в формате, который будет предварительно стандартизован.
При этом везде бегают абонентские данные, доступ к которым желательно не предоставлять посторонним. Насколько защищена информация в такой системе с учетом всех цепочек? Давайте разбиремся.
Зачем предбиллинг операторам мобильной связи?
Считается, что абоненты хотят получать все более новые и современные виды услуг, но нельзя постоянно менять для этого оборудование. Поэтому реализацией новых услуг и способами их предоставления должен заниматься предбиллинг — это его первая задача. Вторая — анализ трафика, проверка его корректности, полноты загрузки в абонентский биллинг, подготовка данных для биллинга.
С помощью предбиллинга реализованы различные сверки и дозагрузки данных. Например, сверка состояния услуг на оборудовании и в биллинге. Бывает, абонент пользуется услугами при том, что в биллинге он уже заблокирован. Либо он пользовался услугами, но с оборудования не поступили записи об этом. Ситуаций может быть множество, большинство таких моментов и решается с помощью предбиллинга.
Когда-то я писал курсовую работу по оптимизации бизнес-процессов компании и расчету ROI. Проблема с расчетом ROI была не в том, что не было исходных данных, — я не понимал, какой «линейкой» их мерить. Примерно так же часто бывает с предбиллингом. Можно бесконечно настраивать и улучшать обработку, но всегда в какой-то момент обстоятельства и данные сложатся так, что произойдет исключение. Можно идеально выстроить систему работы и мониторинга вспомогательных систем биллинга и предбиллинга, но невозможно обеспечить бесперебойную работу оборудования и каналов передачи данных.
Поэтому и существует дублирующая система, которая занимается проверкой данных в биллинге и данных, ушедших от предбиллинга в биллинг. Ее задача — поймать то, что ушло с оборудования, но по какой-то причине «не легло на абонента». Эту роль дублирующей и контролирующей предбиллинг системы обычно играет FMS — Fraud Management System. Конечно, ее основное предназначение — вовсе не контроль предбиллинга, а выявление мошеннических схем и, как следствие, мониторинг потерь и расхождений данных с оборудования и биллинговых данных.
На самом деле вариантов использования предбиллинга очень много. Например, это может быть выполнение сверки между состоянием абонента на оборудовании и в CRM. Такая схема может выглядеть следующим образом.
1. С помощью предбиллинга по SOAP получаем данные с оборудования (HSS, VLR, HLR, AUC, EIR).
2. Преобразуем исходные RAW-данные в нужный формат.
3. Делаем запрос в смежные системы CRM (базы данных, программные интерфейсы).
4. Производим сверку данных.
5. Формируем записи-исключения.
6. Делаем запрос в систему CRM на синхронизацию данных.
7. Итог — абонент, качающий фильм в роуминге в ЮАР, блокируется с нулевым балансом и не уходит в дикий минус.
Еще один пример использования — накопление данных и дальнейшая их обработка. Такой вариант возможен, когда у нас тысячи записей с оборудования (GGSN-SGSN, телефония): выбрасывать все эти записи в детализацию абонента — полнейшее безумие, не говоря уже о том, что мы адски нагружаем все системы таким количеством мелких данных. По этой причине подойдет следующая схема, которая разрешает проблему.
1. Получение данных с оборудования.
2. Агрегация данных на предбиллинге (ждем, когда соберутся все нужные записи по какому-либо условию).
3. Отправка данных в конечный биллинг.
4. Итог — вместо 10 тысяч записей мы отправили одну с агрегирующим значением счетчика потребленного интернет-трафика. Сделали всего один запрос к базе данных и сэкономили кучу ресурсов, включая электричество!
Чтобы было понятнее, как это работает и где здесь могут возникнуть проблемы, давайте возьмем систему предбиллинга Hewlett-Packard Internet Usage Manager (HP IUM, в обновленном варианте eIUM) и на ее примере посмотрим, как работает подобный софт.
Представьте большую мясорубку, в которую бросают мясо, овощи, буханки хлеба — все, что только можно. То есть на входе самые разные продукты, но на выходе все они приобретают одинаковую форму. Мы можем поменять решетку и получим на выходе другую форму, но принцип и путь обработки наших продуктов останется прежний — шнек, нож, решетка. Это и есть классическая схема предбиллинга: сбор, обработка и вывод данных. В предбиллинге IUM звенья этой цепочки называются encapsulator, aggregator и datastore.
Тут необходимо понимать, что на входе у нас должна присутствовать полнота данных — некий минимальный объем информации, без которого дальнейшая обработка бесполезна. При отсутствии какого-то блока или элемента данных мы получаем ошибку или предупреждение, что обработка невозможна, так как операции не могут быть выполнены без этих данных.
Поэтому очень важно, чтобы оборудование формировало файлы-записи, которые имели бы строго определенный и установленный производителем набор и тип данных. Каждый тип оборудования — отдельный обработчик (коллектор), который работает только со своим форматом входных данных. Например, нельзя просто так взять и закинуть файл с оборудования CISCO PGW-SGW с интернет-трафиком мобильных абонентов на коллектор, который обрабатывает поток с оборудования фиксированной связи Iskratel Si3000.
Если мы так сделаем, то в лучшем случае получим исключение при обработке, а в худшем у нас встанет вся обработка конкретного потока, так как обработчик-коллектор упадет с ошибкой и будет ждать, пока мы не решим проблему с «битым» с его точки зрения файлом. Здесь можно заметить, что все системы предбиллинга, как правило, критично воспринимают данные, на обработку которых не был настроен конкретный обработчик-коллектор.
Изначально поток разобранных данных (RAW) формируется на уровне энкапсулятора и уже здесь же может быть подвергнут преобразованиям и фильтрации. Так делается, если нужно до схемы агрегации произвести с потоком изменения, которые должны быть в дальнейшем применены ко всему потоку данных (когда он будет проходить через различные схемы агрегации).
Для начала нужно учитывать, что абонентский трафик в сети телеком-оператора генерируется и поступает с разного оборудования. Это оборудование может формировать файлы с записями (файлы CDR, логи RADIUS, текст в ASCII) и работать по разным протоколам (NetFlow, SNMP, SOAP). И нужно контролировать весь этот веселый и недружный хоровод, снимать данные, обрабатывать и передавать дальше в биллинговую систему в формате, который будет предварительно стандартизован.
При этом везде бегают абонентские данные, доступ к которым желательно не предоставлять посторонним. Насколько защищена информация в такой системе с учетом всех цепочек? Давайте разбиремся.
Зачем предбиллинг операторам мобильной связи?
Считается, что абоненты хотят получать все более новые и современные виды услуг, но нельзя постоянно менять для этого оборудование. Поэтому реализацией новых услуг и способами их предоставления должен заниматься предбиллинг — это его первая задача. Вторая — анализ трафика, проверка его корректности, полноты загрузки в абонентский биллинг, подготовка данных для биллинга.
С помощью предбиллинга реализованы различные сверки и дозагрузки данных. Например, сверка состояния услуг на оборудовании и в биллинге. Бывает, абонент пользуется услугами при том, что в биллинге он уже заблокирован. Либо он пользовался услугами, но с оборудования не поступили записи об этом. Ситуаций может быть множество, большинство таких моментов и решается с помощью предбиллинга.
Когда-то я писал курсовую работу по оптимизации бизнес-процессов компании и расчету ROI. Проблема с расчетом ROI была не в том, что не было исходных данных, — я не понимал, какой «линейкой» их мерить. Примерно так же часто бывает с предбиллингом. Можно бесконечно настраивать и улучшать обработку, но всегда в какой-то момент обстоятельства и данные сложатся так, что произойдет исключение. Можно идеально выстроить систему работы и мониторинга вспомогательных систем биллинга и предбиллинга, но невозможно обеспечить бесперебойную работу оборудования и каналов передачи данных.
Поэтому и существует дублирующая система, которая занимается проверкой данных в биллинге и данных, ушедших от предбиллинга в биллинг. Ее задача — поймать то, что ушло с оборудования, но по какой-то причине «не легло на абонента». Эту роль дублирующей и контролирующей предбиллинг системы обычно играет FMS — Fraud Management System. Конечно, ее основное предназначение — вовсе не контроль предбиллинга, а выявление мошеннических схем и, как следствие, мониторинг потерь и расхождений данных с оборудования и биллинговых данных.
На самом деле вариантов использования предбиллинга очень много. Например, это может быть выполнение сверки между состоянием абонента на оборудовании и в CRM. Такая схема может выглядеть следующим образом.
1. С помощью предбиллинга по SOAP получаем данные с оборудования (HSS, VLR, HLR, AUC, EIR).
2. Преобразуем исходные RAW-данные в нужный формат.
3. Делаем запрос в смежные системы CRM (базы данных, программные интерфейсы).
4. Производим сверку данных.
5. Формируем записи-исключения.
6. Делаем запрос в систему CRM на синхронизацию данных.
7. Итог — абонент, качающий фильм в роуминге в ЮАР, блокируется с нулевым балансом и не уходит в дикий минус.
Еще один пример использования — накопление данных и дальнейшая их обработка. Такой вариант возможен, когда у нас тысячи записей с оборудования (GGSN-SGSN, телефония): выбрасывать все эти записи в детализацию абонента — полнейшее безумие, не говоря уже о том, что мы адски нагружаем все системы таким количеством мелких данных. По этой причине подойдет следующая схема, которая разрешает проблему.
1. Получение данных с оборудования.
2. Агрегация данных на предбиллинге (ждем, когда соберутся все нужные записи по какому-либо условию).
3. Отправка данных в конечный биллинг.
4. Итог — вместо 10 тысяч записей мы отправили одну с агрегирующим значением счетчика потребленного интернет-трафика. Сделали всего один запрос к базе данных и сэкономили кучу ресурсов, включая электричество!
Чтобы было понятнее, как это работает и где здесь могут возникнуть проблемы, давайте возьмем систему предбиллинга Hewlett-Packard Internet Usage Manager (HP IUM, в обновленном варианте eIUM) и на ее примере посмотрим, как работает подобный софт.
Представьте большую мясорубку, в которую бросают мясо, овощи, буханки хлеба — все, что только можно. То есть на входе самые разные продукты, но на выходе все они приобретают одинаковую форму. Мы можем поменять решетку и получим на выходе другую форму, но принцип и путь обработки наших продуктов останется прежний — шнек, нож, решетка. Это и есть классическая схема предбиллинга: сбор, обработка и вывод данных. В предбиллинге IUM звенья этой цепочки называются encapsulator, aggregator и datastore.
Тут необходимо понимать, что на входе у нас должна присутствовать полнота данных — некий минимальный объем информации, без которого дальнейшая обработка бесполезна. При отсутствии какого-то блока или элемента данных мы получаем ошибку или предупреждение, что обработка невозможна, так как операции не могут быть выполнены без этих данных.
Поэтому очень важно, чтобы оборудование формировало файлы-записи, которые имели бы строго определенный и установленный производителем набор и тип данных. Каждый тип оборудования — отдельный обработчик (коллектор), который работает только со своим форматом входных данных. Например, нельзя просто так взять и закинуть файл с оборудования CISCO PGW-SGW с интернет-трафиком мобильных абонентов на коллектор, который обрабатывает поток с оборудования фиксированной связи Iskratel Si3000.
Если мы так сделаем, то в лучшем случае получим исключение при обработке, а в худшем у нас встанет вся обработка конкретного потока, так как обработчик-коллектор упадет с ошибкой и будет ждать, пока мы не решим проблему с «битым» с его точки зрения файлом. Здесь можно заметить, что все системы предбиллинга, как правило, критично воспринимают данные, на обработку которых не был настроен конкретный обработчик-коллектор.
Изначально поток разобранных данных (RAW) формируется на уровне энкапсулятора и уже здесь же может быть подвергнут преобразованиям и фильтрации. Так делается, если нужно до схемы агрегации произвести с потоком изменения, которые должны быть в дальнейшем применены ко всему потоку данных (когда он будет проходить через различные схемы агрегации).