Способ уведомления об отмененном вызове Российский патент 2019 года по МПК H04M1/57 H04W4/20 

Изобретение относится к области телекоммуникаций, в частности к способам информирования абонентов о наступлении событий сети, генерируемых абонентами и может быть использовано операторами интеллектуальной сети NP (Network Provider) в СПРС (сетях подвижной радиосвязи) практически любых типов - GSM, UMTS, LTE и других.

В соответствии с текущим уровнем техники общим для всех типов сетей связи является два уровня:

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

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

Указанное логическое разделение на сигнальный и медиа-уровень справедливо как для самых современных типов сетей связи ОТТ (Over-the-Top, поверх сети доступа IP - Internet), таких как Skype, Viber, GoogleTalk, FacebookMessenger, WhatApp, так и для классических типов коммуникаций, описываемых в телекоммуникационных стандартах ITU-T, ETSI, 3GPP и других институтов.

Телекоммуникационный провайдер, сетевые службы которого используются для службы ОТТ, не имеет контроля в отношении последних. Это связано с тем, что пользователь имеет возможность использовать Интернет так, как он хочет. Сетевой оператор только переносит IP-пакеты от источника к месту назначения, он только может знать о пакетах и их содержимом. Кроме того, для пользователя ОТТ связь дешевле, вызывающий абонент не оплачивает установленное телефонное соединение и аренду установленного канала связи.

Вместе с тем, хотя протокол TCP/IP является достаточно надежным средством переноса данных, тем не менее стандартизованные протоколы установления связи (сигнальные протоколы систем подвижной радиосвязи СПРС) предоставляют гарантированные стандартами QoS. В этой связи, интересно что отдельные функции ОТТ связи гарантируют более надежное срабатывание чем сигнальная сеть оператора (без учета времени срабатывания). Одним из таких прикладных следствий ОТТ связи является гарантированное доведение до второго конечного пользователя ОТТ приложения уведомления об отмененном вызове его первым абонентом. Это случай, когда первый абонент в ОТТ приложении набирает номер второго абонента и быстро отменяет его исходя из своих мотивов. Пакетная сеть ОТТ связи в этом случае срабатывает в обычном режиме TCP/IP протокола и обеспечивает доставку ТСР/ГР пакетов с интерфейсом соответствующего ОТТ приложения до конечного устройства второго абонента, уведомляя его о попытке вызова. В сигнальной сети оператора связи любая операция, которую выполняет клиент агента пользователя (UAC), реализуется с помощью серии транзакций. Диалоги установления соединения создаются путем возврата ответов, не информирующих об ошибках, на запросы определенных типов. В случае сброса вызова первым абонентом, например, в соответствии с стандартом протокола установления сеанса SIP диалог установления соединения прерывается сообщением BYE. Когда участнику диалога приходит сообщение BYE, все сессии, связанные с данным диалогом должны быть разрушены. Клиент агента UA первого, вызывающего пользователя может послать BYE как в установленном диалоге, так и в диалогах, находящихся на «ранней стадии». Например, в случае если первый абонент отменил вызов при установлении соединения с участием сервера переадресации, в тот момент, когда сервер переадресации запрашивает текущий адрес вызываемого пользователя. В этом случае сервер переадресации на сообщение BYE, прекращает диалог установления соединения с первым абонентом, освобождает ресурсы и отвечает сообщением 200 OK первому абоненту, подтверждая освобождение ресурсов. Соединение с вторым пользователем не устанавливается, и он не уведомляется о сброшенной попытке вызова первым абонентом.

Это свойство сигнальных протоколов СПРС проиллюстрированное на примере SIP протокола, но не ограниченным им в рамках настоящего изобретения, представляется авторам недоработанным с точки зрения, как пользователей СПРС, так и операторов связи. Настоящее изобретения направлено на устранение этой недоработки. А именно на надежное доведение до вызываемого пользователя уведомления о сброшенной первым абонентом попытке вызова на любой стадии установления соединения в сигнальной сети оператора по любым известным из уровня техники протоколам коммутации вызовов.

