управление завершением вызова

Формула изобретения

1. Способ управления настройкой вызова от вызывающего модуля (СЕ201) к вызываемому модулю в телекоммуникационной сети, причем вызов содержит первую попытку вызова и дополнительную попытку вызова, а телекоммуникационная сеть содержит узел (SCE205) управления услугами и модуль (SSE204) коммутации услуг, причем узел (SCE205) управления услугами осуществляет этапы, на которых:

принимают от модуля (SSE204) коммутации услуг индикацию того, что первая попытка вызова потерпела неудачу, принимают от модуля (SSE204) коммутации услуг индикацию дополнительной попытки вызова,

получают информацию вызова, относящуюся к первой попытке вызова,

определяют процедуру установления вызова для дополнительной попытки вызова на основе информации вызова, относящейся к первой попытке вызова, и отправляют инструкцию к модулю (SSE204) коммутации услуг для продолжения настройки дополнительной попытки вызова в соответствии с процедурой установления вызова.

2. Способ по п.1, дополнительно содержащий этапы, на которых: отправляют инструкцию для инициации сохранения информации вызова, относящейся к первой попытке вызова, к одному из: модуля (SSE204) коммутации услуг и базы данных (SD202) абонента, соединенной с узлом (SCE205) управления услугами, принимают хранящуюся информацию вызова, относящуюся к первой попытке вызова, совместно с приемом индикации дополнительной попытки вызова.

3. Способ по п.2, в котором индикация дополнительной попытки вызова принимается в начальном сообщении, содержащем элемент информации для индикации дополнительной попытки вызова.

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

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

6. Способ управления настройкой вызова от вызывающего модуля (СЕ201) к вызываемому модулю в телекоммуникационной сети, причем вызов содержит первую попытку вызова и дополнительную попытку вызова, а телекоммуникационная сеть содержит узел (SCE205) управления услугами, модуль (SSE204) коммутации услуг, и узел (SN203) коммутации, причем модуль (SSE204) коммутации услуг осуществляет этапы, на которых:

принимают от узла (SN203) коммутации индикацию того, что первая попытка вызова потерпела неудачу,

отправляют индикацию того, что первая попытка вызова потерпела неудачу, на узел (SCE205) управления услугами,

принимают от узла (SN203) коммутации индикацию дополнительной попытки вызова,

отправляют индикацию дополнительной попытки вызова на узел (SCE205) управления услугами,

принимают инструкцию от узла (SCE205) управления услугами для продолжения настройки дополнительной попытки вызова, и

устанавливают дополнительную попытку вызова в соответствии с инструкцией.

7. Способ по п.6, дополнительно содержащий этапы, на которых:

принимают от узла (SCE205) управления услугами инструкцию для инициации сохранения информации вызова, относящейся к первой попытке вызова,

отправляют на узел (SN203) коммутации инструкцию для инициации сохранения информации вызова, относящейся к первой попытке вызова,

принимают от узла (SN203) коммутации хранящуюся информацию вызова, относящуюся к первой попытке вызова, совместно с приемом индикации дополнительной попытки вызова, и отправляют на узел (SCE205) управления услугами хранящуюся информацию вызова, относящуюся к первой попытке вызова, совместно с отправкой индикации дополнительной попытки вызова.

8. Способ по п.7, в котором хранящаяся информация вызова, относящаяся к первой попытке вызова, отправляется на узел (SCE205) управления услугами в начальном сообщении, содержащем элемент информации, для индикации хранящейся информации вызова.

9. Способ по п.7, в котором индикация дополнительной попытки вызова отправляется на узел (SCE205) управления услугами в начальном сообщении, содержащем элемент информации для индикации дополнительной попытки вызова.

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

11. Способ управления настройкой вызова от вызывающего модуля (СЕ201) к вызываемому модулю в телекоммуникационной сети, причем вызов содержит первую попытку вызова и дополнительную попытку вызова, а телекоммуникационная сеть содержит узел (SCE205) управления услугами, модуль (SSE204) коммутации услуг, базу данных (SD202) абонента и узел (SN203) коммутации, причем узел (SN203) коммутации осуществляет этапы, на которых:

отправляют индикацию того, что первая попытка вызова потерпела неудачу, на модуль (SSE204) коммутации услуг,

принимают от модуля (SSE204) коммутации услуг инструкцию для инициации хранения информации вызова, относящейся к первой попытке вызова,

отправляют на базу данных (SD202) абонента инструкцию для инициации хранения информации вызова, относящейся к первой попытке вызова,

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

принимают от базы данных (SD202) абонента хранящуюся информацию вызова, относящуюся к первой попытке вызова,

инициируют дополнительную попытку вызова от вызывающего модуля (СЕ201) к вызываемому модулю,

отправляют индикацию дополнительной попытки вызова на модуль (SSE204) коммутации услуг, и

отправляют хранящуюся информацию вызова, относящуюся к первой попытке вызова, на модуль (SSE204) коммутации услуг.

12. Способ по п.11, дополнительно содержащий этапы, на которых: предоставляют вызывающему модулю (СЕ201) вариант инициировать дополнительную попытку вызова, когда вызываемый модуль становится доступным, принимают от вызывающего модуля (СЕ201) ответ на этот вариант.

13. Способ управления настройкой вызова от вызывающего модуля (СЕ201) к вызываемому модулю в телекоммуникационной сети, причем вызов содержит первую попытку вызова и дополнительную попытку вызова, а телекоммуникационная сеть содержит узел (SCE205) управления услугами, модуль (SSE204) коммутации услуг, базу данных (SD202) абонента и узел (SN203) коммутации, причем база данных (SD202) абонента осуществляет этапы, на которых:

принимают инструкцию для инициации сохранения информации вызова, относящейся к первой попытке вызова,

сохраняют информацию вызова, относящуюся к первой попытке вызова,

принимают индикацию того, что вызываемый модуль доступен, отправляют индикацию того, что вызываемый модуль доступен, на узел (SN203) коммутации, и

отправляют хранящуюся информацию вызова, относящуюся к первой попытке вызова.

14. Способ по п.13, в котором инструкция для инициации сохранения информации вызова, относящейся к первой попытке вызова, принимается от узла (SN203) коммутации.

15. Способ по п.14, в котором хранящаяся информация вызова, относящаяся к первой попытке вызова, отправляется на узел (SN203) коммутации.

16. Способ по п.13, в котором инструкция для инициации сохранения информации вызова, относящейся к первой попытке вызова, принимается от узла (SCE205) управления услугами.

17. Способ по п.16, в котором хранящаяся информация вызова, относящаяся к первой попытке вызова, отправляется на узел (SCE205) управления услугами.

18. Узел (SCE205) управления услугами, выполненный с возможностью осуществлять этапы способа в соответствии с любым из пп.1-5.

