СПОСОБ ОБЕСПЕЧЕНИЯ УВЕДОМЛЕНИЙ В ВЫЗОВАХ С МОБИЛЬНЫХ ТЕЛЕФОНОВ Российский патент 2006 года по МПК H04M3/42 H04J3/24 

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

Настоящее изобретение относится к сетям мобильной связи, и, в частности, настоящее изобретение относится к способу обеспечения уведомлений для вызовов с мобильных телефонов в сети мобильной связи с использованием транспортного механизма IP (Интернет-протокола). В целом, беспроводные сети с коммутацией пакетов обеспечивают связь для мобильных терминалов без необходимости физического соединения для сетевого доступа. Для обеспечения связи сетей беспроводной связи со стороной коммутации пакетов, а также со стороной коммутации каналов были разработаны услуги пакетной радиосвязи общего назначения (УПРО, GPRS) в Глобальной системе мобильной связи (GSM) и Универсальная наземная система мобильной связи (УНСМ, UMTS).

Как отмечено на веб-сайте, http://www.3gpp.org, Проект сотрудничества по третьему поколению, общеизвестный под акронимом 3GPP, это организация, члены которой договорились совместными усилиями создавать технические описания и технические отчеты, применимые для всего мира, для системы мобильной связи 3-го поколения, основанной на базовых сетях GSM и технологиях радиального доступа, которые они поддерживают (т.е. Универсальный наземный радиодоступ (УНРД, UTRA) для режимов дуплекса с частотным разделением каналов (ДЧР, FDD) и дуплекса с временным разделением каналов (ДВР, TDD)).

Партнеры по 3GPP договорились также о сотрудничестве в поддержке и разработке технических описаний и технических отчетов для Глобальной системы мобильной связи (GSM), включающих в себя усовершенствованные технологии радиального доступа (например, услугу пакетной радиосвязи общего назначения (УПРО, GPRS) и увеличенные скорости передачи данных для развития GSM (EDGE)).

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

Техническое описание TS 23.060, версия V3.3.0, было выпущено 3GPP в январе 2001 г. и отменяет описание услуги стадии 2 для пакетного домена, который включает в себя GPRS в GSM и UMTS. Это техническое описание полностью включено в настоящее описание посредством ссылки. Описание различных элементов и их функций, включенное в настоящее описание изобретения посредством ссылки, представляет собой всего лишь неограничивающий пример сетей связи с коммутацией пакетов, и следует понимать, что настоящее изобретение не ограничивается такими сетями.

Сетевой абонент может иметь один или несколько адресов протокола передачи пакетных данных (PDP). Каждый адрес PDP описан одним или несколькими контекстами PDP на мобильной станции (МС), обслуживающем узле поддержки (УПРО, GPRS) (ОУПО, SGSN) и шлюзовом узле поддержки (УПРО, GPRS) (ШУПО, GGSN). GGSN - это шлюз во внешнюю сеть. Каждый контекст PDP может иметь информацию маршрутизации и отображения, позволяющую направлять перенос данных на связанный с ним адрес PDP и с него, и шаблон потока трафика (ШПТ) для приема переносимых данных.

Каждый контекст PDP можно избирательно и независимо активировать, модифицировать и деактивировать. Состояние активации контекста PDP указывает, разрешен ли перенос данных для соответствующего адреса PDP и ШПТ. Если все контексты PDP, связанные с одним и тем же адресом PDP, неактивны или деактивированы, то перенос всех данных для данного адреса PDP запрещен. Все контексты PDP абонента связаны с одним и тем же контекстом управления мобильностью (контроля перемещения мобильной станции) (ММ) для международного идентификатора мобильной станции (IMSI) этого абонента. Установление контекста PDP означает установление канала связи между МС и ШУПО.

На фиг.1, исключительно в иллюстративных целях, показана процедура активации контекста PDP между МС и ШУПО в системе УНСМ, что соответствует фиг.62 вышеупомянутого технического описания. Там также содержится нижеследующее описание этапов, указанных на фиг.1.

1) МС посылает в ОУПО сообщение запроса на активацию контекста PDP (ИТДСС (NSAPI) [Network layer Service Access Point Identifier - идентификатор точки доступа к службе сетевого уровня], ИТ [идентификатор транзакции], тип PDP, адрес PDP, имя точки доступа, запрашиваемое качеством обслуживания (КО, QoS), опции конфигурации PDP). МС должна использовать адрес PDP для указания, нужен ли ей статический адрес PDP или же динамический адрес PDP. Для запроса динамического адреса PDP, МС должна оставить адрес PDP пустым. МС может использовать имя точки доступа для выбора точки адресации на определенную внешнюю сеть и/или для выбора услуги. Имя точки доступа - это логическое имя, являющееся ссылкой на внешнюю сеть передачи пакетных данных и/или услугу, к которой абонент желает подключиться. Запрашиваемое КО указывает нужный профиль КО. Опции конфигурации PDP можно использовать для запроса от ШУПО необязательных параметров PDP (см. GSM 09.60). Опции конфигурации PDP передаются прозрачно через ОУПО.