Патент US 5859903 12.01.1999 г. описывает метод уведомления о сброшенном первым абонентом вызове в проводной (прикладной для данного изобретения) сети телефонной связи, содержащей т.н. сервисный узел кнопочной телефонной сети соединяющий телефонные аппараты и отдельные линии связи. Способ включает этапы, на которых сервисный узел осуществляет проверку вызова из одной из присоединенных линии связи; осуществляется ли вызов в расширенное подключение абонентов, подписанных на услугу; не ответил ли вызываемый абонент с «расширенным» подключением на вызов. Если ответ проверка по данным этапам положительная то проверяется получение идентификатора, вызывающего (первого абонента), сохраняется и направляется вызываемому абоненту.

При настоящем уровне техники недостатки такого способа очевидны: проводное, шинное подключение т.н. офисных линий к устройству уведомления; отдельное, т.н. «расширенное» подключение подписанных на услугу абонентов («выходы extension line subscriber 1-n…»); невозможность масштабирования, управления производительностью, не гибкость решения.

На современном уровне техники известна заявка WO 2014/087269 2014.06.12 описывающая способ маршрутизации вызовов из ОТТ сетей связи в ОТТ сети так и в сети, не относящиеся к таковым. Согласно способу оператор вызывающего абонента принимает набранный номер вызываемой стороны, передает это номер поставщику ОТТ связи который осуществляет проверку способности завершить указанный вызов, после чего передают результат проверки оператору связи, обеспечивающему бесперебойность связи для вызывающей и вызываемой стороны. За счет этого авторы добиваются как они это называют «бесшовного» соединения абонентов ОТТ сетей и обычных TTN сетей.

Данный способ обеспечивает маршрутизацию вызова, в том числе вызова прерванного вызывающей стороной, за счет того, что пакетная передача данных в этом случае обеспечивает доставку сообщения поверх сигнальной сети оператора. Недостаток такого решения также очевиден, оно по определению работает только в ОТТ сетях с соответствующими последствиями - необходимость ОТТ приложения как минимум для первого абонента и невозможность соответствия QoS стандартизованной в СПРС. Кроме того, такое решение не обеспечивает взаимодействие между различными ОТТ, сетями-например, Viber и Skype, и др.

Техническим результатом предлагаемого способа уведомления об отмененном вызове является быстрое и надежное уведомление вызываемого абонента об отмененной попытке вызова вызывающим абонентом в СПРС.

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

Способ иллюстрируется чертежами:

На фиг. 1, 2 представлены упрощенная схема СПРС с вариантами подключения дополнительного узла SCP XDRay. Фиг. 1, 2 не ограничивают способы подключения узла SCP XDRay в архитектуру СПРС, а иллюстрируют два основных из возможных вариантов подключения в рамках данного изобретения.

На фиг. 3 представлена диаграмма диалога уведомления об отмененном вызове в режиме прослушивания САР диалога SSP - SCP.

На фиг. 4 представлена диаграмма диалога уведомления об отмененном вызове в режиме прослушивания сигнальных сообщений на примере ISUP.

На фигурах сигнальная сеть показана штрихованными линиями, сеть данных сплошными линиями.

Указанный способ может быть реализован в СПРС разных стандартов ITU-T, фиг. 1 иллюстрирует обобщенные сети NP А, В, включающие взаимодействующие основные узлы - мобильные терминалы абонентов MS; узлы коммутации услуг SSP, в разных архитектурах СПРС его функции выполняют MSC, ММЕ и др.; узел управления услугами SCP выполняющий функции биллинга; узел SCP XDRay предоставляющий дополнительные виды обслуживания ДВО (VAS services) IN и подключенный к базовой сети оператора. Некоторые стандартизованные узлы СПРС - система базовых станций BSS, шлюзовые узлы GW и др. с целью упрощения на фиг. 1 не показаны. Также для упрощения фиг. 1 принято, что регистры VLR, HLR, HSS, а также SMSC входят в состав SSP.