19. Модуль (SSE204) коммутации услуг, выполненный с возможностью осуществлять этапы способа в соответствии с любым из пп.6-10.

20. Узел (SN203) коммутации, выполненный с возможностью осуществлять этапы способа в соответствии с любым из пп.11 и 12.

21. База данных (SD202) абонента, выполненная с возможностью осуществлять этапы способа в соответствии с любым из пп.13-17.

22. Читаемый компьютером носитель, хранящий компьютерную программу, загружаемую в блок обработки узла (SCE205) управления услугами, причем компьютерная программа содержит части программного кода, выполненного с возможностью осуществлять этапы способа в соответствии с любым из пп.1-5.

23. Читаемый компьютером носитель, хранящий компьютерную программу, загружаемую в блок обработки модуля (SSE204) коммутации услуг, причем компьютерная программа содержит части программного кода, выполненного с возможностью осуществлять этапы способа в соответствии с любым из пп.6-10.

24. Читаемый компьютером носитель, хранящий компьютерную программу, загружаемую в блок обработки узла (SN203) коммутации, причем компьютерная программа содержит части программного кода, выполненного с возможностью осуществлять этапы способа в соответствии с любым из пп.11 и 12.

25. Читаемый компьютером носитель, хранящий компьютерную программу, загружаемую в блок обработки базы данных (SD202) абонента, причем компьютерная программа содержит части программного кода, выполненного с возможностью осуществлять этапы способа в соответствии с любым из пп.13-17.

Описание изобретения к патенту

Область техники, к которой относится изобретение

Настоящее изобретение относится к телекоммуникационным сетям, в частности к способам и устройствам для управления настройкой вызова в интеллектуальной сети.

Уровень техники

В телекоммуникационной сети вызов, инициированный вызывающим объектом к вызываемому объекту, может не привести к успешному соединению между двумя объектами. Например, вызываемый объект может быть вовлечен в другой вызов, то есть занят или неспособен ответить на вызов, в то время как вызов сделан. Кроме того, в мобильных сетях вызов может потерпеть неудачу, потому что вызываемый объект может быть недоступным по некоторым причинам. Например, вызываемый объект может быть расположен в области, которая экранирована от приема радиосигнала, или пользовательское оборудование вызываемого объекта может быть выключено.

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

Чтобы предоставить большее удобство абонентам, поставщики телекоммуникационных служб предлагают службы завершения вызова для использования в ситуациях, в которых вызов не завершен из-за вызываемого объекта, являющегося недоступным, например, занятым или не достижимым. Примером является добавочная служба завершения вызовов занятому абоненту (CCBS). CCBS была определена, например, в 3GPP (Проект Партнерства Третьего Поколения) TS (Техническая Спецификация) 22.093.

Когда вызываемый объект является занятым или не достижимым, службы завершения вызова обычно разрабатываются для того, чтобы предложить вызывающему объекту вариант автоматического обратного вызова, когда вызываемый объект становится доступным для обратного вызова. Обычно узел коммутации, такой как мобильный центр коммутации (MSC), который обслуживает вызывающий объект, предлагает вызывающему объекту опцию автоматического обратного вызова, когда вызываемый объект будет казаться недоступным, например, занятым или не достижимым. Если вызывающий объект принимает предложение, процедура начинается узлом коммутации, обслуживающим вызываемого объекта для того, чтобы наблюдать за доступностью вызываемого объекта. Как только обнаружено, что вызываемый объект снова является доступным или незанятым, то есть больше не занятым или находящимся в обратной радиосвязи с сетью, тогда уведомляется объект коммутации, обслуживающий вызывающий объект. Этот объект коммутации инициирует вызов к вызывающему объекту и, если вызывающий объект отвечает, настраивается вызов к вызываемому объекту. В качестве альтернативы, объект коммутации отправляет определяемое уведомление вызывающему объекту, сообщая вызывающему объекту, что вызываемый объект теперь доступен, по которому вызывающий объект может инициировать установление вызова на вызываемый объект.

В дополнение к так называемым службам на основе сети, таким как службы завершения вызова, то есть службам, которые выполняются узлами коммутации и под их управлением, есть также службы интеллектуальной сети, которые выполняются и управляются Интеллектуальной Сетью (IN). В соответствии с концепцией IN, интеллект службы или логика службы отделен от функций коммутации. Это отделение в основном дает возможность операторам сети разрабатывать и разворачивать службы и характеристики независимо от поставщиков, позволяя более гибкое развитие служб, упрощенное внедрение, меньшую стоимость и большую автономию. Примерами протоколов IN являются Прикладной протокол интеллектуальной сети (INAP), Расширенная IN (AIN), и Приложения для усовершенствованной логики сетей мобильной связи (CAMEL). INAP был разработан для фиксированных линейный сетей и является первичным протоколом, использующимся для фиксированных линейных IN за пределами Северной Америки. AIN является вариантом, разработанным для Северной Америки.

CAMEL является сетевой характеристикой Фазы 2+ Глобальной системы мобильной связи (GSM) и Широкополосного множественного доступа с кодовым разделением (WCDMA), которые определены в 3GPP TS 22.078. CAMEL основан на ядре INAP с модификациями для того, чтобы принять во внимание, среди прочего, мобильность абонента. В частности, CAMEL допускает использование подписчиком служб, определенных для оператора, даже при роуминге вне домашней наземной мобильной сети общего пользования (PLMN) абонента. Интеллектуальная сеть на основе CAMEL содержит в качестве основных объектов: объект коммутации службы, для коммутации задач, также называемой SSF (функция коммутации служб) или gsmSSF (функция коммутации служб GSM) и объект управления службой, содержащий интеллект службы или логику также называемый SCP (точка управления службой) или gsmSCF (функция управления службой GSM).

Фиг.1 изображает схематический обзор телекоммуникационной сети, содержащей интеллектуальную сеть в соответствии с предшествующим уровнем техники.

Интеллектуальная сеть содержит точку 101 управления службой и функцию 102 коммутации службы. Кроме того, изображены узлы коммутации MSC 103, MSC 104 и MSC 105, каждый из которых может быть Мобильным Центром Коммутации (MSC). MSC 103 обслуживает вызывающий объект, и MSC 105 обслуживает вызываемый объект. Фиг.1 дополнительно изображает вызывающий объект CE100 и вызываемый объект CE106.

Службы интеллектуальных сетей выполняются точкой 101 управления службой и под ее управлением. Точка 101 управления службой способна осуществлять связь с функцией 102 коммутации службы, используя протокол интеллектуальной сети, такой как CAMEL или INAP. Функция 102 коммутации службы из этого примера совмещена с узлом 103 коммутации, то есть узлом коммутации, обслуживающим вызывающий объект. В качестве альтернативы, функция 102 коммутации службы может быть реализована как отдельный узел.

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

