Способ уведомления о входящем вызове и устройство для его осуществления
METHOD OF NOTIFYING INCOMING CALL AND DEVICE FOR ITS IMPLEMENTATION

Изобретение относится к области телефонной связи, в частности к способам уведомления абонентов сетей подвижной радиосвязи СПРС (п. 12, ГОСТ Р 53801-2010, 3GPP TS 23.002) о входящем вызове и не ограничивая объем правовой охраны может быть использовано в сетях CDMA (W-CDMA), GSM, UMTS, LTE и сетях последующих стандартов.
Общеизвестно что на экране входящего звонка мобильного устройства MS/ME (mobile station/mobile equipment) абонент СПРС распознает входящий вызов по отображаемому номеру или по информации, предварительно сохраненной в списке контактов. Полезная информация о неизвестных входящих номерах для принятия решения об ответе на вызов ему недоступна. Оповещение абонента с дополнительной полезной информацией о входящем вызове востребовано операторами СПРС и абонентами связи как услуга связи. Для абонента в роуминге услуга особенно актуальна вследствие повышенной платы за входящие звонки.
По разным оценкам MS с операционными системами (ОС) iOS и Android занимают 99,9% рынка смартфонов, их доли распределяются 1 к 4 соответственно. Есть менее известные мобильные Blackberry OS, Windows OS и другие, появляются новые, с рынка уходят не востребованные. У каждой ОС есть свои концепции управления аппаратной частью MS, ограничения и особенности. Разработчики MS периодически проводят программную доработку MS - удаленно активируют (upgrade) или деактивируют (downgrade) программные функции MS-т.н. «пере прошивка». Программные модули MS выполняющие отрисовку графического интерфейса в т.ч. уведомлений (SMS, USSD, PUSH notifications) различных ОС выполняются по разному по виду, форме и скорости отрисовки. Периодически разработчики MS изменяют или вводят новые графические API отрисовки UI (user interface) интерфейсов, отдельные функции признаются устаревшими. В этих условиях оператору СПРС необходимо решение об уведомлении о входящем вызове которое оставляет за скобками особенности программно-аппаратной архитектуры разных типов MS. В то же время проключение вызова (установления сигнального соединения по сигнальным протоколам СПРС) должно соответствовать требованиям стандартов качества услуг QoS (ГОСТ Р 53731-2009, Recommendation ITU-T Е.800), предоставляемых в СПРС. Вывод на дисплей уведомления о входящем вызове должно быть встроено в эти требования, т.е. предпочтительно чтобы технология уведомления не вмешивалась в сигнальный обмен проключения вызова. При этом уведомление абонента о входящем вызове увязано с необходимостью его отложенной отрисовки на экране MS после появления стандартного экрана входящего звонка (завершения проключения вызова). Данное требование обусловлено не только необходимостью предварительного наблюдения абонентом стандартного экрана входящего звонка и последующим анализом уведомления с дополнительной информации о вызывающей стороне, тем более если запись о вызывающей сторона есть в списке контактов абонента. Но также и программными особенностями отрисовки графического интерфейса уведомлений отдельными ОС MS, которые в противном случае отрисовываются на весь экран (full screen) и полностью перекрывают экран входящего звонка. В этом случае абонент будет лишен возможности наблюдать уведомление. Предлагаемый авторами способ уведомления о входящем вызове учитывает реализацию этих особенностей ОС MS и требований установления соединения QoS СПРС.
Задачей предлагаемого изобретения является повышение надежности способа уведомления абонента СПРС о входящем вызове, доставляемого абоненту по сигнальным протоколам на любые типы MS, при соблюдении стандартов качества предоставления услуг в СПРС.
В терминах предлагаемого изобретения сигнальная сеть оператора подвижной электросвязи включает набор сигнальных протоколов общеканальной сигнализации №7 ОКС7 (п. 102, ГОСТ Р 53801-2010) или SS7 (3GPP TS 28,29 series) - стандартизованная ITU-Т система сигнализации, связывающая элементы цифровых телекоммуникационных сетей, применяемых для установления соединения в СПРС и стандартизованных 3GPP, ITU-T, ETSI. Тип MS включает любое стандартизованное описание MS достаточное для определения связанных с радиосетями программно-аппаратных возможностей MS обслуживаемого (вызываемого) абонента, а также тип и версию его программной архитектуры., например дескриптор IMEI, MS Classmark* 3GPP TS 29.002.
Текущий уровень техники содержит ряд технических решений, раскрывающих способы уведомления абонента о входящем вызове и устройства для их реализации. При этом из внедренных преобладают способы уведомления доставляемых абоненту по пакетной сети Packet Switched (PS) Domain вне сигнальных протоколов сигнальной сети Circuit Switched (CS) Domain (3GPP TS 23.002 Technical Specification).
Стандартизованный функционал Calling Name Presentation (CNAP) ETSI (ETSI TS 101 394 V7.0.0 (1999-08)) набора стандартов CAMEL не был принят сотовыми операторами из-за сложности программно-аппаратной доработки сетевой аппаратуры. Известные патентные и информационные источники не дают ответа о технической реализации способов уведомления о входящем вызове для повсеместно используемых основных архитектур MS. В целом общим недостатком существующего уровня техники, является отсутствие технической реализации уведомления о входящем вызове с учетом различий программно-аппаратных архитектур MS и требований QoS. Более того различные протоколы уведомлений (HTTP PUSH, SMPP и др.) имеют разную последовательность, объем, структуру сообщений, разные оконечные и транзитные сетевые узлы приема-передачи на которых по-разному формируются очереди обработки сообщений. Линии связи базовой сети оператора СПРС ЕРС (Evolved Packet Core) и сети радиодоступа (Е-UTRAN, Evolved Universal Terrestrial Radio Access Network) имеют разную пропускную способность, скорость передачи данных по линиям связи переменна и зависит от текущей нагрузки-имеющейся полосы пропускания. Эти условия влияют на доставку уведомления в условиях проключения соединения по стандартам QoS. В этих условиях узел (узлы) задействованные в формировании и передаче в сеть уведомления о входящем вызове должны надежно отобразить уведомление абоненту, не нарушая требований QoS по соединению вызова.
Необходимо обобщенное решение, девальвирующее как эти отличия, так и не предполагающее вмешательства в сигнальный обмен проключения вызова, в противном случае технология не будет принята операторами СПРС.
Известно мобильное приложение - пакет «Who Calls?» от лаборатории Касперского, которое представляет собой определитель номера по информации базы данных пользователей. Из недостатков отмечается необходимость установки отдельного приложения, регистрация учетной записи, установки обновлений, это занимает время абонента и ресурсы MS, необходимость переустановки при смене MS, требует поддержки dual-mode режима, который поддерживается не всеми MS. Пакетное решение уведомления полностью развязано с сигнальной сетью оператора, что является преимуществом. Одновременно его следствием является невозможность контроля за временем отрисовки уведомления относительно времени проключения а значит появления экрана входящего звонка на экране MS. Также очевидным недостатком является необходимость обмена пакета (мобильного приложения) с соответствующим сервером - GCM (Google Cloud Messaging), для ОС Android, APNS (Apple Push Notification Service) для iOS, WNS (Windows Notification Service) для ОС Windows Phone, для отправки PUSH уведомления на MS.
Из патентных источников известны ряд технических решений-
Способ и устройство для предоставления вызываемой стороне информации о вызывающей стороне по патенту ЕР 2112811 включает запрос информации вызывающей стороны о ней и формирование сообщения с этой информацией для вызываемой стороны, в соответствии с правилом, определенным вызываемой стороной. Данное решение не учитывает механизм проключения сторон. Недостатком решения также представляется увязка способа с определенными мероприятиями на вызывающей стороне и отсутствие реализации для основных мобильных ОС.
Патент RU 2619083 описывает способ и устройство аудио оповещения о втором входящем вызове во время уже происходящего разговора. В различных вариантах реализации этого изобретения аудиоданные хранятся и/или преобразуются локально на MS абонента, если данные второго входящего вызова сохранены в списке контактов MS. В другом случае MS абонента формирует запрос на фоновый сервер о полезной информации второго входящего вызова. Фоновый сервер хранит аудиоданные по типам возможных абонентов по настройкам пользователя через локальное приложение MS. Описание изобретения не раскрывает техническую реализацию инкапсуляции аудио уведомления о втором вызове в происходящий разговор, и носит концептуальный характер, что представляется недостатком.
Патент RU 2638938 того же заявителя в общем случае расширяет предыдущее техническое решение в части совместных настроек записей фонового сервера разными пользователями. Решение также не раскрывает техническую реализацию, имеет весьма обобщенное описание и сохраняет в этой части недостатки прототипа.
Заявка на изобретение US 20150004953 описывает способ и систему предоставления вызывающей стороной информации о себе для вызываемого абонента. Техническое решение предусматривает управление уведомлением о входящем вызове вызывающей стороной с использованием промежуточного сервера конфигурации. Очевидным недостатком заявки, в контексте предлагаемого авторами решения, отмечается необходимость принятия мер вызывающей стороной для формирования уведомления о себе.
Близкой по использованию технологий коммутации, является заявка на изобретение US20060148459 описывающая варианты осуществления устройства пользователя, систему устройств (сетевых узлов) а также способ для обработки информации о вызове. Заявка концептуально, описывает способы уведомления вызываемого абонента о вызывающей стороне и оставляет за скобками меры технической реализации. Из описанных способов усматриваются три основных - посредством сообщения предварительно записанного на стороне вызывающего абонента, т.е. признака предварительного вызова (сообщения, мелодии вызова и др.), посредством USSD сервиса и выполнения SEVI апплетов (SEVI application toolkit SAT). Технически второй и третий способы коммутации с абонентом используют авторы, но суть в реализации технологии с учетом различий программно-аппаратных архитектур MS и требований QoS для формирования уведомления в сигнальной сети. Таких условий заявка американских авторов не учитывает, оставляет вне описания, что представляется недостатком и является следствием обобщенности описания. Основным же отличием а также недостатком отмечается увязка предлагаемых способов уведомления с сетевыми устройствами СПРС вызывающего абонента и использование двух каналов передачи данных о вызове от вызывающей стороны-первого канала установления вызова и второго параллельного с информацией о вызываемом абоненте. Целесообразно чтобы способ уведомления был «развязан» с какими-либо организационно-техническими мероприятиями на вызывающей стороне.
Патент US 9338286 описывает систему и метод отображения информации о вызывающей стороне включая ее профиль, геолокацию и «уровень доверия». В общем случае описанное решение уведомления опирается на данные обработки вызова т.н. сервером CAPS, и дополняется сбором данных из открытых источников. Сервер выполняющий сбор и обработку данных уведомления включает функционал, позволяющий вызывающей стороне настроить формат уведомлений. Патент сохраняет недостатки описанных выше аналогов, а именно является скорее концептуальным, не описывает техническую реализацию в приложении сигнального обмена проключения вызова, и не учитывает разнообразие архитектур MS в части формирования и отображения уведомления о вызывающей стороне.
За прототип предлагаемого способа уведомления выбран патент заявителя RU 2676615 который описывает способ уведомления абонента за счет использования дополнительных узлов СПРС - VAS (Value-Added Service) и STK сервера которые взаимодействуют между собой по внутренним интерфейсам а с стандартными узлами по стандартным протоколам СПРС, и формируют сообщение с дополнительной информацией о вызывающем абоненте по технологии SIM SAT (SIM Applications ToolKit), в том числе в интерактивной форме. Описание патента и опыт его внедрения подтверждает заявленный технический результат. За счет пассивного перехвата сигнального трафика в дополнение к взаимодействию по внутренним API интерфейсам обеспечивается существенный выигрыш времени для формирования уведомления о входящем вызове и не вмешательство в процесс его проключения. Технология SIM Applications ToolKit предоставляет возможность удаленной загрузки SIM апплета для обработки и отображения уведомления на экране MS (SIM ToolKit API Display text) сформированного и переданного сервером уведомления о входящем вызове. Хотя передача команд между слоем радиоинтерфейса RIL (Radio Interface Layer в терминах SIM SAT) и ОС MS выходит за рамки стандарта SIM SAT, в общем случае основные ОС предоставляют такое API, таким образом исключается необходимость установки пакета и его обращения к удаленным серверам (GCM, APNS, WNS) для PUSH уведомлений. Однако в связи с ограниченностью технологии SIM SAT (функционала SIM апплета) дальнейший контроль времени отрисовки уведомления относительно появления экрана входящего звонка (завершения проключения соединения) невозможен, а графический интерфейс уведомления полностью контролируется программными средствами ОС MS. По этим причинам отрисовка PUSH уведомления с дополнительной информацией о входящем вызове некоторыми типами MS может полностью перекрыть экран входящего звонка, что очевидно девальвирует для абонента пользу от уведомления. Эти сложности повлекли необходимость выработки дополнительных организационно-технических мер для надежной работы уведомления о входящем вызове в рамках QoS с учетом особенностей архитектур СПРС и различных программно-аппаратных типов MS.
Техническим результатом способа уведомления о входящем вызове является повышение надежности визуализации уведомления абонента о входящем вызове повышенной информативности в СПРС, передающегося по сигнальной сети СПРС, для любого типа программно-аппаратной реализации MS вызываемого абонента, без вмешательства в сигнальный обмен проключения вызова при соблюдении стандартов качества QoS установления вызова в СПРС.
Технический результат достигается за счет способа уведомления абонента о входящем вызове в СПРС в соответствии с которым для повышения информативности входящего вызова используют по крайней мере один дополнительный программно-аппаратный узел, непосредственно взаимодействующий с сигнальной сетью СПРС, который получает сигнальное сообщение о входящем вызове переадресованное из сети СПРС, и по крайней мере один дополнительный программно-аппаратный узел взаимодействующий с ним и с узлом биллинга СПРС который, по идентификатору вызывающего абонента формирует сообщение вызываемому абоненту с дополнительной информацией о вызывающем абоненте и передает это сообщение в СПРС по SMPP протоколу, причем дополнительный программно-аппаратный узел непосредственно взаимодействующий с сигнальной сетью СПРС, регистрирует время появления в СПРС первого сигнального сообщения установления соединения входящего вызова по протоколу САР, или по протоколу ISUP, или по протоколу SIP или по другому стандартизованному в СПРС сигнальному протоколу, передает это сообщение и время его появления в сети СПРС дополнительному программно-аппаратному узлу взаимодействующему с узлом биллинга СПРС, а дополнительный программно-аппаратный узел взаимодействующий с узлом биллинга СПРС производит передачу в СПРС SMS, USSD сообщения с дополнительной информацией о вызывающем абоненте по таймеру запущенному по полученному времени регистрации появления в СПРС первого сигнального сообщения установления соединения входящего вызова. Передача такого сообщения происходит в интервале 2-4 секунд, начиная с времени запуска таймера.
Техническим результатом устройства для уведомления о входящем вызове является повышение надежности визуализации уведомления абонента о входящем вызове повышенной информативности в СПРС, передающегося по сигнальной сети СПРС, для любого типа программно-аппаратной реализации MS вызываемого абонента, без вмешательства в сигнальный обмен проключения вызова при соблюдении стандартов качества QoS установления вызова в СПРС.
Технический результат достигается за счет устройства СПРС для уведомления о входящем вызове содержащее стандартные узлы СПРС, по крайней мере один дополнительный программно-аппаратный узел, непосредственно взаимодействующий с сигнальной сетью СПРС, выполненный с возможностью пассивного захвата сообщения о входящем вызове из сигнальной сети СПРС, и по крайней мере один дополнительный программно-аппаратный узел взаимодействующий с ним и с узлом биллинга СПРС выполненный с возможностью формирования сообщения вызываемому абоненту с дополнительной информацией о вызывающем абоненте с использованием внутренней или внешней базы данных и передачи этого сообщения в СПРС по SMPP протоколу для отображения вызываемому абоненту, причем дополнительный программно-аппаратный узел непосредственно взаимодействующий с сигнальной сетью СПРС, выполнен с возможностью регистрации времени появления в сети СПРС первого сигнального сообщения установления соединения входящего вызова, а дополнительный программно-аппаратный узел взаимодействующий с узлом биллинга СПРС выполнен с возможностью передачи в СПРС сообщения вызываемому абоненту с дополнительной информацией о вызывающем абоненте по таймеру запущенному по полученному времени регистрации появления в СПРС первого сигнального сообщения установления соединения входящего вызова.
Изобретение иллюстрируется чертежами:
На фиг. 1 показана обобщенная сетевая архитектура СПРС (NP network provider) с узлом уведомления о входящем вызове подключенным через стандартный CAMEL Gateway.
На фиг. 2 показана обобщенная сетевая архитектура СПРС (NP network provider) с дополнительными узлами регистрации входящего вызова и уведомления о нем в варианте предлагаемого изобретения.
На фиг. 3 показан стандартный сигнальный диалог предоставления услуги уведомления о входящем вызове по технологии CAMEL.
На фиг. 4 представлен сигнальный диалог предоставления услуги уведомления о входящем вызове в варианте предлагаемого изобретения.
Фиг. 1, 2 иллюстрируют сравнительную архитектуру СПРС для стандартной CAMEL реализации услуги уведомления о входящем вызове фиг. 1 и реализации предлагаемой автором фиг.2. Устройство СПРС оператора NP (network provider), для уведомления абонента о входящем вызове представленные на фиг. 1, 2 в общем случае включает стандартные узлы коммутации 3 фиг. 1, 4 фиг.2 SSP (Service Switching Point) и управления услугами 2 фиг. 1, 3 фиг.2 SCP (Service Control Point), а также мобильное устройство домашнего вызываемого абонента 4 фиг. 1, 5 фиг.2 MS (Mobil Station) для сетей CDMA, GSM, UMTS, LTE. SMSC (SMS Center СПРС) на фигурах для упрощения не показан, в контексте заявки SMSC функционально включен в SSP. В стандартной CAMEL реализации (фиг. 1) СПРС включает узел дополнительных видов обслуживания ДВО SCP WCS 1 взаимодействующий с СПРС по прикладному протоколу CAP (CAMEL application part) В предлагаемой автором архитектуре (фиг.2) СПРС включает взаимодействующие между собой узлы 1 WCS (who calls server) уведомления абонента о входящем вызове и 2 SNA (signal network analyzer) перехвата и анализа событий сигнальной сети. Под различными событиями сигнальной сети в контексте предлагаемого изобретения подразумеваются различные системные сообщения установлении вызова внутри сигнальной сети СПРС.
Узлы 1 и 2 (фиг. 2), по сути, представляют собой программно-аппаратные комплексы.
Архитектура узла 1 WCS (фиг.2) включает программно-аппаратные интерфейсы API взаимодействия с удаленной базой данных БД содержащей записи с дополнительной информацией об абонентах СПРС, API взаимодействия с узлом биллинга SCP и контроллер SMPP (Short Message Peer-to-Peer, SMS, USSD) протокола. БД (на фиг.не показана) может быть внутренняя или внешняя, в том числе БД другого оператора СПРС, или DMP (Data Management Platform), а также любая сторонняя база данных и/или любое программное обеспечение, которое позволяет собирать, обрабатывать и хранить любые типы аудиторных данных абонентов СПРС.Узел 1 WCS выполнен с возможностью запуска таймера начиная с времени регистрации узлом 2 SNA сигнального сообщения установления вызова, извлечения данных об абонентах из него, получения из БД дополнительных данных о вызывающем абоненте, формирования и передачи в сеть по таймеру уведомительного сообщения по SMPP протоколу с дополнительной информацией о вызывающей стороне а также функции взаимодействия с биллингом оператора NP осуществляющим начисление платы за предоставления услуги уведомления о входящем вызове. В контексте предлагаемого способа уведомления данный узел биллинга отделен от узла SCP управления услугами и с целью упрощения на фигурах не показан. Такое физическое отделение узла биллинга от узла SCP управления услугами, кроме того, исключает избыточный сигнальный обмен WCS - SCP, что предпочтительно с учетом сетевой нагрузки узла управления услугами SCP.
В дополнение к стандартной серверной архитектуре (фиг. 2) узел 2 SNA включает программно-аппаратные модули захвата, анализа и обработки сетевых сообщений сигнальных протоколов ОКС7 СПРС.Узел 2 SNA подключен к СПРС через высокоскоростной интерфейс и выполняет в режиме реального времени функции обнаружения, перехвата и регистрации времени появления в сети первого сигнального сообщения установления вызова. Для реализации обнаружения вызовов соответствующие контроллеры узла 2 SNA SS7 включают программы анализа сетевых сигнальных диалогов 3GPP поступающих на сетевую карту. Передача захваченного сообщения от узла 2 SNA узлу 1 WCS производится по согласованным программным API интерфейсам.
Функции узла 1 WCS и 2 SNA (фиг. 2) могут быть реализованы на сетевом одном узле. При некотором выигрыше в производительности такая реализация не является предпочтительной в связи с тем, что узел 2 SNA может выполнять разнородный сетевой анализ. Помимо выявления входящего вызова в сети он может проводить сетевой анализ в отношении иных событий сети (не только сигнальной) генерируемых абонентами или оператором - регистрация абонента в сети, запрос баланса, выход в интернет, появление в роуминге и др. В этой связи, делегирование ему функций формирования и передачи в сеть уведомления о входящем вызове представляется избыточным и нарушает принцип разделения функциональных объектов IN сетей.
В варианте стандартного подключения по технологии CAMEL (фиг. 1) узел 1 SCP WCS представляет собой стандартный программно-аппаратный узел предоставления дополнительных услуг ДВО VAS (Value Added Services) по технологии CAMEL. Он подключен к сети через стандартный CAMEL gateway предоставляет услугу уведомления по подписке CSI (CAMEL Subscription Information) и выполняет функции узла управления услугами SCP (Service Control Point) в терминологии IN сетей.
Диаграммы фиг. 3, 4 иллюстрируют различие стандартной реализации услуги по технологии CAMEL и предлагаемой автором технической реализации способа уведомления. Диаграммы оставляют за скобками стандартный сигнальный диалог СПРС по определению, текущего SSP вызываемого абонента, в контексте заявки принято, что данный диалог успешно произведен и SSP для вызываемого абонента является текущим.
Для сравнения фиг. 3 иллюстрирует реализацию способа уведомления о входящем вызове, предполагающую стандартное применение технологии CAMEL по подписке. Входящий вызов 1 incoming call поступает на текущий узел коммутации SSP. SSP начинает стандартную обработку вызова t init call processing. Запускается стандартный сигнальный САР диалог 2 CAP dialog для проверки запретов на вызовы, анализ CAMEL подписок и др. На узле коммутации SSP срабатывает N-CSI триггер подписки на уведомление о входящем вызове (N whoCalls), формируется состояние обработки входящего (12) вызова DP (Detection Point). В соответствии с парадигмой обработки вызова CAMEL BCSM (Basic Call State Model) SSP формирует запрос 3 initialDP (12) (called, calling) на SCP WCS с параметрами вызываемой (called) и вызывающей (calling) сторон (техническая спецификация CAMEL-ETSI TS 129 078) и ждет дальнейших указаний по обработке входящего вызова. Происходит стандартный САР обмен САР N_WhoCalls dialog, который завершается сообщением 4 CONTINUE N_WhoCalls на SSP для продолжения обработки вызова без параметров, т.к. для реализации уведомления не требуется дополнительная маршрутизация входящего вызова. При получении сообщения 3 initialDP (12) (called, calling) SCP WSC начинает выполнять программный алгоритм формирования уведомления WhoCalls notif determ. Программная логика алгоритма по аналогии с описанным ниже предлагаемым способом включает извлечение из САР сообщения 3 информации о вызывающей и вызываемой стороне called/calling party number (MSISDN, IMSI); запрос-ответ к базе данных User BD 5 API request (ID calling)-6 API response calling data; формирование сообщения для вызываемого абонента (called) с информацией User BD о вызывающей стороне (calling) и передачу в сеть этого сообщения 7 bind_transmitter. После стандартного SMPP обмена 7-9 USSD dialog, MS вызываемого абонента воспроизводит USSD N1 (Network Initiated) сообщение о входящем вызове с полезной дополнительной информацией о вызывающей стороне (calling) t notif. В этом варианте реализации сложность получения абонентом данного сообщения t notif после появления экрана входящего звонка t alert состоит в том, что время передачи в сеть USSD сообщения о входящем вызове 7 и соответственно его отрисовки на экране MS t notif никак не связано и не зависит от времени обработки вызова на SSP At call processing, начиная с времени t init call processing и до времени установления вызова t complit call processing. Передача сообщения 4 CONTINUE N_WhoCalls с параметром At приостановки установления вызова на SSP не исправляет ситуацию, т.к. узлу SCP WCS не известно в какое время, начиная с t init call processing т.е. времени начала обработки вызова сработал триггер подписки DP(12) N-csi N WhoCalls init и передано сообщение 3 initialDP(12) (called, calling). Более того приостановка установления вызова на SSP нежелательна с точки зрения QoS. По этой же причине (неизвестности начала отсчета) узлу SCP WCS не известно примерное время окончания обработки вызова SSP-SCP t complit call processing, сообщения 10 CONTINUE, CONNECT - команды узла управления услугами SCP о завершении обработки входящего звонка на SSP и завершения проключения вызова 11 alerting, а значит и время отрисовки на MS экрана входящего звонка t alert. В лучшем случае абонент получит сообщение USSD N1 уведомление t notif неопределенно позже экрана входящего звонка t alert, а в худшем, как показано на диаграмме фиг. 3 до его появления. В любом случае такой способ не позволяет управлять временем отрисовки t notif и t alert.
Предлагаемый автором способ уведомления абонента о входящем вызове, диаграмма фиг. 4 разрешает эту неопределенность Узел SNA через высокоскоростной интерфейс в режиме реального времени пассивно принимает зеркалированный из СПРС NP сигнальный CAP, SIP, ISUP траффик. При поступлении в сеть СПРС сообщения IAM (ISUP), INVITE (SIP) запроса 1 incoming call на установление входящего вызова SNA захватывает это сообщение и регистрирует время его появления в сети t reg. Далее по согласованным API интерфейсам узел SNA передает это сообщение (событие event) и время его регистрации t reg узлу WCS 2 incoming call event t reg. SSP начинает стандартную обработку вызова, включающую САР диалог 3 в ходе которого происходит проверка запретов на вызовы, анализ CAMEL подписок для входящих вызовов - T-CSI и др. Программный алгоритм узла WCS при получении сообщения 2 incoming call event запускает таймер timer start начиная с времени регистрации t reg события и начинает выполнять программный алгоритм формирования уведомления о входящем вызове WhoCalls notif determing. Алгоритм включает извлечение из сообщения информации ID о вызывающей и вызываемой стороне called/calling party number (MSISDN, IMSI). По извлеченному идентификатору ID вызывающей стороны алгоритм WCS формирует запрос к базе данных (User BD) 4 API request (ID calling). User BD отвечает имеющейся у нее записью с данными для формирования уведомления 5 API response calling data. Диалог 4-5 может не производиться в случае включения User BD непосредственно в узел WCS. После получения дополнительной информации о вызывающей стороне узел WCS формирует USSD N1 сообщение и передает его в сеть 8 bind_transmitter в период At от 2-х до 4-х секунд с момента запуска таймера WCS timer start. Этот интервал, как показано ниже, рассчитывается математически по переменным, определяющим время обработки вызова SSP-SCP At call processing. Далее происходит стандартный сигнальный SMPP диалог 8-10 с SMSC. Для подтверждения доставки регистрации времени t notif отрисовки USSD N1 сообщения с дополнительной информацией о вызывающей стороне, WCS может инициировать SMPP диалог 8-10 в режиме сообщений транзакции (Transaction Message Mode SMPP). В этом режиме SMSC гарантирует подтверждение доставки (или не доставки) сообщения 10 data_sm_resp (для упрощения диаграммы это сообщение показано напрямую в WCS).
Отмечается, что алгоритм узла WCS программно настроен на завершение всех операций по формированию и передаче в сеть уведомления о входящем вызове до времени завершения обработки вызова call processing Δt=2-4 sec. А время запуска таймера может отсчитываться от регистрации в сети первого сообщения САР диалога SSP - SCP на установление соединения, в этом случае обобщенная последовательность вызовов аналогично приведенной выше с учетом t init начала САР диалога.
В данной предлагаемой автором реализации, как иллюстрирует диаграмма фиг. 4, за счет включения в архитектуру сети СПРС узла SNA, регистрации им времени t reg появления первого сообщения установления входящего вызова и запуска (отсчета) таймера на узле WCS для передачи уведомления в сеть, абонент гарантированно получает уведомление о входящем вызове t notif после появления экрана входящего звонка t alert. Причем как понятно специалисту, способ позволяет настроить время передачи уведомления на узле WCS и соответственно его получения и отрисовки на MS t notif. Сообщение 10 data_sm_resp подтверждения доставки USSD N1 в сравнении с временем t alert используется для такой последующей настройки, т.е. времени передачи 8 bind_transmitter.
Вычисление оптимального интервала call processing Δt, представляет собой сложную математическую задачу, а программная методика такого расчета является ноу-хау заявителя. Время обработки вызова не является постоянной величиной и зависит как от конфигурации сети, так и от текущей загрузки каналов коммутации. Математическая модель такого расчета включает временно-вероятностные характеристики теории массового обслуживания. Расчет включает время управляющих воздействий на SSP, как указывалось выше это также время обмена информации об интеллектуальных услугах SSP-SCP, время проверки запретов на вызовы и анализ списка триггеров CAMEL подписки для входящих вызовов - T-CSI. Время перехода состояний САР парадигмы модели входящего вызова T-BCSM (Terminating Basic Call State Model) и соответственно время формирования управляющих воздействий включает время запуска программы логики услуги, время чтения-записи БД SCP информации об услуге, времени выполнения логики услуги. Расчет усугубляется сложно прогнозируемыми очередями обработки сообщений SSP - SCP. Тем не менее, оптимальный интервал At call processing поддается расчету с приемлемой для реализации способа точностью. В контексте заявки, без ограничения объема правовой охраны, интервал принят в 2-4 секунды. Математическая модель, взятая за основу для расчета времени обработки вызова приведена в книге Б.Я Лихтциндера и др. «Интеллектуальные сети связи» издание Эко-Трендз, Москва 2002 г. Глава 7, стр. 76.
Дополнительно отмечается, что в предлагаемом автором способе за счет выведения из сигнального обмена SSP - SCP диалога CAP N_whoCalls dialog подписки сокращено время обработки вызова и обеспечено не вмешательство способа уведомления в сигнальный обмен установки вызова. При том что инициация уведомления, его формирование и доведение до абонента произведено по сигнальным протоколам СПРС.
Предлагаемый авторами способ, за счет пассивного анализа сигнальной сети СПРС на узле 2 SNA позволяет регистрировать как время появления экрана входящего звонка на MS абонента t alert 7 alerting, так и время появления уведомления о нем t notif 10 data_sm_resp.В последствии эти данные учитываются для настройки способа. В дополнении к этому способ учитывает комфортное для абонента время задержки уведомления. Исследование показали, что оптимальное время задержки отрисовки USSD N1 уведомления после появления экрана входящего звонка составляет 1-2 секунды. Это время представляется комфортным для предварительного анализа абонентом информации экрана входящего звонка и последующего анализа дополнительной информации о нем содержащейся в уведомительном сообщении.
Предлагаемый способ и устройство для его осуществления разработаны испытаны и внедрены в сетях операторов СПРС являются эволюционным развитием технического решения по патенту заявителя RU2676615 и подтверждают заявленный технический результат.