3) В УНСМ, установление однонаправленного канала радиодоступа (ОНКРД, RAB) производят посредством процедуры назначения ОНКРД, см. подпункт "Процедура назначения ОНКРД".

5) ОУПО проверяет правомерность запроса активации контекста PDP с использованием типа PDP (необязательного), адреса PDP (необязательного) и имени точки доступа, обеспечиваемых МС и записями абонирования контекста PDP. Критерии проверки, критерии выбора имени точки доступа (ИТД, APN) и отображение ИТД в ШУПО описаны в Приложении А.

Если нельзя получить ни одного адреса ШУПО или если ОУПО определил неправомерность запроса активации контекста PDP, согласно правилам, описанным в Приложении А, то ОУПО отклоняет запрос активации контекста PDP.

Если можно получить адрес ШУПО, то ОУПО создает ИДКТ [идентификатор конечных точек туннеля] для запрашиваемого контекста PDP. Если МС запрашивает динамический адрес, то ОУПО позволяет ШУПО выделить динамический адрес. ОУПО может ограничить запрашиваемые атрибуты КО в соответствии со своими возможностями, текущей нагрузкой и абонированным профилем КО.

ОУПО посылает на используемый ШУПО запрос на создание контекста PDP (тип PDP, адрес PDP, имя точки доступа, согласованное КО, ИДКТ, ИТДСС, MSISDN [международный номер МС в цифровой сети с комплексными услугами (ЦСКУ) (ISDN)], режим выбора, характеристики начисления платежей, справка по трассе, тип трассы, ИД триггера, и идентификатор центра эксплуатации и поддержки (ЦЭП, ОМС), опции конфигурации PDP). Имя точки доступа должно быть сетевым идентификатором ИТД из ИТД, выбранных согласно процедуре, описанной в Приложении А. Адрес PDP должен быть пустым, если запрашивается динамический адрес. ШУПО может использовать имя точки доступа для нахождения внешней сети и, в необязательном порядке, для активации услуги для этого ИТД. Режим выбора указывает, выбрано ли абонированное ИТД или послала ли МС неабонированное ИТД или выбрано неабонированное ИТД, выбранное ОУПО. Режим выбора устанавливают согласно Приложению А. ШУПО может использовать режим выбора при принятии решения, принимать или отклонять активацию контекста PDP. Например, если ИТД требует абонирования, то ШУПО настраивают так, чтобы он принимал только такую активацию контекста PDP, которая запрашивает абонированное ИТД, которое ОУПО указал посредством режима выбора. Поле "характеристики начисления платежей" указывает, за какой вид начисления платежей отвечает контекст PDP. ОУПО должен копировать характеристики начисления платежей из абонированных характеристик начисления платежей, если такие приняты от домашнего регистра местоположения (ДРМ, HLR). ОУПО должен включать справку по трассе, тип трассы, ИД триггера, если трасса ШУПО активирована. ОУПО должен копировать справку по трассе, тип трассы, и идентификатор ЦЭП из информации трассы, полученной от ДРМ или ЦЭП.

ШУПО создает новую сотовую ячейку в своей таблице контекста PDP и генерирует ИД начисления платежей. Новая сотовая ячейка позволяет ШУПО маршрутизировать протокольные блоки данных (ПБД, PDU) PDP между ОУПО и внешней сетью PDP и начинать начисление платежей. ШУПО может дополнительно ограничивать согласованные КО в соответствии со своими возможностями и текущей нагрузкой. Затем ШУПО возвращает на ОУПО сообщение ответа по созданию контекста PDP (ИДКТ, адрес PDP, опции конфигурации PDP, согласованное КО, ИД начисления платежей, причина). Адрес PDP включают, если ШУПО выделил адрес PDP. Если ШУПО был настроен оператором на использование выделения адреса внешней сети передачи пакетных данных (СПД, PDN) для запрошенного ИТД, то адрес PDP должен быть установлен равным 0.0.0.0, что указывает, что МС должна согласовать адрес PDP с внешней СПД по завершении процедуры активации контекста PDP. ШУПО должен транслировать, модифицировать и контролировать эти согласования, пока контекст PDP находится в состоянии АКТИВНОЕ, и использовать процедуру модификации контекста PDP, инициированную ШУПО, для переноса используемого в данный момент адреса PDP на ОУПО и МС. Опции конфигурации PDP содержат необязательные параметры PDP, которые ШУПО может переносить в МС. МС может запрашивать эти необязательные параметры PDP в сообщении запроса активации контекста PDP, или ОУПО может посылать их по собственной инициативе. Опции конфигурации PDP передаются прозрачно через ОУПО. Сообщения создания контекста PDP передаются по магистральной сети.