Сущность изобретения

Целью изобретения является предоставление способов, устройств и компьютерных программ, которые улучшают завершение вызова в телекоммуникационной сети.

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

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

Объект управления службой принимает от объекта коммутации службы индикацию того, что первая попытка вызова потерпела неудачу в первый момент времени. Во второй момент времени (например, на секунды, минуты, часы, дни позже, чем первый момент времени) объект управления службой принимает от объекта коммутации службы индикацию дополнительной попытки вызова, получает информацию вызова, относящуюся к первой попытке вызова, определяет процедуру установления вызова для дополнительной попытки вызова на основе информации вызова, относящейся к первой попытке вызова, и отправляет инструкцию на объект коммутации службы для продолжения настройки дополнительной попытки вызова в соответствии с процедурой установления вызова.

Объект коммутации службы принимает от узла коммутации индикацию того, что первая попытка вызова потерпела неудачу, в первый момент времени, и отправляет индикацию того, что первая попытка вызова потерпела неудачу на объект управления службой. Во второй момент времени объект коммутации службы принимает от узла коммутации индикацию дополнительной попытки вызова, отправляет индикацию дополнительной попытки вызова на объект управления службой, принимает инструкцию от объекта управления службой для продолжения настройки дополнительной попытки вызова, и устанавливает дополнительную попытку вызова в соответствии с инструкцией.

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

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

В варианте осуществления, индикация дополнительной попытки вызова принимается объектом управления службой в начальном сообщении, содержащем элемент информации для индикации дополнительной попытки вызова. Использование начального сообщения преимущественно предоставляет то, что объект управления службой проинформирован о дополнительной попытке вызова на начальном этапе вызова. Это позволяет объекту управления службой брать управление обработки дополнительной попытки вызова на раннем этапе. Элемент информации предпочтительно специализирован, то есть предварительно заданные значения могут использоваться для индикации дополнительной попытки вызова на предварительно заданных позициях в начальном сообщении с предопределениями, известными как объекту управления службой, так и объекту коммутации службы. Общее обозначение с предварительно заданными значениями и предварительно заданными позициями элемента информации в начальном сообщении облегчает вставку и извлечение значения как для коммутации службы, так и для объекта управления службой. Начальное сообщение и специализированный элемент информации предпочтительно стандартизированы, хотя, если стандартизация не возможна, могут использоваться собственные расширения.

В варианте осуществления, индикация хранимой информации вызова, связанной с первой попыткой вызова, принимается объектом управления службой в начальном сообщении, содержащем элемент информации для индикации хранимой информации вызова. Использование начального сообщения преимущественно обеспечивает то, что объект управления службой дает выигрыш в знании о хранимой информации вызова, связанной с первой попыткой вызова и начальной стадии дополнительной попытки вызова. Это позволяет объекту взять управление над обработкой попытки вызова на ранней стадии, даже до того, как была завершена дополнительная попытка вызова.

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

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

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

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

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

Краткое описание чертежей

Фиг.1 изображает схематическую иллюстрацию телекоммуникационной сети, содержащей интеллектуальную сеть в соответствии с предшествующим уровнем техники.

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

Фиг.3 изображает схему последовательности операций этапов способа, осуществляемого объектом управления службой.

Фиг.4 изображает схему последовательности операций этапов способа, осуществляемого объектом коммутации службы.

Фиг.5 изображает схему последовательности операций этапов способа, осуществляемого узлом коммутации.

Фиг.6 изображает схему последовательности операций этапов способа, осуществляемого базой данных абонента.

Фиг.7 изображает блок-схему варианта осуществления объекта управления службой.

Фиг.8 изображает блок-схему варианта осуществления объекта коммутации службы.

Фиг.9 изображает блок-схему варианта осуществления узла коммутации.

Фиг.10 изображает блок-схему варианта осуществления базы данных абонента.

Подробное описание

Фиг.2 изображает диаграмму последовательности, показывающую сообщения, обменянные в телекоммуникационной сети в примерном варианте осуществления изобретения. Изображенное является вызывающим объектом CE201, базой данных SD202 абонента, узлом SN203 коммутации, объектом SSE204 коммутации службы и объектом SCE205 управления службой. Вызывающий объект CE201 осуществляет связь с узлом SN203 коммутации. База данных SD202 абонента содержит информацию абонента о вызывающем объекте CE201, и способна обмениваться информацией с узлом SN203 коммутации и дополнительными базами данных абонента, например, с базой данных абонента, ассоциированной с вызываемым объектом, не показанным на Фиг.2. Объект SSE204 коммутации службы осуществляет связь с узлом SN203 коммутации. Предпочтительно, объект SSE204 коммутации службы совмещен с узлом SN203 коммутации. Объект SCE205 управления службой содержит логику службы для выполнения служб интеллектуальной сети и способен осуществлять связь с объектом SSE204 коммутации службы.

Объект SCE205 управления службой и объект SSE204 коммутации службы являются частью интеллектуальной сети, как описано со ссылкой на Фиг.1. Объект SCE205 управления службой имеет функции, схожие с функциями точки 101 управления службой с Фиг.1, но является усовершенствованным с новыми признаками, как будет подробно описано ниже со ссылкой на Фиг.7. Объект SSE204 коммутации службы имеет функции, схожие с функциями функции 102 коммутации службы с Фиг.1, но является усовершенствованным с новыми признаками, как будет подробно описано ниже со ссылкой на Фиг.8. Узел SN203 коммутации также является частью сети, описанной со ссылкой на Фиг.1. Узел SN203 коммутации имеет функции, схожие с функциями MSC 103 с Фиг.1, но является усовершенствованным с новыми признаками, как будет подробно описано ниже со ссылкой на Фиг.9.

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

На первом этапе 210 узел SN203 коммутации отправляет уведомление о том, что первая попытка вызова потерпела неудачу на объект SSE204 коммутации службы. Первая попытка вызова может потерпеть неудачу, например, из-за того, что вызываемый объект занят или не достижим, из-за возникновения перегрузки в сети, или из-за того, что вызываемый объект на отвечает на вызов. Узел SN203 коммутации может принять индикацию от дополнительного узла коммутации, обслуживающего вызываемый объект, не изображенный, причем индикация проходит через узел коммутации, обслуживающий вызывающий объект. В соответствии с вариантом осуществления, узел SN203 коммутации может также отправлять индикацию причины неудачи на объект SSE204 коммутации службы. Индикация причины неудачи может быть отправлена в том же самом сообщении, что и индикация того, что первая попытка вызова потерпела неудачу, или в отдельном сообщении. Сообщение может быть сообщением о высвобождении (REL), как задано в протоколе управления вызовом пользовательской части (ISUP) цифровой сети с интеграцией обслуживания (ISDN).