В рамках предлагаемого способа, но не ограничивая объем его правовой охраны аппаратно-программной частью узла ДВО, представляется ПАК SCP XDRay. Данный способ может быть реализован различной архитектурой ПАК являющейся как отдельным узлом СПРС, так и частью существующего стандартизованного сетевого узла. SCP XDRay - комплекс для уведомления о событиях поведения абонентов в сетях сотовой связи разработанный авторами - заявка WO №2013107454. Комплекс может пассивно включаться в сеть оператора и может быть настроен на захват любых диалогов базовой сети оператора, программная логика его работы являющаяся ноу-хау авторов оптимизирована для мгновенной реакции на захваченные события и настраивается по времени формирования и передачи в сеть уведомительных сообщений и возможности их приема абонентами или оператором. Параметры абонентов извлекаются из перехваченных сообщений и по специальному алгоритму программного комплекса сравниваются с данными профиля абонента для генерирования способа уведомления. В разных архитектурах SCP XDRay может слушать обмен данными сети взаимодействуя со шлюзовым узлом, узлом коммутации как на фиг. 1, SCP или подключившись к физической сети СПС через обобщенный gateway фиг. 2. Аппаратно-программная архитектура SCP XDRray оптимизирована под мгновенную реакцию на события сигнальной сети оператора в увязке «захват-хранение-уведомление» причем ПАК обеспечивает такую увязку в разных сочетаниях.

Фиг. 3 иллюстрирует реализацию работы SCP XDRay по технологии CAMEL. В этом варианте SCP XDRay в пассивном режиме слушает САР диалог SSP - SCP. В соответствии с парадигмой базовой модели состояния вызова (BCSM) процесс обработки вызовов в SSP переходит от одного состояния вызова к другому (PIC - Points in Call). Доступ к услугам IN для конкретных PIC определен в т.н. триггерных точках detection point DP. Подписка на услугу уведомления о сброшенном вызове (CAMEL Subscription Information, СSI) может быть сделана в HLR профиле абонента или непосредственно на SSP (Network Service CAMEL Subscription Information, N-CSI). Обработка исходящего вызова происходит на SSP (Vistor MSC) в котором абонент зарегистрирован в данный момент. VLR этого MSC уже содержит копию профиля абонента, а значит и запись о подписке на услугу уведомления о сброшенном вызове. В другом варианте уведомление о сброшенном вызове м.б. предопределенной функциональностью СПРС и предоставляться без подписки. Абонент А инициирует исходящий вызов, после сигнального обмена SSP-MS включающего запрос услуги, в данном случае исходящий вызов, для упрощения диаграммы фиг. этот диалог умещен в сообщение 1 Setup. Формируется состояния вызова initial DP означающее, что обнаружено обращение к интеллектуальным услугам и начинается САР диалог SSP - SCP. SSP инициирует запрос 2 InitialDP(A, В) в адрес SCP с запросом указания об обработке вызова. После анализа SCP отвечает сообщением 3 RRB\ACH…\CONt «RequestReportBCSM + Continue + ApplyCharging» с разрешением биллинга. В это время вызов последовательно переходит в состояния PIC «O_Null & Authorize Origination_Attempt» включающего проверку подписок, запретов на вызов и др.; «Collect_Info», «Analyse_Information» - разбор данных о подписках абонента разбор вызываемого номера; "Routing & Alerting" включающий вызов абонента Б. В случае ответа вызываемого абонента вызов переходит и состояние DP «O_Answer», либо другие DP в зависимости от событий сети - абонент Б-занят, не отвечает и др., в соответствии с рекомендациями ITU-T Q.1214. SCP XDRay мониторит весь диалог в зеркальном траффике в пассивном режиме (фиг. 1). В случае если в момент диалога SSP А - SCP А абонент А отменяет вызов, нажимая на клавишу положить трубку MS А направляет в сеть сообщение 4 REL. SSP генерирует событие O_Abandon указывающее, что вызывающая сторона освобождает вызов до того, как вызов достигнет активной фазы, на которой до SSP В вызываемого абонента доводится сигнализация о входящем вызове, "Routing & Alerting», например, и направляет соответствующее сообщение 5 O_Abandon на SCP. Это событие может произойти во время создания BCSM находится в PIC или Null или во время взаимодействия с пользователем в начале вызова (BCSM находится в собранной информации DP) и не содержит код причины в уведомлении об отказе. Т.е. сообщение может быть передано в диалог SSP - SCP на любой стадии сигнального обмена до CAP message N (на фиг. сообщения «САР message N-1» и «САР message N» не пронумерованы т.к. в этом случае диалог прерывается они не передаются). SSP освобождает ресурсы установления соединения и направляет подтверждение 6 RLC. SCP XDRay перехватывает сообщение O_Abandon и запускает процедуру уведомления абонента Б. ПАК SCP XDRay устанавливает сигнальный диалог 7-14 для уведомления вызываемого абонента В. Немедленно после получения подтверждения SSP В «адрес полный» программный алгоритм генерирует сообщение разъединения 8 REL (А, В). Абонент В уведомляется о попытке вызова абонентом А. Дополнительно SCP XDRay может направлять SMS уведомление для абонента В 15-16.