Если согласованное КО, полученное от ОУПО, несовместимо с активируемым контекстом PDP, то ШУПО отклоняет сообщение запроса на создание контекста PDP. Совместимые профили КО конфигурируются оператором ШУПО.

7) ОУПО вводит ИТДСС совместно с адресом ШУПО в контекст PDP. Если МС запросила динамический адрес, то в контекст PDP вводится адрес PDP, полученный от ШУПО. ОУПО выбирает уровень приоритета доступа к радиоканалу и ИД потока пакетов на основании согласованного КО и возвращает в МС сообщение согласия на активацию контекста PDP (тип PDP, адрес PDP, ИТ, согласованное КО, уровень приоритета доступа к радиоканалу, ИД потока пакетов, опции конфигурации PDP). Теперь ОУПО может маршрутизировать ПБД PDP между ШУПО и МС и начать начисление платежей.

Аналогично, на фиг.2, исключительно в иллюстративных целях, показана процедура активации контекста PDP, что соответствует фиг.64 вышеупомянутого технического описания. Там также содержится нижеследующее описание этапов, указанных на фиг.2.

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

Процедуру активации вторичного контекста PDP можно выполнять, не включая шаблон потока трафика (ШПТ) во вновь активированный контекст PDP, если все остальные активные контексты PDP для этого адреса PDP и ИТД уже содержат ШПТ, в противном случае, ШПТ следует включать. ШПТ содержит атрибуты, которые задают фильтр заголовка IP, который используется, чтобы направлять пакеты данных, полученные от подключенной внешней сети передачи пакетных данных, во вновь активированный контекст PDP.

1) МС посылает в ОУПО сообщение запроса на активацию вторичного контекста PDP (присоединенный ИТ, ИТДСС, ИТ, запрашиваемое КО, ШПТ). Присоединенный ИТ содержит значение ИТ, присвоенное любому из уже активированных контекстов PDP для этого адреса PDP и ИТД. Запрашиваемое КО указывает нужный профиль КО. ШПТ передают прозрачно через ОУПО в ШУПО, чтобы разрешить классификацию пакетов для переноса данных нисходящей линии связи. ИТ и ИТДСС содержат значения, не используемые никаким другим активированным контекстом PDP.

3) В УНСМ, установление ОНКРД осуществляется посредством процедуры назначения ОНКРД.

4) ОУПО подтверждает запрос активации вторичного контекста PDP с использованием ИТ, указанного присоединенным ИТ. ОУПО использует один и тот же адрес ШУПО для уже активированного(ых) контекста(ов) PDP для этих ИТ и адреса PDP.

ОУПО и ШУПО могут ограничивать и согласовывать запрашиваемое КО согласно указанному в подпункте "Процедура активации контекста PDP". ОУПО посылает в используемый ШУПО сообщение запроса на создание контекста PDP (согласованное КО, ИДКТ, ИТДСС, первичный ИТДСС, ШПТ). Первичный ИТДСС указывает значение ИТДСС, присвоенное любому из уже активированных контекстов PDP для этих адреса PDP и ИТД. ШПТ входит, только если он получен в сообщении запроса активации вторичного контекста PDP. ШУПО использует ту же внешнюю сеть, которая используется уже активированным(и) контекстом(ами) для этого адреса PDP, генерирует новую сотовую ячейку в своей таблице контекстов PDP и сохраняет ШПТ. Новая сотовая ячейка позволяет ШУПО маршрутизировать ПБД PDP через разные туннели GTP [протокол туннелирования GPRS] между ОУПО и внешней сетью PDP. ШУПО возвращает в ОУПО сообщение ответа по созданию контекста PDP (ИДКТ, согласованное КО, причина).

6) ОУПО выбирает уровень приоритета доступа к радиоканалу и ИД потока пакетов на основании согласованного КО и возвращает на МС сообщение согласия на активацию вторичного контекста PDP (ИТ, согласованное КО, уровень приоритета доступа к радиоканалу, ИД потока пакетов). Теперь ОУПО может маршрутизировать ПБД PDP между ШУПО и МС через разные туннели GTP и, возможно, разные соединения LLC [уровня управления логическим соединением].

На фиг.3, исключительно в иллюстративных целях, показана процедура модификации контекста PDP, инициированная ОУПО, что соответствует фиг.68 вышеупомянутого технического описания. Там также содержится нижеследующее описание этапов, указанных на фиг.3.