На следующем этапе 211 объект SSE204 коммутации службы отправляет индикацию того, что первая попытка вызова потерпела неудачу на объект SCE205 управления службой, например, в отчете о событии. Если индикация причины неудачи принята объектом SSE204 коммутации службы на этапе 210, он может также отправлять индикацию причины на объект SCE205 управления службой. Причина неудачи, в дальнейшем варианте осуществления, может содержать диагностику причины, дающую индикацию - может ли служба завершения вызова, такая как CCBS, быть применена к вызову.

Объект SCE205 управления службой получает информацию вызова, относящуюся к первой попытке вызова на этапе 212. Информация вызова может содержать индикацию каждого из следующего: идентификатор вызывающего объекта, идентификатор вызываемого объекта, набранный номер (например, короткий номер, ассоциированный с вызываемым объектом), время и дата первой попытки вызова, и местоположение вызывающего объекта во время первой попытки вызова. В соответствии с предпочтительным вариантом осуществления, информация вызова может указывать дополнительно одно из следующего: размера оплаты звонка, схемы трансляции номера, применимой к целевому номеру вызываемого объекта и индикатора взаимодействия добавочных служб для вызова.

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

В соответствии с этапом 213, объект SCE205 управления службой отправляет инструкцию на объект SSE204 коммутации службы для инициации хранения информации вызова, относящейся к первой попытке вызова для дальнейшего обращения. Инструкция может быть отправлена в сообщении ContinueWithArgument (CWA) (Продолжить с аргументом) CAMEL. В последующих вариантах осуществления, не изображенных, объект SCE205 управления службой отправляет инструкцию для инициации хранения информации вызова напрямую SD202.

На этапе 214, объект SSE204 коммутации службы отправляет инструкцию, принятую на этапе 213, на узел SN203 коммутации.

В соответствии с этапом 215, узел SN203 коммутации предоставляет вызывающему объекту CE201 вариант инициировать дополнительную попытку вызова, когда вызываемый объект становится доступным. Вызывающий объект CE201 отправляет ответ на узел SN203 коммутации на этапе 216.

На этапе 217 узел SN203 коммутации отправляет инструкцию, принятую на этапе 214, на базу данных SD202 абонента, например, в сообщении протокола мобильных приложений (MAP). В соответствии с вариантом осуществления, инструкция отправляется на базу данных SD202 абонента при условии, что ответ от вызывающего объекта CE201, принятый на этапе 216, указывает, что вызывающий объект CE201 выбрал вариант инициировать дополнительную попытку вызова, когда вызываемая сторона станет доступной.

База данных SD202 абонента хранит, на этапе 218, информацию вызова, относящуюся к первой попытке вызова, в ответ на инструкцию, принятую от узла SN203 коммутации. В качестве альтернативы, инструкция принимается непосредственно от объекта SCE205 управления службой.

В соответствии с этапом 219, база данных SD202 абонента принимает индикацию того, что вызываемый объект является доступным. Индикация может быть принята от базы данных абонента, ассоциированной с вызываемым объектом.

На этапе 220 база данных SD202 абонента отправляет на узел SN203 коммутации индикацию того, что вызываемый объект является доступным.

На этапе 221 база данных SD202 абонента отправляет хранящуюся информацию вызова, относящуюся к первой попытке вызова. Если инструкция, принятая на этапе 217, принята от узла SN203 коммутации, то хранящаяся информация вызова отправляется назад на узел SN203 коммутации. В соответствии с вариантом осуществления, этапы 220 и 221 могут быть объединены в один этап, посредством чего индикация того, что вызываемый объект является доступным, и хранящаяся информация вызова отправляются на узел SN203 коммутации в сообщении MAP о том, что удаленный пользователь свободен.

В качестве альтернативы, если инструкция, принятая на этапе 217, принята непосредственно от объекта SCE205 управления службой, то хранящаяся информация вызова отправляется назад на объект SCE205 управления службой.

Примерный способ продолжается далее на этапе 222, на котором узел SN203 коммутации осуществляет этап инициации дополнительной попытки вызова от вызывающего объекта CE201 к вызываемому объекту. В соответствии с вариантом осуществления, узел SN203 коммутации отправляет сообщение вызывающему объекту CE201 для сигнализации о том, что вызываемый объект является доступным. Если вызывающий объект CE201 отправляет узлу SN203 коммутации сообщение, указывающее, что он принимает дополнительную попытку вызова, узел SN203 коммутации инициирует настройку попытки вызова к вызываемому объекту.

В соответствии с этапом 223, узел SN203 коммутации осуществляет этап отправки индикации дополнительной попытки вызова на объект SSE204 коммутации службы.

Узел SN203 коммутации отправляет хранящуюся информацию вызова, относящуюся к первой попытке вызова на объект SSE204 коммутации службы на этапе 224. В соответствии с вариантом осуществления, этапы 223 и 224 могут быть объединены в один этап.

В соответствии с этапом 225, объект SSE204 коммутации службы отправляет индикацию дополнительной попытки вызова на объект SCE205 управления службой. Объект SSE204 коммутации службы может отправлять индикацию объекту SCE205 управления службой в начальном сообщении, предпочтительно в сообщении начальной точки обнаружения (IDP) CAMEL.

Объект SSE204 коммутации службы отправляет информацию вызова, относящуюся к первой попытке вызова, если она принята от узла SN203 коммутации, на объект SCE205 управления службой на этапе 226. Информация вызова может быть отправлена в том же самом сообщении, что и индикация дополнительной попытки вызова на этапе 225.

В соответствии с альтернативным вариантом осуществления, хранящаяся информация принимается объектом SCE205 управления службой напрямую от базы данных SD202 абонента. Объект SCE205 управления службой может отправлять запрос базе данных SD202 абонента для извлечения хранящейся информации вызова.

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

В соответствии с этапом 228, инструкция отправляется от объекта SCE205 управления службой на объект SSE204 коммутации службы для продолжения настройки дополнительной попытки вызова в соответствии с процедурой установления вызова.

На этапе 229, объект SSE204 коммутации службы отправляет сообщение на узел SN203 коммутации для установления вызова в соответствии с инструкцией от объекта SCE205 управления службой.

В последующих параграфах подробное описание приведено со ссылкой на фигуры с 3 по 6 примерных способов, осуществленных соответствующими устройствами, изображенными на Фиг.2.

Фиг.3 изображает примерные этапы, осуществляемые объектом управления службой в соответствии с вариантом осуществления изобретения.