Такая реализация способа предпочтительна и не ограничивая объем правовой охраны является основным режимом работы SCP XDRay. Пассивный режим SCP XDRay ограничен прослушиванием сигнализации, a SSP освобожден от коммутации уведомления о сброшенном вызове. Она обеспечивает принципы компонентного построения IN сети, разделяет функции коммутации и управления обслуживанием вызовов. Реализация исключает сигнальный обмен между узлом коммутации SSP и узлом SCP XDRay, предоставляющего VAS сервисы, что безусловно предпочтительно с точки зрения обслуживания СПРС.

Фиг. 4 иллюстрирует диаграмму сигнального обмена ISUP в рамках которой SCP XDRay в пассивном режиме прослушивает сигнальный траффик на примере ISUP и уведомляет вызываемого абонента Б. В этой реализации SCP XDRay пассивно слушает сигнальный обмен (ISUP) в базовой сети оператора вне диалога CAP SSP-SCP.

Абонент А инициирует исходящий ISDN-вызов MS А посылает сообщение 1 Setup к исходящей SSP А. При приеме запроса на установление соединения от вызывающего абонента исходящая SSP А анализирует информацию о маршруте и формирует начальное адресное сообщение IAM. Сообщение IAM передает адресную информацию, также информацию, относящуюся к установлению соединения, параметры совместимости и др. SCP XDRay перехватывает сигнальное сообщение 1 Setup на инициирование процедур установления соединения помечает профиль абонента А признаком процедура установления исходящего вызова, это возможно за счет предварительного накопления профилей абонентов на SCP XDRay. В случае если абонент А отменяет исходящий вызов и сбрасывает его (кладет трубку) MS А направляет в сеть сообщение 2 REL - уведомление освобождение канала, использовавшегося в соединении, сообщение информирует SSP А о необходимости освободить ресурсы, задействованные в установлении соединения. SSP А по коду причины (ISUP cause codes), в данном случае 16-нормальное завершение вызова по требованию MS А, обеспечивает переход в исходное состояние элементов соединительного пути и направляет подтверждение 3 RLC. В этом случае SSP А не гарантирует отправку сообщения IAM в направлении вызываемого абонента Б на входящую SSP В или транзитную SSP, а значит не гарантирует информирование абонента Б о попытке вызова. SCP XDRay перехватывает сообщение 2 REL его программный алгоритм увязывает полученное сообщение разъединения от MS А с активным признаком профиля абонента - «устанавливается исходящее соединение». По признаку REL ISUP cause codes = 16, а также по условию не появления в сети оператора начального сообщения IAM, и/или запроса дополнительной информации INR, ответа на него исходящей SSP А - INF, и/или подтверждения коммутатора - адрес достаточен АСМ, программный алгоритм SCP XDRay определяет, что абонент Б не информирован о сброшенном вызове. И запускает процедуру уведомления абонента Б. ПАК SCP XDRay устанавливает сигнальный диалог 4-11 для уведомления вызываемого абонента В. Немедленно после получения подтверждения SSP В «адрес полный» программный алгоритм генерирует сообщение разъединения 8 REL (А, В). Абонент В уведомляется о попытке вызова абонентом А. Дополнительно SCP XDRay может направлять SMS уведомление для абонента В 12-13.

Такая реализация способа может быть актуальна в случае невозможности прослушивания САР диалога. Реализация также исключает сигнальный обмен между узлом коммутации SSP и узлом VAS сервисов, что безусловно предпочтительно с точки зрения обслуживания СПРС. Недостатком и платой за такое разделение функций, в данном способе прослушивания сигнального траффика, является повышенная нагрузка на SCP XDRay в части мониторинга всех исходящих вызовов и контроля их завершения. Даже учитывая, что программный алгоритм SCP XDRay оптимизирован на мгновенную запись-чтение признака установления исходящего соединения профиля абонента, нагрузка на сервер оценивается как значительная.

Как понятно для специалиста, на примере протокола ISUP, данный способ может использоваться не только в сетях СПРС, но и в сетях телефонной сети общего пользования ТФОП.