МС и ШУПО могут делать запрос, и ОУПО может принимать решение, возможно, по условию, заданному ДРМ, как объясняется в подпункте "Процедура ввода абонентских данных", или по условию процедуры освобождения ОНКРД, инициированной контроллером радиосети (КРС, RNC), или МС и ОУПО могут принимать решение после освобождения Iu [интерфейс между КРС и базовой сетью], инициированного КРС, по модификации параметров, которые были согласованы в процедуре активации для одного или нескольких контекстов PDP. Можно модифицировать следующие параметры:

- согласованное КО;

- уровень приоритета доступа к радиоканалу;

- ИД потока пакетов;

- адрес PDP (когда процедура модификации инициирована ШУПО); и

- ШПТ (когда процедура модификации инициирована МС).

ОУПО может запрашивать модификацию параметров, посылая в МС сообщение запроса на модификацию контекста PDP.

ШУПО может запрашивать модификацию параметров, посылая в ОУПО сообщение запроса на модификацию контекста PDP.

МС может запрашивать модификацию параметров, посылая в ОУПО сообщение запроса на модификацию контекста PDP.

КРС может запрашивать освобождение Iu, посылая в ОУПО сообщение запроса на освобождение Iu. После освобождения Iu, МС и ОУПО должны модифицировать контексты PDP согласно правилам, указанным в подпункте "Процедура модификации контекста PDP, инициированная КРС".

КРС может запрашивать освобождение однонаправленного канала радиодоступа. После освобождения ОНКРД, МС и ОУПО должны локально модифицировать соответствующий контекст PDP согласно правилам, указанным в подпункте "Процедура локальной модификации контекста, инициированная освобождением ОНКРД".

Трассу можно активировать, когда контекст PDP активен. Чтобы разрешить активацию трассы в ШУПО, ОУПО должен послать в ШУПО сообщение запроса на обновление контекста PDP. Если модификация контекста PDP осуществляется только для активации трассы, то ОУПО не должен посылать в МС сообщение запроса на модификацию контекста PDP.

1) ОУПО может посылать в ШУПО сообщение запроса на обновление контекста PDP (ИДКТ, ИТДСС, согласованное КО, справка по трассе, тип трассы, ИД триггера, идентификатор ЦЭП). Если согласованное КО, полученное от ОУПО, несовместимо с модифицируемым контекстом PDP, то ШУПО отклоняет запрос на обновление контекста PDP. Совместимые профили КО конфигурируются оператором ШУПО. ОУПО должен включать в сообщение справку по трассе, тип трассы, ИД триггера и идентификатор ЦЭП, если трасса ШУПО активирована, когда контекст PDP активен. ОУПО должен копировать справку по трассе, тип трассы и идентификатор ЦЭП из информации трассы, полученной от ДРМ или ЦЭП.

2) ШУПО может ограничивать согласованное КО в соответствии со своими возможностями и текущей нагрузкой. ШУПО сохраняет согласованное КО и возвращает сообщение ответа по обновлению контекста PDP (ИДКТ, согласованное КО, причина).

3) ОУПО выбирает уровень приоритета доступа к радиоканалу и ИД потока пакетов на основании согласованного КО и может посылать в МС сообщение запроса на модификацию контекста PDP (ИТ, согласованное КО, уровень приоритета доступа к радиоканалу, ИД потока пакетов).

4) МС осуществляет подтверждение приема (положительное квитирование), возвращая сообщение согласия на модификацию контекста PDP. Если же МС не принимает новое согласованное КО, то она должна деактивировать контекст PDP посредством процедуры деактивации контекста PDP, инициированной МС.

5) В УНСМ, модификация однонаправленного канала радиодоступа может осуществляться посредством процедуры назначения ОНКРД.

6) Если трасса СБС (системы базовых станций) активируется, когда контекст PDP активен, то ОУПО должен посылать сообщение активации трассы (справка по трассе, тип трассы, ИД триггера, идентификатор ЦЭП). Справка по трассе и тип трассы копируются из информации трассы, полученной от ДРМ или ЦЭП.

1) ОУПО может посылать в ШУПО сообщение запроса на обновление контекста PDP (ИДКТ, ИТДСС, согласованное КО, справка по трассе, тип трассы, ИД триггера, идентификатор ЦЭП). Если согласованное КО, полученное от ОУПО, несовместимо с модифицируемым контекстом PDP, то ШУПО отклоняет запрос на обновление контекста PDP. Совместимые профили КО конфигурируются оператором ШУПО. ОУПО должен включать в сообщение справку по трассе, тип трассы, ИД триггера и идентификатор ЦЭП, если трасса ШУПО активирована, когда контекст PDP активен. ОУПО должен копировать справку по трассе, тип трассы и идентификатор ЦЭП из информации трассы, полученной от ДРМ или ЦЭП.