На начальном этапе, объект коммутации службы отправляет сообщение на объект управления службой, например, в сообщении отчета о событии BCSM (модели состояния базового вызова) CAMEL, содержащем индикацию того, что первая попытка вызова от вызывающего объекта к вызываемому объекту потерпела неудачу. Объект коммутации службы может принимать индикацию от узла коммутации, обслуживающего вызываемый объект.

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

Способ может продолжиться на этапе 302, на котором объект управления службой осуществляет этап приема, от объекта коммутации службы, индикации дополнительной попытки вызова от вызывающего объекта к вызываемому объекту. Объект управления службой теперь проинформирован о том, что дополнительная попытка вызова инициирована по отношению к первой попытке вызова, которая потерпела неудачу. В соответствии с вариантом осуществления, индикация дополнительной попытки вызова может быть принята в начальном сообщении, например в сообщении начальной точки обнаружения (IDP) CAMEL, содержащем элемент информации для индикации дополнительной попытки вызова.

На этапе 303, информация вызова, относящаяся к первой попытке вызова, принимается объектом управления службой. Информация вызова может содержать одно из следующего: идентификатор вызывающего объекта, идентификатор вызываемого объекта, набранный номер (например, короткий номер, ассоциированный с вызываемым объектом), время и дату первой попытки вызова, и местоположения вызывающего объекта во время первой попытки вызова. В соответствии с предпочтительным вариантом осуществления, информация вызова может указывать дополнительно одно из следующего: размер оплаты звонка, схему трансляции номера, применимую к предназначенному номеру вызываемого объекта и индикатора взаимодействия добавочных служб для вызова.

В варианте осуществления, информация вызова, относящаяся к первой попытке вызова, принимается из внешней памяти объекта управления службой после того, как она хранилась во время первой попытки вызова. В качестве альтернативы, объект управления службой может заранее отправить инструкцию на объект коммутации службы для инициации хранения информации вызова, относящейся к первой попытке вызова, например, в базе данных абонента. Инструкция может быть отправлена в сообщении ContinueWithArgument (CWA) CAMEL. База данных абонента, которая может хранить информацию вызова, может быть регистром домашнего местоположения (HLR), ассоциированным с вызывающим объектом. В дополнительном альтернативном варианте осуществления, объект управления службой отправляет инструкцию для инициации хранения информации вызова, относящейся к первой попытке вызова, напрямую к базе данных абонента.

Хранящаяся информация вызова, относящаяся к первой попытке вызова, может впоследствии быть восстановлена во время настройки дополнительной попытки вызова. Она может быть принята объектом управления службой, посредством объекта коммутации службы и дополнительных узлов коммутации между базой данных абонента и объектом коммутации службы, совместно с этапом приема индикации дополнительной попытки вызова. В предпочтительном варианте осуществления, хранящаяся информация, относящаяся к первой попытке вызова, может быть принята в том же самом начальном сообщении, что и индикация дополнительной попытки вызова. Начальное сообщение может содержать элемент информации для индикации хранящейся информации вызова. В соответствии с альтернативным вариантом осуществления, хранящаяся информация вызова принимается объектом управления службой напрямую от базы данных абонента. Объект управления службой может запросить базу данных абонента отправить хранящуюся информацию вызова.

В соответствии с этапом 304, объект управления службой осуществляет этап определения процедуры установления вызова для дополнительной попытки вызова, на основе информации вызова, относящейся к первой попытке вызова. Логика службы объекта управления службой может анализировать информацию вызова, полученную на предыдущем этапе, и определять подходящую процедуру установления вызова, которая будет применена к дополнительной попытке вызова с использованием информации вызова из первой попытки вызова. Например, объект управления службой может решить оставить целевой номер как принятый, ассоциированный с вызываемым номером, неизменным, то есть не применять схему трансляции номера к дополнительной попытке вызова. Это частично является преимуществом в следующей ситуации. Она может возникнуть, когда узел коммутации, который выполняет службу завершения вызова, после того как управление вызовом возвращается от объекта управления службой, высвобождает вызов, когда он осознает, что целевой номер был изменен службой в объекте управления службой, например службой виртуальной частной сети (VPN). Причина этого поведения заключается в том, что дополнительная попытка вызова больше не расценивается узлом коммутации, как относящаяся к первой попытке вызова, и считается запрещенной. В соответствии с этапами, осуществляемыми объектом управления службой, объект управления службой осведомлен, что дополнительная попытка вызова относится к потерпевшей неудачу первой попытке вызова, и он может решить не изменять целевой номер. Поэтому дополнительная попытка вызова может быть установлена узлом коммутации. В другом примере или дополнении, объект управления службой может определять процедуру установления вызова, которая применяет тот же самый размер оплаты, который был применен к первой попытке вызова. Преимущество этого заключается в том, что с вызывающего объекта взимается размер оплаты в соответствии с размером оплаты для первой попытки вызова, даже если размер оплаты мог измениться из-за времени суток, или изменения местоположения вызывающего объекта.

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

В соответствии с этапом 305, инструкция отправляется от объекта управления службой на объект коммутации службы для продолжения настройки дополнительной попытки вызова в соответствии с процедурой установления вызова. Инструкция может быть отправлена в сообщении CAMEL Connect (Соединить), Continue (Продолжить) или ContinueWithArgument (продолжить с аргументом), в зависимости от типа инструкции. Объект управления службой может, до отправки инструкции и в зависимости от типа инструкции, предоставлять объекту коммутации службы инструкции оплаты, такие как CAMEL Apply charging (применение оплаты), Furnish charging information (информация доставки оплаты) или Send charging information (информация отправки оплаты). На этом способ может закончиться или может продолжиться любым из этапов, описанных здесь.

Фиг.4 изображает примерные этапы, осуществляемые объектом коммутации службы в соответствии с вариантом осуществления изобретения.

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

В соответствии с этапом 401, объект коммутации службы может осуществлять этап приема, от узла коммутации, индикации того, что первая попытка вызова вызываемому объекту потерпела неудачу. Сообщение, содержащее индикацию того, что первая попытка вызова потерпела неудачу, может также содержать индикацию причины неудачи, например, занятость или не достижимость вызываемого объекта, возникновение перегрузки в сети, или не ответ на вызов вызываемого объекта. Сообщение может быть сообщением о высвобождении (REL)ISUP.

Впоследствии объект коммутации службы осуществляет этап отправки индикации того, что первая попытка вызова вызываемому объекту потерпела неудачу на объект управления службой на этапе 402. Объект коммутации службы может отправлять индикацию на объект управления службой в отчете о событии, предпочтительно в сообщении отчета о событии BCSM CAMEL. В варианте осуществления, объект коммутации службы может также отправлять индикацию причины неудачи, если оно принято от узла коммутации, на объект управления службой в том же самом или отдельном сообщении.

