RU2282312C2 - Способ обеспечения уведомлений в вызовах с мобильных телефонов - Google Patents

Способ обеспечения уведомлений в вызовах с мобильных телефонов Download PDF

Info

Publication number
RU2282312C2
RU2282312C2 RU2003132473/09A RU2003132473A RU2282312C2 RU 2282312 C2 RU2282312 C2 RU 2282312C2 RU 2003132473/09 A RU2003132473/09 A RU 2003132473/09A RU 2003132473 A RU2003132473 A RU 2003132473A RU 2282312 C2 RU2282312 C2 RU 2282312C2
Authority
RU
Russia
Prior art keywords
pdp
communication session
context
address
network
Prior art date
Application number
RU2003132473/09A
Other languages
English (en)
Other versions
RU2003132473A (ru
Inventor
Туй ХУРТТА (FI)
Туйя ХУРТТА
Стефано ФАЧЧИН (US)
Стефано ФАЧЧИН
Недко ИВАНОВ (HU)
Недко ИВАНОВ
Бертениль БАЛАЖ (HU)
Бертениль БАЛАЖ
Original Assignee
Нокиа Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нокиа Корпорейшн filed Critical Нокиа Корпорейшн
Publication of RU2003132473A publication Critical patent/RU2003132473A/ru
Application granted granted Critical
Publication of RU2282312C2 publication Critical patent/RU2282312C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Medicines Containing Plant Substances (AREA)

Abstract

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

Description

Уровень техники
Настоящее изобретение относится к сетям мобильной связи, и, в частности, настоящее изобретение относится к способу обеспечения уведомлений для вызовов с мобильных телефонов в сети мобильной связи с использованием транспортного механизма 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 с помощью ШПТ удаленного оборудования, чтобы устройство удаленного оборудования могло переслать в МС свое уведомление.
Итак, мы рассмотрели иллюстративные варианты осуществления. Хотя настоящее изобретение было описано со ссылкой на иллюстративные варианты его осуществления, следует понимать, что специалисты в данной области техники могут предложить различные другие модификации и варианты осуществления, не выходя за рамки сущности и объема принципов данного изобретения. В частности, возможны разумные вариации и модификации, касающиеся составных частей и/или конфигураций рассматриваемой объединенной комбинации в пределах вышеизложенного раскрытия, чертежей и прилагаемой формулы изобретения, не нарушающие сущности изобретения. Помимо вариаций и модификаций составных частей и/или конфигураций, специалистам в данной области техники будут очевидны альтернативные варианты осуществления.

Claims (26)

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, отличающееся тем, что информация фильтрации содержит шаблон потока трафика (ШПТ).
RU2003132473/09A 2001-04-09 2002-04-09 Способ обеспечения уведомлений в вызовах с мобильных телефонов RU2282312C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/827,917 2001-04-09
US09/827,917 US7054945B2 (en) 2001-04-09 2001-04-09 Technique for providing announcements in mobile-originated calls

Publications (2)

Publication Number Publication Date
RU2003132473A RU2003132473A (ru) 2005-05-27
RU2282312C2 true RU2282312C2 (ru) 2006-08-20

Family

ID=25250475

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2003132473/09A RU2282312C2 (ru) 2001-04-09 2002-04-09 Способ обеспечения уведомлений в вызовах с мобильных телефонов

Country Status (15)

Country Link
US (1) US7054945B2 (ru)
EP (1) EP1397750B1 (ru)
JP (1) JP3901095B2 (ru)
KR (1) KR100879811B1 (ru)
CN (1) CN1278250C (ru)
AT (1) ATE387669T1 (ru)
AU (1) AU2002246300B2 (ru)
BR (1) BR0208709A (ru)
CA (1) CA2443690A1 (ru)
DE (1) DE60225278T2 (ru)
ES (1) ES2302799T3 (ru)
MX (1) MXPA03009181A (ru)
RU (1) RU2282312C2 (ru)
WO (1) WO2002082781A2 (ru)
ZA (1) ZA200307615B (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2470483C2 (ru) * 2007-04-24 2012-12-20 Телефонактиеболагет Лм Эрикссон (Пабл) Способ и система, позволяющие избежать зависания pdp контекста

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8295269B1 (en) 2000-04-10 2012-10-23 Nokia Corporation Technique for informing network of voice traffic
SE0002572D0 (sv) * 2000-07-07 2000-07-07 Ericsson Telefon Ab L M Communication system
US7249170B2 (en) * 2000-12-06 2007-07-24 Intelliden System and method for configuration, management and monitoring of network resources
EP1250023A1 (en) * 2001-04-11 2002-10-16 Alcatel Provision of subscriber QoS guarantees to roaming subscribers
DE10120772A1 (de) * 2001-04-24 2002-11-07 Siemens Ag Heterogenes Mobilfunksystem
US20040255039A1 (en) * 2001-05-10 2004-12-16 Bernard Honeisen Method, system and network element device for controlling sessions between terminals
KR100624803B1 (ko) * 2001-05-28 2006-09-19 노키아 코포레이션 2개 이상의 네트워크 요소들이 1개의 요소에 통합될 때의최적의 라우팅
US20030003894A1 (en) * 2001-06-27 2003-01-02 Kumar Anil K. Developing mobile unit based estimates of metered packet charges
KR100389819B1 (ko) * 2001-07-09 2003-07-02 삼성전자주식회사 부호분할다중접속 이동통신시스템에서 패킷 데이터 전송방법
US20030039259A1 (en) * 2001-07-10 2003-02-27 Lila Madour Traffic flow template for managing packet data flows
WO2003039080A1 (en) * 2001-10-31 2003-05-08 Nokia Corporation A method for handling of messages between a terminal and a data network
FI20012561A (fi) * 2001-12-21 2003-06-22 Nokia Corp Loogisen yhteyden modifiointi
KR100438430B1 (ko) 2002-01-24 2004-07-03 삼성전자주식회사 이동통신시스템에서 트래픽 플로우 탬플릿 재정렬 장치 및방법
NO20020667D0 (no) * 2002-02-11 2002-02-11 Ericsson Telefon Ab L M Fremgangsmåte for å unngå unödig okkupering av ressurser i pakkesvitsjede mobilnett
US7792973B2 (en) * 2002-03-12 2010-09-07 Verizon Business Global Llc Systems and methods for initiating announcements in a SIP telecommunications network
GB2387069A (en) * 2002-03-27 2003-10-01 Ericsson Telefon Ab L M Indicating different charging regimes for user and signalling data in a communications network
EP1495593B1 (en) * 2002-04-10 2006-06-21 Telefonaktiebolaget LM Ericsson (publ) Data preservation
KR101009819B1 (ko) * 2002-06-06 2011-01-19 톰슨 라이센싱 Ｗｌａｎ과 이동 통신 시스템 간의 상호 연동시하이브리드 결합을 위한 논리 지원 노드인 ｗｌａｎ
US20040028080A1 (en) * 2002-08-06 2004-02-12 Harish Samarasinghe Method of defining a SIP message body for communications between core network elements
US7254643B1 (en) 2002-08-08 2007-08-07 At&T Corp. System and method for providing multi-media services to communication devices over a communications network
US7330448B2 (en) * 2002-08-21 2008-02-12 Thomson Licensing Technique for managing quality of services levels when interworking a wireless local area network with a wireless telephony network
US20040037264A1 (en) * 2002-08-23 2004-02-26 Charbel Khawand Pre-negotiated quality of service
ES2297798T3 (es) * 2002-09-24 2008-05-01 Orange Sa Metodo para una pasarela de seleccion de un canal para transferir paquetes de datos.
KR100554799B1 (ko) 2002-11-19 2006-02-22 엘지전자 주식회사 Ｇｓｍ이동통신 시스템의 전송 데이타 암호화 및 암호화 해제 방법
GB2396444A (en) * 2002-12-18 2004-06-23 Nokia Corp A Method of Announcing Sessions
US7180912B1 (en) 2003-01-06 2007-02-20 At&T Corp. System and method for providing a plurality of multi-media services using a number of media servers to form a preliminary interactive communication relationship with a calling communication device
JP4164379B2 (ja) * 2003-02-06 2008-10-15 キヤノン株式会社 検査方法
US7508923B1 (en) 2003-02-27 2009-03-24 At&T Corp. Call control element constructing a session initiation protocol (SIP) message including provisions for incorporating address related information of public switched telephone network (PSTN) based devices
US7701915B2 (en) * 2003-06-27 2010-04-20 Nokia Corporation Method in a communication system, a communication system and a communication device
US7327746B1 (en) * 2003-08-08 2008-02-05 Cisco Technology, Inc. System and method for detecting and directing traffic in a network environment
US20050041631A1 (en) * 2003-08-20 2005-02-24 Naveen Aerrabotu Apparatus and method for primary link packet control
GB2405557A (en) * 2003-08-27 2005-03-02 Nokia Corp Service identification data relating services at a given frequency to services and identifying their media format
US7283506B2 (en) * 2003-10-13 2007-10-16 Nokia Corporation System and method for releasing sessions at network entities associated with the sessions
GB0324596D0 (en) * 2003-10-21 2003-11-26 Nokia Corp Sessions in a communication system
US7864693B2 (en) 2003-12-05 2011-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for establishing a communication session between two terminals
GB2417650A (en) 2004-07-30 2006-03-01 Orange Personal Comm Serv Ltd Tunnelling IPv6 packets over IPv4 packet radio network wherein an IPv6 address including a tunnel end identifier of the IPv4 bearer is formed
US7620057B1 (en) * 2004-10-19 2009-11-17 Broadcom Corporation Cache line replacement with zero latency
US8139739B2 (en) * 2005-05-06 2012-03-20 At&T Mobility Ii Llc Enhanced alerting system
JP4685938B2 (ja) * 2005-08-22 2011-05-18 テレフオンアクチーボラゲット エル エム エリクソン（パブル） マルチメディア用通信セッションの確立方法及び装置
WO2007029593A1 (ja) * 2005-09-07 2007-03-15 Matsushita Electric Industrial Co., Ltd. 携帯電話装置およびその制御方法
US20070258427A1 (en) * 2006-05-03 2007-11-08 Interdigital Technology Corporation Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures
SG171641A1 (en) * 2006-05-03 2011-06-29 Interdigital Tech Corp Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures
CN101128041B (zh) 2006-08-15 2010-05-12 华为技术有限公司 接入网和核心网间下行数据隧道失效后的处理方法和系统
US8239241B2 (en) * 2006-08-29 2012-08-07 International Business Machines Corporation Method and apparatus for providing information about anticipated delays to customers at service centers, contact centers, or call centers
US7684387B2 (en) * 2006-10-06 2010-03-23 Motorola, Inc. Method for routing combinational services to a single endpoint
CN101094152B (zh) * 2006-11-07 2010-08-18 中兴通讯股份有限公司 一种分组域单隧道无线网络控制器错误的处理方法
US8959239B2 (en) * 2006-12-29 2015-02-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for reporting streaming media quality
US20080235185A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication system and method of accessing therefor
US20080235778A1 (en) * 2007-03-21 2008-09-25 Motorola, Inc. Communication network, an access network element and a method of operation therefor
WO2009006942A1 (en) * 2007-07-10 2009-01-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods, apparatuses and computer program for ims recovery upon restart of a s-cscf
US20100202291A1 (en) * 2007-07-30 2010-08-12 Telefonaktiebolaget Lm Ericsson (Publ) Method of Selecting Media Flow
CN101808270B (zh) 2010-03-10 2016-03-30 华为终端有限公司 一种基于Android的业务处理方法和装置
KR101791533B1 (ko) * 2011-04-28 2017-10-30 삼성전자 주식회사 이동통신 시스템에서 자원 예약 방법 및 시스템
CN109195200B (zh) * 2018-08-27 2021-01-15 京信通信系统（中国）有限公司 Apn分配方法、装置、通信设备和系统
US11082536B2 (en) * 2018-10-24 2021-08-03 Jeffrey T. Schultz Mobile announcement system

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11163947A (ja) * 1997-09-22 1999-06-18 Toshiba Corp ゲートウェイ装置、無線端末装置、ルータ装置および通信ネットワークのゲートウェイ制御方法
JP3949288B2 (ja) 1997-09-22 2007-07-25 株式会社東芝 ゲートウェイ装置及び無線端末装置
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
DE19849540B4 (de) * 1998-07-06 2006-09-28 Siemens Ag Verfahren und Mobilfunknetz zur Behandlung eines Paketdatendienstes
EP1207902A2 (de) * 1999-06-17 2002-05-29 Pharmacia AB VERWENDUNG VON WACHSTUMSHORMON (hGH) ZUR THERAPIE SEXUELLER FUNKTIONSSTÖRUNGEN
US6707813B1 (en) * 2000-02-21 2004-03-16 Telefonaktiebolaget L M Ericsson (Publ) Method of call control to minimize delays in launching multimedia or voice calls in a packet-switched radio telecommunications network
US7123920B1 (en) 2000-04-10 2006-10-17 Nokia Corporation Technique for setting up calls in mobile network
US6654610B1 (en) * 2000-05-05 2003-11-25 Lucent Technologies Inc. Two-way packet data protocol methods and apparatus for a mobile telecommunication system
US6621793B2 (en) * 2000-05-22 2003-09-16 Telefonaktiebolaget Lm Ericsson (Publ) Application influenced policy
US7126939B2 (en) * 2000-07-24 2006-10-24 Nortel Networks Limited Packet-based calls in a wireless network
US6546247B1 (en) * 2000-09-08 2003-04-08 Telefonaktiebolaget L M Ericsson (Publ) Home location server and call processing method in a hybrid second/third generation radio telecommunications network
US6834044B2 (en) * 2001-02-15 2004-12-21 Telefonaktiebolaget L M Ericsson (Publ) Multi-path data streaming in a wireless packet data network

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2470483C2 (ru) * 2007-04-24 2012-12-20 Телефонактиеболагет Лм Эрикссон (Пабл) Способ и система, позволяющие избежать зависания pdp контекста

Also Published As

Publication number Publication date
EP1397750A2 (en) 2004-03-17
AU2002246300B2 (en) 2007-08-09
RU2003132473A (ru) 2005-05-27
BR0208709A (pt) 2004-07-20
WO2002082781A3 (en) 2003-12-24
ES2302799T3 (es) 2008-08-01
US7054945B2 (en) 2006-05-30
CN1502078A (zh) 2004-06-02
EP1397750A4 (en) 2005-09-14
JP3901095B2 (ja) 2007-04-04
ZA200307615B (en) 2004-06-03
DE60225278T2 (de) 2009-03-26
EP1397750B1 (en) 2008-02-27
CA2443690A1 (en) 2002-10-17
KR20030085102A (ko) 2003-11-01
ATE387669T1 (de) 2008-03-15
US20020147824A1 (en) 2002-10-10
CN1278250C (zh) 2006-10-04
JP2004534438A (ja) 2004-11-11
WO2002082781A2 (en) 2002-10-17
WO2002082781B1 (en) 2004-02-12
DE60225278D1 (de) 2008-04-10
KR100879811B1 (ko) 2009-01-22
MXPA03009181A (es) 2004-02-17

Similar Documents

Publication Publication Date Title
RU2282312C2 (ru) Способ обеспечения уведомлений в вызовах с мобильных телефонов
CA2405777C (en) A technique for setting up calls in internet protocol mobile network
JP4520690B2 (ja) カンファレンスコールをスケジューリングするための方法および装置
JP4391531B2 (ja) Ｐｄｐコンテキスト作動後に、ローミング・ユーザの呼び出しの除外を可能にする方法及び通信システム
JP4223806B2 (ja) ネットワーク要素間に接続を確立する方法及びシステム
JP4960385B2 (ja) データ伝送においてパケットフィルタを設置するための方法およびデバイス
US7525938B2 (en) Session control in a communication system
AU2002246300A1 (en) Technique for providing announcements in mobile-originated calls
JP5000764B2 (ja) 部分セッション移転方法及びこのための端末
RU2412550C2 (ru) Инициируемый сетью переход от речевой службы к мультимедийной службе
WO2002085050A1 (en) One-to-one communication, where the system having different control plane and user plane logical entities
WO2000070825A1 (en) Connection management method
US8295269B1 (en) Technique for informing network of voice traffic
JP2007195211A (ja) ネットワーク要素間に接続を確立する方法及びシステム
JP2009065683A (ja) ネットワーク要素間に接続を確立する方法及びシステム
KR20060067982A (ko) 네트워크 요소들 사이의 접속을 설정하는 방법 및 시스템

Legal Events

Date Code Title Description
RH4A Copy of patent granted that was duplicated for the russian federation

Effective date: 20080130

PC4A Invention patent assignment

Effective date: 20080304

MM4A The patent is invalid due to non-payment of fees

Effective date: 20120410