2) ШУПО может ограничивать согласованное КО в соответствии со своими возможностями и текущей нагрузкой. ШУПО сохраняет согласованное КО и возвращает сообщение ответа по обновлению контекста PDP (ИДКТ, согласованное КО, причина).

3) ОУПО выбирает уровень приоритета доступа к радиоканалу и ИД потока пакетов на основании согласованного КО и может посылать в МС сообщение запроса на модификацию контекста PDP (ИТ, согласованное КО, уровень приоритета доступа к радиоканалу, ИД потока пакетов).

4) МС осуществляет подтверждение приема (положительное квитирование), возвращая сообщение согласия на модификацию контекста PDP. Если же МС не принимает новое согласованное КО, то она должна деактивировать контекст PDP посредством процедуры деактивации контекста PDP, инициированной МС.

5) В УНСМ модификация однонаправленного канала радиодоступа может осуществляться посредством процедуры назначения ОНКРД.

6) Если трасса СБС (системы базовых станций) активируется, когда контекст PDP активен, то ОУПО должен посылать сообщение активации трассы (справка по трассе, тип трассы, ИД триггера, идентификатор ЦЭП). Справка по трассе и тип трассы копируются из информации трассы, полученной от ДРМ или ЦЭП.

На фиг.4, также исключительно в иллюстративных целях, показана процедура модификации контекста PDP, инициированная ШУПО, что соответствует фиг.69 вышеупомянутого технического описания. Там также содержится нижеследующее описание этапов, указанных на фиг.4.

1) ШУПО посылает в ОУПО сообщение обновления контекста PDP (ИДКТ, ИТДСС, адрес PDP, запрашиваемое КО). Запрашиваемое КО указывает нужный профиль КО. Адрес PDP является необязательным.

2) ОУПО может ограничивать нужный профиль КО в соответствии со своими возможностями, текущей нагрузкой, текущим профилем КО и абонированным профилем КО. ОУПО выбирает уровень приоритета доступа к радиоканалу и ИД потока пакетов на основании согласованного КО и посылает в МС сообщение запроса на модификацию контекста PDP (ИТ, адрес PDP, согласованное КО, уровень приоритета доступа к радиоканалу, ИД потока пакетов).

3) МС осуществляет подтверждение приема (положительное квитирование), возвращая сообщение согласия на модификацию контекста PDP. Если же МС не принимает новое согласованное КО, то она должна деактивировать контекст PDP посредством процедуры деактивации контекста PDP, инициированной МС.

4) В УНСМ модификация однонаправленного канала радиодоступа может осуществляться посредством процедуры назначения ОНКРД.

5) По приему сообщения согласия на модификацию контекста PDP или по завершении процедуры модификации ОНКРД, ОУПО возвращает в ШУПО сообщение ответа по обновлению контекста PDP (ИДКТ, согласованное КО). Если же ОУПО принимает сообщение запроса на деактивацию контекста PDP, то он должен следовать процедуре деактивации контекста PDP, инициированной МС.

На фиг.5, также исключительно в иллюстративных целях, показана процедура модификации контекста PDP, инициированная МС, что соответствует фиг.70 вышеупомянутого технического описания. Там также содержится нижеследующее описание этапов, указанных на фиг.5.

1) МС посылает в ОУПО сообщение запроса на модификацию контекста PDP (ИТ, запрашиваемое КО, ШПТ). В сообщение может входить запрашиваемое КО или ШПТ или оба параметра. Запрашиваемое КО указывает нужный профиль КО, а ШПТ указывает ШПТ, который нужно добавить или модифицировать или исключить из контекста PDP.

2) ОУПО может ограничивать нужный профиль КО в соответствии со своими возможностями, текущей нагрузкой, текущим профилем КО и абонированным профилем КО. ОУПО посылает в ШУПО сообщение запроса на обновление контекста PDP (ИДКТ, ИТДСС, согласованное КО, ШПТ). Если согласованное КО и/или ШПТ, полученные от ОУПО, несовместимы с модифицируемым контекстом PDP (например, ШПТ содержит несоответствующие фильтры пакетов), то ШУПО отклоняет запрос на обновление контекста PDP. Совместимые профили КО конфигурируются оператором ШУПО.

3) ШУПО также может ограничивать согласованное КО в соответствии со своими возможностями и текущей нагрузкой. ШУПО сохраняет согласованное КО, сохраняет, модифицирует или удаляет ШПТ того контекста PDP, который указан в ШПТ, и возвращает сообщение ответа по обновлению контекста PDP (ИДКТ, согласованное КО).