В соответствии с вариантом осуществления, объект коммутации службы может принимать инструкцию от объекта управления службой для инициации хранения информации вызова, относящейся к первой попытке вызова, например, в базе данных абонента. Инструкция может быть принята в сообщении CAMEL ContinueWithArgument (продолжить с аргументом) (CWA). База данных абонента, которая может хранить информацию вызова, может быть регистром домашнего местоположения (HLR), ассоциированным с вызывающим объектом. Объект коммутации службы может отправлять инструкцию на узел коммутации, для дальнейшего направления к базе данных абонента.

На этапе 403, объект коммутации службы может осуществлять этап приема, от узла коммутации, индикации того, что дополнительная попытка вызова к вызываемому объекту была инициирована. Индикация может быть принята в ISUP IAM (Начальное адресное сообщение). Протокол ISUP, который используется между узлом коммутации и объектом коммутации службы, может быть внешним ISUP или ISUP внутри узла.

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

В соответствии с этапом 404, объект коммутации службы осуществляет этап отправки индикации дополнительной попытки вызова на объект управления службой. Объект коммутации службы может отправлять индикацию на объект управления службой в начальном сообщении, предпочтительно в сообщении начальной точки обнаружения (IDP) CAMEL. Сообщение может содержать элемент информации для индикации того, что дополнительная попытка вызова относится к первой попытке вызова, которая потерпела неудачу. В дополнительном варианте осуществления, объект коммутации службы может отправлять информацию вызова, относящуюся к первой попытке вызова, если принята от узла коммутации, на объект управления службой, в том же самом или отдельном сообщении. Начальное сообщение может содержать элемент информации для индикации хранимой информации вызова.

В соответствии с этапом 405, объект коммутации службы осуществляет этап приема инструкции от объекта управления службой для продолжения настройки дополнительной попытки вызова. Инструкция может быть принята в сообщении CAMEL Connect, Continue или ContinueWithArgument, в зависимости от типа инструкции. Объект коммутации службы может, до приема инструкции, принимать инструкции оплаты, такие как CAMEL Apply charging, Furnish charging information или Send charging information.

Способ может продолжиться на этапе 406, на котором объект коммутации службы осуществляет этап выполнения инструкции, то есть установления дополнительной попытки вызова в соответствии с принятой инструкцией.

На этом способ может закончиться или может продолжиться любым из этапов, описанных здесь.

Фиг.5 изображает примерные этапы, осуществляемые узлом коммутации в соответствии с вариантом осуществления изобретения. Узел коммутации может быть мобильным центром коммутации (MSC).

На первом этапе 501, узел коммутации осуществляет этап отправки индикации того, что первая попытка вызова от вызывающего объекта к вызываемому объекту потерпела неудачу, на объект коммутации службы. Узел коммутации может принимать индикацию от дополнительного узла коммутации, обслуживающего вызываемый объект. Узел коммутации может отправлять индикацию того, что первая попытка вызова потерпела неудачу на объект коммутации службы в сообщении, содержащем также индикацию причины сбоя, например, занятость или не достижимость вызываемого объекта, возникновение перегрузки в сети, или не ответ на вызов вызываемого объекта. Причина неудачи может, необязательно, содержать диагностику причины. Сообщение может быть сообщением о высвобождении (REL)ISUP.

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

На этапе 503, узел коммутации отправляет инструкцию, принятую на этапе 502, к базе данных абонента, предпочтительно к регистру домашнего местоположения (HLR), ассоциированному с вызывающим объектом. Узел коммутации может отправлять инструкцию в сообщении протокола мобильных приложений (MAP). В соответствии с вариантом осуществления, узел коммутации может предоставлять вызывающему объекту вариант инициировать дополнительную попытку вызова, когда вызываемый объект становится доступным. Вызывающий объект отправляет ответ на узел коммутации. В соответствии с дополнительным вариантом осуществления, этап 503, то есть отправка инструкции для инициации хранения информации вызова, относящейся к первой попытке вызова на базу данных абонента, осуществляется на условии того, что ответ от вызывающего объекта указывает, что вызывающая сторона выбирает вариант принять предложение для дополнительной попытки вызова, когда вызываемый объект становится доступным.

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

Узел коммутации принимает хранящуюся информацию вызова, относящуюся к первой попытке вызова от базы данных абонента, предпочтительно от базы данных абонента, ассоциированной с вызывающим объектом, на этапе 505. В соответствии с вариантом осуществления, этапы 504 и 505 могут быть объединены в один этап, в котором индикация того, что вызываемый объект является доступным и хранящаяся информация принимаются узлом коммутации в сообщении MAP о том, что удаленный пользователь свободен.

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

В соответствии с этапом 507, узел коммутации осуществляет этап отправки индикации дополнительной попытки вызова на объект коммутации службы. Узел коммутации отправляет индикацию, например, в начальном адресном сообщении (IAM) ISUP, на объект коммутации службы.

На этапе 508, узел коммутации отправляет хранящуюся информацию, относящуюся к первой попытке вызова, на объект коммутации службы. В соответствии с вариантом осуществления, этапы 507 и 508 могут быть объединены в один этап, в котором индикация дополнительной попытки вызова и хранящаяся информация вызова отправляются на объект коммутации службы в одном начальном адресном сообщении (IAM) ISUP. Сообщение IAM содержит элемент информации для индикации хранящейся информации вызова.

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

На этом способ может закончиться или может продолжиться любым из этапов, описанных здесь.

Фиг.6 изображает примерные этапы, осуществляемые базой данных абонента в соответствии с вариантом осуществления изобретения. База данных абонента может быть регистром домашнего местоположения (HLR). Предпочтительно, HLR, ассоциированным с вызывающим объектом.

На первом этапе 601, база данных абонента принимает инструкцию для хранения информации вызова, относящейся к первой попытке вызова от вызывающего объекта к вызываемому объекту. Инструкция принимается, например, в сообщении-запросе завершения вызовов занятому абоненту (CCBS) MAP. Сообщение-запрос MAP CCBS содержит элемент информации для индикации информации вызова, относящейся к первой попытке вызова. В соответствии с вариантом осуществления, инструкция принимается от узла коммутации. В качестве альтернативы, инструкция принимается от объекта управления службой. На следующем этапе 602, база данных абонента хранит информацию вызова, относящуюся к первой попытке вызова. База данных абонента может принимать множественные запросы на хранение информации вызова, относящейся к соответствующим множественным первым попыткам вызова, ассоциированным с одной и той же вызывающей стороной. Информация вызова, ассоциированная с каждой из множества первых попыток вызова, может быть сохранена индивидуально базой данных абонента.

В соответствии с этапом 603, база данных абонента принимает индикацию того, что вызываемый объект является доступным. Индикация может быть принята от базы данных абонента, ассоциированной с вызываемым объектом.

