В настоящее время все больше и больше компаний хотели бы использовать рейтинг AAA GW в режиме реального времени, однако они сталкиваются с множеством вопросов. В этой статье мы ответим на некоторые из них, сравним традиционный пакетный рейтинг с рейтингом в реальном времени и покажем некоторые преимущества последнего.
При обычной пакетной оценке все данные о событиях считываются из файлов CDR/EDR уже после завершения событий. Данные события обрабатываются, оцениваются и начисляются.
При рейтинге в режиме реального времени данные обрабатываются, когда события пытаются произойти или даже находятся в процессе. События авторизуются, повторно авторизуются и, в конце концов, тарифицируются.
При планировании системы реального времени необходимо разработать ее таким образом, чтобы свести к минимуму возможность прерывания услуг или потери доходов. Чтобы свести их к минимуму, необходимо учитывать такие факторы, как задержка, архитектура высокой доступности, разделение cm/dm на услуги для упрощения обслуживания производства и эффективный мониторинг.
С тарификацией в режиме реального времени предоплаченные и постоплатные пользователи могут быть размещены в одной системе - такая система называется конвергентным биллингом. Биллинг в реальном времени предлагает еще больше преимуществ, например, кредитные лимиты по постоплате и обратную связь в реальном времени после использования услуг клиентом.
В одной из следующих статей будет представлена более подробная информация о AAA GW, процессе взаимодействия для звонков (mbi,) и gprs/mms/sms (diameter.) Следите за нами в Twitter и оставайтесь с нами.
Здравствуйте,
Это снова я. Меня интересует Ваш рейтинг в реальном времени. В настоящее время я оцениваю архитектуру, заложенную нашим СИ. Я не буду называть никаких имен. Как Вы классифицируете архитектуру как высокую доступность? Любой может заявить, что его архитектура - это HA, но насколько HA является действительно хорошей HA? Какие переменные необходимо учитывать? Есть ли конкретная формула, на которую я могу сослаться?
Еще один вопрос, касающийся AAA с использованием протокола diameter. Мы используем конвейер для обработки пакетов диаметра, менеджер диаметра здесь не внедрен. Где я могу найти файл журнала, потому что в те дни, когда IPT менеджер все еще существовал, вы можете найти файлы журнала пакетов в $PIN_HOME/apps/radius_ipt/radius_ipt.log, но для пакетов диаметра, я не знаю.
Пожалуйста, посоветуйте.
Заранее спасибо.
С уважением,
-Аязул
Здравствуйте, Аязул,
Наше описание высокой доступности - это способность системы поддерживать производительность после выхода из строя одного или нескольких серверов. Основным компонентом высокой доступности является обход отказа, то есть возможность для клиентских соединений переходить с неработающего сервера на работающий в случае отказа сервера, что позволяет клиентским приложениям продолжать работать.
Мы согласны с Вашим утверждением, что любой может заявить, что его/ее архитектура - это HA. Тем не менее, дать простой ответ на Ваши вопросы не представляется возможным. Сначала мы должны проанализировать архитектуру HA клиента, а затем провести необходимое тестирование.
Что касается второго вопроса, в общем случае Вы можете найти журналы диаметров в каталоге /opt/portal/pre_dia/log.
Если Вы хотите узнать больше подробностей, пожалуйста, не стесняйтесь обращаться к нам напрямую.
С наилучшими пожеланиями,
Алес
Здравствуйте,
Прошло некоторое время с момента выхода этой статьи. Мне хотелось бы знать, используете ли Вы по-прежнему Oracle BRM AAA GW или Oracle BRM ECE? Если Вы используете ECE, пожалуйста, поделитесь своим подходом, проблемами и полученными уроками.
Спасибо и наилучшие пожелания,
Хан
В среде рейтинга в реальном времени конвейер AAA GW терпит крах из-за сброса ядра памяти после обработки запросов на использование.
Проблема воспроизводится с помощью следующих действий:
1.Запустите систему рейтинга в реальном времени со следующими компонентами: AAA GW, CM, Realtime Pipeline, и DM_ORACLE
2. Отправьте запрос на трубопровод AAA GW. Этот запрос обрабатывается без проблем.
3. Через несколько минут процесс pipeline IFW создает дамп ядра.
Может ли кто-нибудь помочь в этом вопросе Oracle BRM?
Чтобы реализовать решение, выполните следующие шаги:
1. Загрузите и изучите readme последнего набора патчей.
2. Убедитесь, что Вы сделали резервную копию системы перед применением рекомендуемого набора исправлений.
3. Примените исправление в тестовой среде.
4. Проведите повторное тестирование.