4) В УНСМ, модификация однонаправленного канала радиодоступа может осуществляться посредством процедуры назначения ОНКРД.

5) ОУПО выбирает уровень приоритета доступа к радиоканалу и ИД потока пакетов на основании согласованного КО и возвращает в МС сообщение согласия на модификацию контекста PDP (ИТ, согласованное КО, уровень приоритета доступа к радиоканалу, ИД потока пакетов).

Примечание: если ОУПО не принимает запрашиваемое КО, то этапы 2 и 3 этой процедуры пропускают, и на этапе 4 в МС возвращают существующее согласованное КО.

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

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

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

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

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

Согласно способу, отвечающему настоящему изобретению, для вызова с мобильного телефона, на который нужно ответить уведомлением, МС сообщают адрес транспортного уровня узла, который будет воспроизводить уведомление, после чего МС инициирует процедуру модификации контекста PDP, чтобы установить шаблон потока трафика (ШПТ) согласно адресу транспортного уровня (ТА) узла.

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

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

Ниже приведено краткое описание чертежей, на которых:

фиг.1 иллюстрирует этапы процедуры активации контекста PDP,

фиг.2 иллюстрирует этапы процедуры активации вторичного контекста PDP,

фиг.3-5 иллюстрируют этапы, соответственно, процедуры модификации контекста PDP, инициированной ОУПО, инициированной ШУПО и инициированной МС,

фиг.6 и 7 также подробно иллюстрируют этапы процедуры установления вызова,

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

Предпочтительные варианты осуществления изобретения

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

В дополнение к вышеупомянутому техническому описанию, техническое описание TS 23.228, версия V1.5.0, задает описание услуги стадии 2 для подсистемы IP-мультимедиа (IM), которая включает в себя элементы, необходимые для поддержки услуг IP-мультимедиа (IM) в УНСМ. Это техническое описание полностью включено в настоящее описание посредством ссылки, и, как и в случае ранее упомянутого технического описания, элементы и их функции, включенные сюда посредством ссылки, являются всего лишь неограничительным примером сетей беспроводной связи с коммутацией пакетов, и настоящее изобретение не следует рассматривать как ограниченное ими.

На фиг.6, которая соответствует фиг.5.7 технического описания TS 23.228, подробно показаны следующие этапы процедуры установления вызова.

1. Пользовательское оборудование ПО(А) начинает процедуру инициирования сеанса с ПО(В), которая включает в себя предложение SDP [протокола описания сеанса].

2. Пользователь на ПО(В) предварительно оповещается. (необязательный)

3. Указатель предварительного оповещения можно посылать в ПО(А). (необязательный)

4. Пользователь на ПО(В) будет взаимодействовать и выражать свои пожелания относительно текущего сеанса. (необязательный)

5. ПО(В) генерирует принятый SDP на основании настроек терминала, переконфигурированных профилей терминала и, в необязательном порядке, пожеланий пользователя.

6. Принятый SDP пересылают в ПО(А) в полезной нагрузке достоверного ответа SIP [протокола инициирования сеанса].

7. Осуществляют процедуру создания исходного однонаправленного канала. На этапе создания этого однонаправленного канала, ресурсы сети доступа ПО(А) и ПО(В) резервируются посредством процедур контекста PDP. При этом можно также резервировать ресурсы однонаправленного канала во внешних сетях.

8. Терминал в ПО(В) начинает звонить. (необязательный)

9. Указатель оповещения посылают в ПО(А). (необязательный)

10. Пользователь на ПО(В) может взаимодействовать и выражать свои пожелания относительно текущего сеанса. (необязательный)

11. При этом ПО(А) и ПО(В) могут осуществлять процедуру модификации однонаправленного канала, если исходные однонаправленные каналы, зарезервированные на этапе 7, и пожелания пользователя на ПО(В) отличаются друг от друга. На этом этапе модификации однонаправленного канала ресурсы сети доступа ПО(А) и ПО(В) можно модифицировать путем модификации контекста PDP, а также можно модифицировать резервирование ресурсов во внешней сети.

12. Осуществляют подтверждение (положительное квитирование) процедуры инициирования сеанса.

Кроме того, на фиг.7 показаны этапы процедуры установления вызова, что соответствует фиг.5.15 раздела 5.6.2 второго упомянутого технического описания. Здесь также описаны следующие этапы.

1. ПО1 посылает запрос ПРИГЛАШЕНИЕ SIP, содержащий исходный SDP, на П-ФУСВ, определенный посредством механизма обнаружения ФУСВ. Исходный SDP может представлять одну или несколько сред для мультимедийного сеанса.