База данных абонента, на этапе 604, отправляет индикацию того, что вызываемый объект является доступным на узел коммутации.

На этапе 605, база данных абонента отправляет хранящуюся информацию вызова, относящуюся к первой попытке вызова. Если инструкция, принятая на этапе 601, принята от узла коммутации, хранящаяся информация вызова отправляется назад на узел коммутации. В соответствии с вариантом осуществления, этапы 604 и 605 могут быть объединены в один этап, в котором индикация того, что вызываемый объект является доступным и хранящаяся информация вызова отправляются на узел коммутации в сообщении MAP, что удаленный пользователь свободен. В качестве альтернативы, если инструкция, принятая на этапе 601, принята напрямую от объекта управления службой, хранящаяся информация отправляется назад на объект управления службой.

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

На этом способ может закончиться или может продолжиться любым из этапов, описанных здесь.

Изобретение, кроме того, осуществлено в устройствах, которые описаны более подробно ниже со ссылками на Фиг.7, 8, 9 и 10. Ссылочные позиции использованы только для иллюстрации и не предназначены быть ограничивающими.

Фиг.7 изображает вариант осуществления объекта SCE7 управления службой, содержащего блок RU7 приема для приема сообщений, блок TU7 передачи для передачи сообщений, блок PU7 обработки для обработки сообщений и информации, содержащий блок CU7 оперирования информацией вызова, и предпочтительно, блок SU7 хранения для хранения и/или получения хранящейся информации.

Объект управления службой может быть автономным устройством. Тем не менее, возможно, что объект управления службой функционирует на узле коммутации, например, как аппаратное оборудование и/или субблок программного обеспечения узла коммутации. Объект управления службой может быть установлен и запущен в работу на узле коммутации, не используя совместно ни один из блоков RU7, TU7, PU7, CU7 с узлом коммутации, или используя совместно, по меньшей мере, один из блоков RU7, TU7, PU7, CU7 с блоками узла коммутации. Альтернативным вариантом осуществления является объект управления службой в соответствии с компьютерной программой, загружаемой в блок обработки узла коммутации.

Блок PU7 обработки может быть выполнен с возможностью обрабатывать индикацию того, что первая попытка вызова потерпела неудачу, принятое посредством блока RU7 приема от объекта коммутации службы. Кроме того, блок PU7 обработки может быть выполнен с возможностью обрабатывать индикацию дополнительной попытки вызова, принятой посредством блока RU7 приема от объекта коммутации службы. Блок CU7 оперирования информацией вызова может быть выполнен с возможностью получать информацию вызова, относящуюся к первой попытке вызова. Блок PU7 обработки может быть дополнительно выполнен с возможностью определять процедуру установления вызова для дополнительной попытки вызова, на основе информации вызова, относящейся к первой попытке вызова, и инициировать передачу инструкции на объект коммутации службы, посредством блока TU7 передачи, для продолжения настройки дополнительной попытки вызова, в соответствии с процедурой установления вызова.

В соответствии с вариантом осуществления, блок CU7 оперирования информацией вызова может быть выполнен с возможностью инициировать передачу инструкции для инициации хранения информации вызова, относящейся к первой попытке вызова, посредством блока TU7 передачи, одному из: объект коммутации службы и база данных абонента, соединенных с объектом управления службой. Дополнительно, блок CU7 оперирования информацией вызова может быть выполнен с возможностью обрабатывать хранящуюся информацию вызова, относящуюся к первой попытке вызова, принятой посредством блока RU7 приема, совместно с приемом индикации дополнительной попытки вызова.

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

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

Фиг.8 изображает вариант осуществления объекта SSE8 коммутации службы, содержащего блок IU8 ввода, блок OU8 вывода, блок PU8 обработки для обработки сообщений и информации, содержащий блок CU8 оперирования информацией вызова, и предпочтительно, блок SU8 хранения для хранения и/или получения хранящейся информации.

Объект коммутации службы может быть автономным устройством, а блок IU8 ввода и блок OU8 вывода могут быть внешними интерфейсами, такими как блок приема для приема сообщений и блок передачи для передачи сообщений соответственно. Предпочтительно, объект коммутации службы функционирует на узле коммутации, например, как аппаратное оборудование и/или субблок программного обеспечения узла коммутации. Объект коммутации службы может быть установлен и запущен в работу на узле коммутации, не используя совместно ни один из блоков IU8, OU8, PU8, SU8 с узлом коммутации, или используя совместно, по меньшей мере, один из блоков IU8, OU8, PU8, SU8 с блоками узла коммутации, содержащими блок для приема сообщений, блок передачи для отправки сообщений, блок обработки для обработки сообщений и информации, и предпочтительно, блок хранения. Предпочтительным вариантом осуществления является объект коммутации службы в соответствии с компьютерной программой, загружаемой в блок обработки узла коммутации.

Блок PU8 обработки может быть выполнен с возможностью обрабатывать индикацию того, что первая попытка вызова потерпела неудачу, принятое, посредством блока IU8 ввода, от узла коммутации, и инициировать отправку индикации, посредством блока OU8 вывода, на объект управления службой. Кроме того, блок PU8 обработки может быть выполнен с возможностью обрабатывать индикацию дополнительной попытки вызова, принятой посредством блока IU8 ввода, от узла коммутации, и инициировать передачу индикации дополнительной попытки вызова, посредством блока OU8 вывода, на объект управления службой. Блок PU8 обработки может быть дополнительно выполнен с возможностью обрабатывать инструкцию, принятую посредством блока IU8 ввода, от объекта управления службой, для продолжения настройки дополнительной попытки вызова и для установления дополнительной попытки вызова в соответствии с принятой инструкцией.

В соответствии с вариантом осуществления, блок IU8 ввода может быть выполнен с возможностью принимать инструкцию для инициации хранения информации вызова, относящейся к первой попытке вызова от объекта управления службой. Блок CU8 оперирования информацией вызова может быть выполнен с возможностью инициировать передачу, посредством блока OU8 вывода, на узел коммутации, инструкцию для инициации хранения информации вызова, относящейся к первой попытке вызова. Дополнительно, блок IU8 ввода может быть выполнен с возможностью принимать хранящуюся информацию вызова, относящуюся к первой попытке вызова, от узла коммутации, совместно с приемом индикации дополнительной попытки вызова. Блок CU8 оперирования информацией вызова может быть дополнительно выполнен с возможностью инициировать отправку, посредством блока OU8 вывода, на объект управления службой хранящейся информации вызова, относящейся к первой попытке вызова, совместно с отправкой индикации дополнительной попытки вызова.

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

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

Фиг.9 изображает вариант осуществления узла SN9 коммутации, содержащего блок IU9 ввода, блок OU9 вывода, блок PU9 обработки для обработки сообщений и информации, содержащий блок CU9 оперирования информацией вызова, и предпочтительно, блок SU9 хранения для хранения и/или получения хранящейся информации.