Способ может быть реализован в полуактивном режиме (менее предпочтителен). В этом случае включается сигнальный обмен между SCP XDRay и SSP или/и SCP А. А после перехвата и обработки сообщения O_Abandon SCP XDRay обменивается данными с SSP или/и SCP А для коммутации уведомления вызываемого абонента. В этом случае инициирование и прерывание соединения (сообщения 7-16 фиг. 2) для уведомления вызываемого абонента выполняется на SSP А. Суть способа также предполагает уведомление о сброшенном вызове и без узла SCP XDRay. В этом случае сигнальный обмен 7-16 фиг. 2 производится между SSP А и SSP В. A SCP XDRay или отсутствует в архитектуре сети или выполняет другие функции (предоставляет другие сервисы). В этом случае обобщенная логика обработки отбоя вызывающей стороны и уведомления вызываемой выполняется на SSP А и/или SCP А.

Возможности ПАК SCP XDRay обеспечивают реализацию способа в которой для обнаружения отмененного вызова и уведомления о нем анализируются сообщения радиосети оператора, например, по протоколу DTAP GSM (Direct Transfer Application Part), и/или lu интерфейсу с коммутацией каналов CS, коммутацией пакетов PS для сетей LTE. В этом случае узел SCP XDRay получает зеркалированный трафик радиосети оператора на участке MS-MSC (GSM), UTRAN-CN (LTE). Такой вариант реализации предпочтителен в части быстродействия способа, в нем задержки сообщений на коммутаторе и в базовой сети оператора в целом не оказывают влияние на скорость уведомления. В этом случае общая логика работы способа сохраняется с учетом форматов протоколов (интерфейсов) применяемых в радиосети СПРС.

Описанные выше реализации работы иллюстрируют некоторые из множества реализаций способа уведомления, для специалиста очевидно, что суть способа реализуема не только по проколам интеллектуального управления вызовами CAP/ISUP, но также по протоколу установления сеанса SIP, для этого в состав ПАК SCP XDRay включен SIP сервер. Логика выполнения способа по протоколу SIP аналогична приведенному выше с учетом стандартов API SIP и в общем виде заключается в генерировании уведомления SCP XDRay до окончания установления сеанса SIP при прерывании его вызывающим абонентом. Парадигма предлагаемого способа уведомления хорошо укладывается и в другие способы коммутации вызова, известные из уровня техники.

Уведомления вызываемому абоненту могут быть сформированы как SMS, USSD, PUSH сообщения, в любых других форматах известных из текущего уровня техники.

Данный способ внедрен и эксплуатируется заявителем в СПРС известного оператора на базе комплекса SCP XDRay и показал эффективность надежного уведомления абонентов об отмененном вызове в соответствии с стандартизованными требованиями QoS.

Изобретение относится к области информирования абонентов о наступлении событий сети, а именно к способу уведомления абонента об отмененном входящем вызове. Техническим результатом является доведение до вызываемого пользователя уведомления о сброшенной первым абонентом попытке вызова на любой стадии установления соединения в сигнальной сети оператора по любым протоколам коммутации вызовов. Для этого телекоммуникационный провайдер принимает исходящий вызов вызывающей стороны, определяет номер вызываемой стороны, в случае отмены вызова вызывающей стороной до информирования вызываемого абонента об этом вызове, телекоммуникационный провайдер обнаруживает отмененный вызов, определяет, что вызываемый абонент не информирован об отмененном вызове и формирует информационное сообщение об отмененном вызове вызываемому абоненту. 2 з.п. ф-лы, 4 ил.

1. Способ уведомления об отмененном вызове, в соответствии с которым телекоммуникационный провайдер принимает исходящий вызов вызывающей стороны, определяет номер вызываемой стороны, отличающийся тем, что, в случае отмены вызова вызывающей стороной до информирования вызываемого абонента об этом вызове, телекоммуникационный провайдер обнаруживает отмененный вызов, определяет, что вызываемый абонент не информирован об отмененном вызове и формирует информационное сообщение об отмененном вызове вызываемому абоненту.

2. Способ уведомления по п. 1, отличающийся тем, что обнаружение отмененного вызова производят с помощью узла, дополнительного включенного в сеть оператора сотовой связи.

3. Способ уведомления по п. 1, отличающийся тем, что обнаружение отмененного вызова производят с помощью стандартного узла сети оператора сети сотовой связи.