2. П-ФУСВ вспоминает (из процедуры регистрации) следующий хоп ФУСВ для этого ПО. В этом случае он пересылает ПРИГЛАШЕНИЕ на О-ФУСВ в домашней сети.

3. О-ФУСВ подтверждает профиль услуги и осуществляет любое управление услугами вызывающей стороны, необходимое для этого абонента. Это включает в себя авторизацию запрашиваемого SDP на основании абонирования пользователем мультимедийных услуг.

4. О-ФУСВ пересылает запрос в соответствии с процедурами S-S.

5. Возможности медийного потока вызываемой стороны возвращаются по пути сигнализации посредством процедур S-S.

6. О-ФУСВ пересылает сообщение SDP на П-ФУСВ.

7. П-ФУСВ авторизует ресурсы, необходимые для данного сеанса.

8. П-ФУСВ пересылает сообщение SDP в конечную точку (пункт) вызывающей стороны.

9. ПО принимает решение о конечном наборе медийных потоков для этого сеанса и посылает на П-ФУСВ конечный SDP.

10. П-ФУСВ пересылает это сообщение на О-ФУСВ.

11. О-ФУСВ пересылает это сообщение в конечную точку (пункт) вызываемой стороны посредством процедуры S-S.

12. Определив конечные медийные потоки на этапе 9, ПО инициирует процедуры резервирования ресурсов, необходимых для данного сеанса.

13. По завершении резервирования ресурсов, ПО посылает сообщение "Успешное резервирование ресурсов" в конечную точку (пункт) вызываемой стороны, по пути сигнализации, установленному сообщением ПРИГЛАШЕНИЕ. Сообщение направляется сначала на П-ФУСВ.

14. П-ФУСВ пересылает это сообщение на О-ФУСВ.

15. О-ФУСВ пересылает это сообщение на конечную точку (пункт) вызываемой стороны по процедуре S-S.

16. Вызываемое ПО может, в необязательном порядке, осуществлять оповещение. Если так, то оно сигнализирует об этом вызывающей стороне посредством условного ответа, обозначающего звонок. Это сообщение посылают на О-ФУСВ посредством процедуры S-S.

17. О-ФУСВ пересылает это сообщение на П-ФУСВ.

18. П-ФУСВ пересылает сообщение звонка в ПО.

19. ПО указывает вызывающему абоненту, что на вызываемой стороне раздается звонок.

20. При ответе вызываемой стороны, конечная точка (пункт) вызываемой стороны посылает конечный ответ SIP 200-ОК, который задан процедурами вызываемой стороны и процедурами S-S, на О-ФУСВ.

21. О-ФУСВ осуществляет любое управление услугами вызывающей стороны, необходимое для выполнения установления сеансом.

22. О-ФУСВ передает ответ 200-ОК обратно на П-ФУСВ по пути запроса ПРИГЛАШЕНИЕ вышеозначенного этапа (2).

23. П-ФУСВ указывает, какие ресурсы, зарезервированные для этого сеанса, нужно использовать.

24. П-ФУСВ передает ответ 200-ОК обратно в ПО.

25. ПО начинает медийный(е) поток(и) для этого сеанса.

26. ПО отвечает на 200 ОК посредством сообщения подтверждение приема (ПДТ, ACK), которое направляется на П-ФУСВ.

27. П-ФУСВ пересылает конечное сообщение подтверждение приема (ACK) на О-ФУСВ.

28. О-ФУСВ пересылает конечное сообщение подтверждение приема (ACK) на конечную точку (пункт) вызываемой стороны, посредством процедуры S-S. Однако МС часто бывает нужно принимать записанное уведомление от вызывающей стороны, а не соединение с вызывающей стороной для осуществления разговора. В этих условиях, записанное уведомление выводится из узла по адресу, отличному от адреса вызывающей стороны, и способ, отвечающий изобретению, позволяет облегчить инициирование процедуры модификации контекста PDP для задания шаблона потока трафика (ШПТ) в соответствии с адресом транспортного уровня (ТА) узла.

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

Это сообщение установления перехватывается сетью, которая проинструктирована пересылать, в ответ на установление вызова, сообщение уведомления вызываемой стороне. Устройство, которое будет воспроизводить (считывать) уведомление, обозначенное на чертеже как Удаленная ФУСВ/ПОВТ, на этапе 2 подтверждает прием сообщения установления посредством сообщения соединения, содержащего IP-адрес и номер порта, т.е. ТА удаленного оборудования, что позволяет МС правильно соединяться с ним.

Затем на этапах 3, 4, 5, 6 и 7, МС активирует вторичный контекст PDP, который содержит ШПТ, позволяющий устройству посылать трафик в МС. Таким образом, ШПТ содержит ТА удаленного оборудования (т.е. IP-адрес и номер порта).