Блок PU9 обработки может быть выполнен с возможностью отправлять индикацию того, что первая попытка вызова потерпела неудачу, посредством блока OU9 вывода, на объект коммутации службы. Блок IU9 ввода может быть выполнен с возможностью принимать инструкцию, для инициации хранения информации вызова, относящейся к первой попытке вызова, от объекта коммутации службы. Блок CU9 оперирования информацией вызова может быть выполнен с возможностью инициировать передачу, посредством блока OU9 вывода, на базу данных абонента, инструкции для инициации хранения информации вызова, относящейся к первой попытке вызова. Дополнительно, блок IU9 ввода может быть выполнен с возможностью принимать от базы данных абонента, индикацию того, что вызываемый объект является доступным, и принимать информацию вызова, относящуюся к первой попытке вызова. Блок PU9 обработки может быть выполнен с возможностью инициировать дополнительную попытку вызова от вызывающего объекта к вызываемому объекту, и инициировать передачу индикации дополнительной попытки вызова, посредством блока OU9 вывода, на объект коммутации службы. Блок CU9 оперирования информацией вызова может быть дополнительно выполнен с возможностью инициировать отправку, посредством блока OU9 вывода, на объект коммутации службы, хранящейся информации вызова, относящейся к первой попытке вызова.

В соответствии с вариантом осуществления, блок PU9 обработки может быть выполнен с возможностью предоставлять, посредством блока OU9 вывода, вызывающему объекту вариант инициировать дополнительную попытку вызова, когда вызываемый объект становится доступным, и обрабатывать, по выбору, ответ от вызывающего объекта, принятый посредством блока IU9 ввода.

Фиг.10 изображает вариант осуществления базы данных SD10 абонента, содержащей блок IU10 ввода, блок OU10 вывода, блок PU10 обработки для обработки сообщений и информации, содержащий блок CU10 оперирования информацией вызова, и предпочтительно, блок SU10 хранения для хранения и/или получения хранящейся информации.

Блок IU10 ввода может быть выполнен с возможностью принимать инструкцию для инициации хранения информации вызова, относящейся к первой попытке вызова. Блок CU10 оперирования информацией вызова может быть выполнен с возможностью хранить информацию вызова, относящуюся к первой попытке вызова в блоке SU10 хранения. Дополнительно, блок IU10 ввода может быть выполнен с возможностью принимать индикацию того, что вызываемый объект является доступным. Блок PU10 обработки может быть выполнен с возможностью инициировать передачу индикации того, что вызываемый объект является доступным на узел коммутации, посредством блока OU10 вывода. Блок CU10 оперирования информацией вызова может быть дополнительно выполнен с возможностью извлечения информации вызова, относящейся к первой попытке вызова, из блока SU10 хранения, и инициирования отправки хранящейся информации вызова, относящейся к первой попытке вызова, посредством блока OU10 вывода.

В соответствии с вариантом осуществления, инструкция для инициации хранения информации вызова, относящейся к первой попытке вызова, принимается посредством блока IU10 ввода от узла коммутации. Дополнительно, хранящаяся информация вызова, относящаяся к первой попытке вызова, отправляется посредством блока OU10 вывода на узел коммутации.

В соответствии с другим вариантом осуществления, инструкция для инициации хранения информации вызова, относящейся к первой попытке вызова, принимается посредством блока IU10 ввода от объекта управления службой. Дополнительно, информация вызова, относящаяся к первой попытке вызова, отправляется, посредством блока OU10 вывода, на объект управления службой.

Протоколы IN такие, как прикладная подсистема CAMEL (CAP, например CAPv4, смотри 3GPP TS 29.078 и 3GPP TS 23.078) предпочтительно изменены, по меньшей мере, одним из следующих подробных расширений, для того, чтобы предоставить объекту коммутации службы и объекту управления службой возможности в соответствии с изобретением:

a) новый элемент информации (IE) может быть добавлен в сообщение "начальной точки обнаружения" (InitialDP или сокращенно IDP) для индикации объекту управления службой, что активизация относится к дополнительной попытке вызова, относящейся к первой попытке вызова, которая потерпела неудачу:

Название элемента информации	Описание
Настройка службы завершения вызова	Этот IE указывает, что активизация службы относится к дополнительной попытке вызова, относящейся к первой попытке вызова, которая потерпела неудачу

IDP, содержащая новый элемент информации, может быть использована объектом коммутации службы, для отправки индикации дополнительной попытке вызова на объект управления службой.

b) новый элемент информации (IE) может быть добавлен в сообщение "начальной точки обнаружения" (InitialDP или сокращенно IDP) для индикации объекту управления службой хранящейся информации, относящейся к первой попытке вызова.

Название элемента информации	Описание
Данные информации вызова свободного формата	Этот IE содержит индикацию информации вызова, относящейся к первой попытке вызова

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

с) Сообщение "ContinueWithArgument" (CWA) может быть использовано для переноса информации, касающейся инструкции для инициации хранения информации вызова, относящейся к первой попытке вызова, на объект коммутации службы для дополнительной попытки вызова. Новый элемент информации (IE) "данные информации вызова свободного формата" может быть добавлен для этой цели к "ContinueWithArgument".

Название элемента информации	Описание
Данные информации вызова свободного формата	Этот IE содержит индикацию информации вызова, относящейся к первой попытке вызова

Сообщение "ContinueWithArgument" содержит новые данные информации вызова свободного формата, которые могут использоваться объектом управления службой для отправки инструкции на объект коммутации службы для инициации хранения информации вызова.

Кроме того, протокол MAP предпочтительно изменяется следующим расширением для того, чтобы предоставить узлу коммутации и базе данных абонента возможности в соответствии с изобретением.

а) Новый элемент информации (IE) может быть добавлен в сообщение MAP REGISTER CC ENTRY, сообщение MAP CCBS REQUEST и в сообщение MAP REMOTE USER FREE для индикации хранящейся информации, относящейся к первой попытке вызова.

Название элемента информации	Описание
Данные информации вызова свободного формата	Этот IE содержит индикацию информации вызова, относящуюся к первой попытке вызова

Очевидно, что изобретение может быть реализовано в любой телекоммуникационной сети, такой как GSM, множественный доступ с кодовым разделением (CDMA), множественный доступ с временным разделением (TDMA), универсальная мобильная телекоммуникационная система (UMTS) или сеть 4G. Объект управления службой обычно осуществлен в одном устройстве или может быть распределен по нескольким устройствам. Соответствующее применимо и к объекту коммутации службы. Объект управления службой и объект коммутации службы могут быть реализованы как отдельные функции на одном и том же устройстве или платформе.