На этапе 8 МС подтверждает прием вторичного контекста PDP, и, на этапе 9, удаленное оборудование воспроизводит уведомление для МС.

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

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

Изобретение относится к сетям мобильной связи, в частности к обеспечению уведомлений для вызовов с мобильных телефонов в сети мобильной связи с использованием транспортного механизма Интернет-протокола. Технический результат - обеспечение контроля перемещения мобильной станции. Способ обеспечения уведомления в сети связи предусматривает установление сеанса связи первого уровня на первом элементе сети. Затем определяют, что уведомление следует считывать для первого элемента сети. Посылают идентификатор второго элемента сети, который должен считывать уведомление в течение первого сеанса связи, и, после установления сеанса связи второго уровня, параметры канала связи второго уровня модифицируют в соответствии с переданным идентификатором. Затем второй элемент сети считывает уведомление для первого элемента сети. Переданный идентификатор может содержать IP-адрес или номер порта или ТА (адрес транспортного уровня). Сеанс связи может содержать контекст PDP (протокола передачи пакетных данных). Первый элемент сети может содержать мобильную станцию. 2 н. и 24 з.п. ф-лы, 8 ил.

1. Способ обеспечения уведомления в сети связи, заключающийся в том, что устанавливают сеанс связи первого уровня для первого элемента сети, определяют, что уведомление нужно воспроизводить для первого элемента сети, посылают идентификатор второго элемента сети, который должен воспроизводить уведомление в течение сеанса связи первого уровня, устанавливают сеанс связи второго уровня, задают параметры сеанса связи второго уровня в соответствии с переданным идентификатором и воспроизводят уведомление для первого элемента сети.2. Способ по п.1, отличающийся тем, что переданный идентификатор содержит IP-адрес (Интернет-протокола).3. Способ по п.1, отличающийся тем, что переданный идентификатор содержит номер порта.4. Способ по п.1, отличающийся тем, что переданный идентификатор содержит ТА (адрес транспортного уровня).5. Способ по п.1, отличающийся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).6. Способ по п.2, отличающийся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).7. Способ по п.3, отличающийся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).8. Способ по п.4, отличающийся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).9. Способ по п.1, отличающийся тем, что первый элемент сети содержит МС (мобильную станцию).10. Способ по п.1, отличающийся тем, что упомянутый сеанс связи содержит, по меньшей мере, один контекст PDP.11. Способ по п.1, отличающийся тем, что упомянутые параметры содержат информацию фильтрации.12. Способ по п.11, отличающийся тем, что информация фильтрации содержит шаблон потока графика (ШПТ).13. Способ по п.1, отличающийся тем, что упомянутые параметры канала связи задают, включая ТА (адрес транспортного уровня) в ШПТ (шаблон потока графика).14. Устройство хранения программ, считываемое машиной, реально воплощающее программу из команд, выполняемых на машине для осуществления способа обеспечения уведомления в сети связи, содержащее средство для установления сеанса связи первого уровня для первого элемента сети, средство для определения того, что уведомление нужно воспроизводить для первого элемента сети, средство для посылки идентификатора второго элемента сети, который должен воспроизводить уведомление в течение сеанса связи первого уровня, средство для установления сеанса связи второго уровня, средство для задания параметров сеанса связи второго уровня в соответствии с переданным идентификатором и средство для воспроизведения уведомления для первого элемента сети.15. Устройство по п.14, отличающееся тем, что переданный идентификатор содержит IP-адрес (Интернет-протокола).16. Устройство по п.14, отличающееся тем, что переданный идентификатор содержит номер порта.17. Устройство по п.14, отличающееся тем, что переданный идентификатор содержит ТА (адрес транспортного уровня).18. Устройство по п.14, отличающееся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).19. Устройство по п.15, отличающееся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).20. Устройство по п.16, отличающееся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).21. Устройство по п.17, отличающееся тем, что упомянутый сеанс связи содержит контекст PDP (протокола передачи пакетных данных).22. Устройство по п.14, отличающееся тем, что первый элемент сети содержит МС (мобильную станцию).23. Устройство по п.14, отличающееся, тем, что упомянутый сеанс связи содержит, по меньшей мере, один контекст PDP.24. Устройство по п.14, отличающееся тем, что упомянутые параметры сеанса связи заданы посредством включения ТА (адрес транспортного уровня) в ШПТ (шаблон потока трафика).25. Устройство по п.14, отличающееся тем, что упомянутые параметры содержат информацию фильтрации.26. Устройство по п.25, отличающееся тем, что информация фильтрации содержит шаблон потока трафика (ШПТ).