Инициируемый сетью переход от речевой службы к мультимедийной службе
Изобретение относится к системам связи. Технический результат заключается в исключении ненужного прерывания трафика. Раскрыты способ, устройство и система для инициирования изменения службы в беспроводной системе, включающей инициирующую сторону и конечную сторону. Изобретение включает инициирование запроса на модификацию в беспроводной системе, при этом запрос на модификацию относится к изменению службы с переходом из первого режима во второй режим. Кроме того, способ по изобретению включает модификацию режима терминала с переходом из первого режима во второй режим, если запрос на модификацию одобрен терминалом, и завершение назначения радиоканала после того, как запрос на модификацию будет одобрен. 3 н. и 7 з.п. ф-лы, 7 ил.
Предпосылки создания изобретения
Область техники
Настоящее изобретение относится к области радиосвязи.
Описание уровня техники
Имеются многочисленные службы связи, которые переносят различные формы и комбинации мультимедийного содержания, например видеоданные, сетевой контент, графику и текст. В контексте настоящего описания термин "мультимедийный" относится к любому содержанию, имеющему визуальный элемент. Мобильные терминалы беспроводных сетей связи, в частности телефоны сотовых сетей связи, в настоящее время способны переносить данные, включая мультимедийные данные, в рамках различных служб связи. Используется множество типов мобильных терминалов, например сотовые телефоны, радиотелефоны, персональные цифровые секретари (PDA), наладонные компьютеры и ноутбуки. Сильный толчок в развитии современной беспроводной связи связан с использованием мобильных терминалов для различных приложений, позволяющих пользователям таких устройств органично ввести в свою жизнь дополнительные события и потребности при сохранении адекватной возможности связи для приема и передачи всех необходимых данных и информации.
Усовершенствованный мобильный терминал, поддерживаемый сетями третьего поколения (3G) и четвертого поколения (4G) и использующий самые последние достижения в области компьютеров, программного обеспечения, дисплеев и других технических средств, способен осуществить доступ и получить множество разнообразных служб связи. К сожалению, способ выполнения и продолжительность (для пользователя) процедуры, необходимой для переключения между службами связи, могут меняться в широких пределах и непредсказуемым образом. Эти службы связи могут быть предоставлены различными источниками информации, находящимися в других сетях, и могут быть основаны и построены на разнообразных способах передачи данных. Это вводит дополнительные задержки и неопределенности при переключении мобильного терминала между различными службами связи.
По меньшей мере по этим причинам современным способам переключения между различными службами связи в мобильном терминале присущи недостатки. Соответственно имеется потребность в эффективных решениях, которые позволили бы легко и по существу немедленно переключать мобильный терминал между различными службами связи без того, чтобы пользователь замечал прерывание соединения на какое-то время.
Известные технические решения не позволяют избежать ненужных модификаций назначения на инициирующей стороне или ненужных прерываний трафика данных, если терминал на конечной стороне принял решение отклонить изменение службы с речевой на мультимедийную или если модификация не поддерживается пользовательским устройством на конечной стороне.
Если бы модификация назначения на инициирующей ее стороне для терминала на этой стороне не запускалась до того, как будет установлено, что изменение службы в пользовательском оборудовании на конечной стороне прошло успешно, можно было бы избежать ненужной модификации назначения канала и ненужного прерывания трафика данных на инициирующей стороне.
Сущность изобретения
Настоящее изобретение относится к изменению служб в беспроводной сети. В одном из вариантов осуществления настоящего изобретения предложен способ инициирования изменения служб в беспроводной системе. Беспроводная система включает инициирующую сторону и конечную сторону. Способ включает инициирование запроса на модификацию в беспроводной системе, при этом запрос на модификацию относится к изменению службы из первого режима во второй режим. Кроме того, способ включает модификацию режима терминала с переходом из первого режима во второй режим, если запрос на модификацию одобрен терминалом, и завершение назначения радиоканала после того, как запрос на модификацию будет одобрен.
Другой вариант осуществления изобретения относится к устройству для инициирования изменения службы в беспроводной системе, которая содержит инициирующую сторону и конечную сторону. Устройство содержит средство переключения, предназначенное для инициирования запроса на модификацию в беспроводной системе, при этом запрос на модификацию относится к изменению службы из первого режима во второй режим. Кроме того, устройство содержит первое средство модификации для модификации режима терминала с переходом из первого режима во второй режим, если запрос на модификацию одобрен терминалом, и средство назначения радиоканала для завершения назначения радиоканала после того, как запрос на модификацию будет одобрен.
Еще один вариант осуществления настоящего изобретения относится к системе для инициирования изменения службы в беспроводной сети, включающей инициирующую сторону и конечную сторону. Система включает блок переключения, который инициирует запрос на модификацию в беспроводной системе, при этом запрос на модификацию относится к изменению службы из первого режима во второй режим. Кроме того, система включает первый блок модификации для модификации режима терминала с переходом из первого режима во второй режим, если запрос на модификацию одобрен терминалом, и блок назначения канала для завершения назначения радиоканала после того, как запрос на модификацию будет одобрен.
Краткое описание чертежей
На фиг.1 показана блок-схема архитектуры сети согласно примеру осуществления изобретения;
на фиг.2 показана последовательность операций, поясняющая пример осуществления изобретения;
на фиг.3 поясняется сценарий для случая, когда инициирующий терминал отклоняет модификацию службы;
на фиг.4 поясняется сценарий для случая, когда конечная сторона В отклоняет изменение службы;
на фиг.5 поясняется сценарий для случая, когда контроллер радиосети на конечной стороне отклоняет запрос на службу;
на фиг.6А, 6В поясняется сценарий для случая, когда контроллер радиосети на инициирующей стороне отклоняет изменение службы.
Подробное описание предпочтительного варианта (вариантов) осуществления изобретения
На фиг.1 показан пример блок-схемы архитектуры сети. На фиг.1 показано первое пользовательское устройство (UE, User Equipment) 11 и второе пользовательское устройство UE 12, связанные посредством радиоинтерфейса Uu с соответствующими первым и вторым узлами В 21, 22 универсальной наземной сети 40 радиодоступа (UTRAN, Universal Terrestrial Radio Access Network). Узлы В 21, 22 могут участвовать в управлении радиоресурсами и могут выполнять ту же функцию, что и обычная базовая станция. Кроме того, сеть 40 UTRAN включает по меньшей мере один контроллер 30 радиосети (RNC, Radio Network Controller), связанный с узлами 21, 22 через интерфейс, обозначенный как lub, который отвечает за управление радиоресурсами в своем домене (то есть для узлов В 21, 22, связанных с этой сетью). Контроллер 30 радиосети может быть точкой доступа к службам для всех служб, которые сеть 40 UTRAN обеспечивает для базовой сети (CN, Core network) 50. На фиг.1 также показан контроллер 35 радиосети, связанный с узлами В 23 и 24 через интерфейс lub. Интерфейс расположен между контроллером 30 радиосети и контроллером 35 радиосети и обозначен как lur. Для простоты последующее обсуждение относится к контроллеру 30 радиосети, а не к контроллеру 35 радиосети.
Базовая сеть 50 может включать центр 52 коммутации мобильной связи/визитный регистр местоположения (MSC/VLR), который является коммутатором (MSC) и базой данных (VLR), обслуживающими пользовательское устройство в его текущем местоположении для служб с коммутацией каналов (CS). Функция MSC может использоваться для коммутации CS-транзакций, а функция VLR может хранить информацию о профиле услуг для посещающих сеть пользователей, а также информацию о местоположении пользовательского устройства в пределах системы обслуживания. Часть сети, доступ к которой получают через MSC/VLR 52, может называться доменом CS. MSC/VLR 52 может быть связан со шлюзовым MSC (GMSC) 54, который является коммутатором в точке, в которой базовая сеть 50 связана с внешними сетями 60 с коммутацией каналов, например, коммутируемыми телефонными сетями общего пользования (PSTN), цифровыми сетями с интеграцией служб (ISDN) или наземными сетями мобильной связи общего пользования (PLMN). Все входящие и исходящие соединения с коммутацией каналов проходят через GMSC 54.
Для обеспечения передачи группового вещания между базовой сетью 50 и сетью 40 UTRAN через интерфейс lu необходимо принять во внимание различные характеристики передачи данных при групповом вещании не только при активной передаче данных, но также при резервировании и конфигурировании необходимых ресурсов интерфейса lu. Текущие технические требования партнерского проекта 3-го поколения (3GPP) определяют протоколы сигнализации, такие как RANAP (Radio Access Network Application Part, прикладная часть сети радиодоступа) и luUP (протокол интерфейса lu в плоскости пользователя). Протокол RANAP представляет собой протокол сигнализации на интерфейсе lu, который содержит всю управляющую информацию, определенную для уровня радиосети, используемого для решений, связанных с UTRAN. Протокол luUP также относится к уровню радиосети и определен так, чтобы быть в максимально возможной степени независимым от домена базовой сети, для которого он используется. Протокол luUP может обеспечивать перенос пользовательских данных, относящихся к каналам радиодоступа, посредством интерфейса lu. Каждый канал радиодоступа (RAB, Radio Access Bearer) может иметь свой собственный экземпляр протокола. Протокол может или работать полностью прозрачно, или формировать кадры для сегментов пользовательских данных и некоторой основной управляющей сигнализации, которые используются для инициализации и онлайнового управления. В связи с этими случаями протокол luUP может иметь два режима, то есть прозрачный режим для полностью прозрачной работы и режим поддержки для заранее определенных размеров блока сервисных данных (SDU, Service Data Unit), соответствующих кадрированным сегментам пользовательских данных.
Каждое пользовательское устройство, желающее принять службу группового вещания, может иметь соглашение с провайдером услуг или с оператором службы группового вещания. Таким образом, перед началом фактического сеанса группового вещания пользовательские устройства, которым разрешено принимать службу группового вещания, конфигурируются для приема данных группового вещания через воздушный интерфейс.
Начало сеанса может начинаться из сети (NW). Например, шлюзовой узел поддержки GPRS (GGSN) или центр коммутации службы мультимедийного многоадресного группового вещания (MBMS-SC) может определить потребность в сеансе группового вещания в сотовой сети связи. Из этого сетевого устройства требование запуска сеанса группового вещания может быть передано в узел SGSN, который инициализирует активизацию контекста PDP (протокол пакетной передачи данных). Хотя активизация контекста PDP может быть выполнена прозрачно для UTRAN и пользовательского устройства, услуги контроллера радиосети могут потребоваться для указания службы группового вещания / статуса группы в сотах группового вещания. Сеть UTRAN может регистрировать, имеет ли контроллер радиосети пользователей группового вещания. Варианты осуществления изобретения могут обеспечивать, чтобы информация о пользователе группового вещания передавалась в узел SGSN, который может запустить процесс активизации контекста PDP без запроса какой-либо информации от UTRAN.
Либо контроллер радиосети, либо MBMS-SC могут отклонить запрос на активизацию по любой причине, включая, но этим не ограничиваясь, отсутствие ресурсов для этой службы или отсутствие абонентов этой службы в этой части сети.
Инициированное сетью изменение службы с речевой на мультимедийную может, например, привести к ненужным модификациям назначений каналов радиодоступа и прерываниям трафика данных, если пользовательское устройство UE В решает отклонить изменение службы с речевой на мультимедийную, или модификация назначения канала радиодоступа для пользовательского устройства В оканчивается неудачей.
В настоящем изобретении удается избежать ненужных модификаций назначения канала радиодоступа на инициирующей стороне, а также избежать ненужных прерываний трафика данных, если пользовательское оборудование В отклоняет изменение службы с речевой на мультимедийную с использованием сообщения MODIFY REJECT (МОДИФИЦИРОВАНИЕ ОТКЛОНЕНО) или если модификация назначения канала радиодоступа терпит неудачу для пользовательского оборудования UE В.
Когда посещаемый MSC, А или В, не может более поддерживать текущий мультимедийный вызов, например, вследствие ухудшения условий покрытия, посещаемый MSC этой стороны должен инициировать модификацию службы с мультимедийной на речевую. Если посещаемый MSC будет снова в состоянии поддерживать мультимедийную передачу в более поздний момент времени, в то время как речевой вызов все еще продолжается, тот же самый посещаемый MSC может инициировать изменение службы с речевой на мультимедийную, если только он не инициировал ранее изменение службы с мультимедийной на речевую и никакое другое изменение службы не было выполнено в промежутке между этими событиями.
Настоящее изобретение описывается на примере инициируемого сетью изменения службы, рассмотренного выше. Случай, когда осуществляется модификация назначения и изменение службы для обоих пользователей, описан ниже и проиллюстрирован на фиг.2, которая является базисом для описания остальных чертежей.
Кроме того, на фиг.2-6А также иллюстрируется то, что называют "процедурами базовой сети" для связи между инициирующей стороной А и конечной стороной В. Пример процедур базовой сети описан ниже.
Для того чтобы сеть была способна передать запрос, осуществить изменение службы и "отступление назад" как при установлении соединения, так и в течение активного состояния соединения, используются обычные процедуры управления транскодером вне полосы. Используемый кодек обсуждается ниже.
В процедурах согласования кодеков из инициирующего в конечный MSC передается упорядоченный список предпочтительных кодеков. Узел, который требует взаимодействия с плоскостью пользователя, удалит кодеки, которые он не поддерживает. Конечный MSC должен выбрать для использования "выбранный кодек" из списка доступных для вызова кодеков. Этот выбор будет основан на принятом списке кодеков и на информации, выданной конечным пользовательским устройством в сообщении подтверждения ВЫЗОВА (CALL).
Для указания на то, что запрошен мультимедийный вызов, в список кодеков включают фиктивный кодек. Ниже описаны два фиктивных кода.
Первый (фиктивный код 1) используется для инициируемого терминалом изменения службы с речевой на мультимедийную. Этот кодек обозначен как кодек 3G-324.M. Он поддерживается любым SCUDIF-совместимым MSC.
Второй (фиктивный код 2) должен использоваться для инициируемого сетью изменения службы с речевой на мультимедийную. Этот кодек в настоящем документе обозначен как кодек 3G-324.M2. Кодек 3G-324.M2 идентичен кодеку 3G-324M за исключением идентификатора ColD. Он должен поддерживаться любым SCDIF-совместимым MSC, поддерживающим инициируемое сетью изменение службы с речевой на мультимедийную.
Два кодека, о которых шла речь выше, используются только базовой сетью и не должны посылаться из терминала в информационном элементе со списком поддерживаемых кодеков (Supported Codec List IE). В инициирующем MSC имеется список поддерживаемых типов кодеков, перечисленных в порядке предпочтения.
Если сообщение SETUP (УСТАНОВКА), принятое из пользовательского устройства, в дополнение к мультимедийному информационному элементу BC-IE и речевому информационному элементу BC-IE будет содержать индикатор повторения (Repeat Indicator) со значением изменения службы и "отступления назад", то MSC в списке поддерживаемых типов кодеков должен включать кодек 3G-324.M.
Ниже описаны примеры осуществления настоящего изобретения. На фиг.2, как обсуждалось выше, на шаге (а) конфигурации (конфигурация 1 и конфигурация 2) заранее согласуются в процессе установления соединения. Это обеспечивается центром коммутации мобильной связи (MSC) пользователя А (MSC А), который посылает согласованные назначения в контроллер радиосети (RNC) пользователя A (RNC А). Запрашивается изменение службы, и контроллер RNC А запускает процедуру (b) изменения службы.
Процедура (b) изменения службы начинается с того, что из контроллера радиосети RNC А в MSC А посылается MODIFY REQUEST, т.е. ЗАПРОС НА МОДИФИКАЦИЮ конфигурации канала радиодоступа для прикладного протокола сети радиодоступа (RANAP RAB).
На шаге (с) MSC А запрашивает модификацию, посылая сообщение MODIFY (МОДИФИКАЦИЯ) в пользовательское устройство А. На шаге (α) пользовательское устройство А одобряет изменение, посылая сообщение MODIFY COMPLETE (МОДИФИКАЦИЯ ЗАВЕРШЕНА).
Только после того как пользовательское устройство А одобрит запрос MODIFY путем посылки сообщения MODIFY COMPLETE, начинается процедура изменения службы для пользовательского устройства В на удаленной стороне.
На удаленной стороне на шаге (f) MSC В инициирует процедуру изменения в процессе соединения по направлению к пользовательскому устройству В с использованием сообщения MODIFY. Терминал должен запросить подтверждение от пользователя, если только конфигурацией не определено иначе. Если изменение одобрено, пользовательское устройство В отвечает (g) центру MSC В сообщением MODIFY COMPLETE (МОДИФИКАЦИЯ ЗАВЕРШЕНА), а если изменение отклонено, то должно быть послано сообщение MODIFY REJECT (МОДИФИКАЦИЯ ОТКЛОНЕНА).
При приеме сообщения MODIFY ни пользовательское устройство А, ни пользовательское устройство В не прерывает трафик данных и должно продолжать посылку и прием данных в прежнем режиме до тех пор, пока каналы радиодоступа на обеих сторонах не будут реконфигурированы (h)-(i) для нового режима. Если терминал, в этом примере пользовательское устройство В, одобряет модификацию с посылкой (g) сообщения MODIFY COMPLETE (МОДИФИКАЦИЯ ЗАВЕРШЕНА), то радиоканал должен посылать и принимать данные в новом режиме. После того как обе стороны одобрят изменение службы, из MSC А в контроллер А радиосети посылается (k) запрос на назначение канала радиодоступа. На шаге (l) контроллер А радиосети посылает указание на то, что назначение канала радиодоступа завершено.
Если терминал на любой из сторон отклоняет изменение службы, то посещаемый MSC должен или сбросить вызов, или инициировать процедуру изменения службы в направлении другой стороны для возврата к первоначальной службе. В настоящем примере инициируется процедура изменения службы для возврата к первоначальной службе.
На фиг.3 поясняется сценарий, при котором терминал инициирующей стороны отклоняет модификацию службы. Шаги (а) и (b) назначения и запроса на реконфигурацию аналогичны тем, которые обсуждались выше в связи с фиг.2. Однако в этом сценарии пользовательское устройство А отклоняет (d) запрос на реконфигурацию, который был послан из MSC А. Поскольку пользовательское устройство А отклонило запрос на изменение конфигурации, процедура запуска изменения службы для конечной стороны В не была начата. Поэтому удается избежать ненужных модификаций назначения канала радиодоступа (RAB Assignment) как на инициирующей стороне А, так и на конечной стороне В и избежать ненужных прерываний трафика данных на инициирующей стороне А.
На фиг.4 поясняется сценарий, при котором конечная сторона В отклоняет изменение службы. Согласно этому примеру изменение службы отклоняется пользовательским устройством UE В. Шаги (a)-(f) аналогичны описанным выше со ссылкой на фиг.2. Однако на конечной стороне В пользовательским устройством В изменение не одобряется, и пользовательское устройство В отвечает (gg) центру MSC В сообщением MODIFY REJECT (МОДИФИКАЦИЯ ОТКЛОНЕНА).
На шаге (hh) конечная сторона указывает, что требуемое изменение службы на стороне В не было успешным. В это время MSC А посылает новый запрос MODIFY путем посылки (l) сообщения MODIFY в пользовательское устройство UE А с целью изменения режима вызова обратно к речевому из мультимедийного, и этот запрос одобряется (m). В этом примере, хотя пользовательское устройство UE В отклонило запрос на модификацию конфигурации, на инициирующей стороне А удается избежать ненужных модификаций назначения канала радиодоступа и ненужных прерываний трафика данных.
На фиг.5 поясняется сценарий работы контроллера радиосети (RNC) на конечной стороне при отклонении им запроса на обслуживание согласно примеру осуществления настоящего изобретения. Запрос назначения канала радиодоступа отклоняется контроллером В радиосети. Этот сценарий отличается от того, в котором пользовательское устройство В отклоняет изменение службы, поскольку пользовательское устройство В перешло с речевой службы на мультимедийную и должно будет вернуться обратно в речевой режим.
На фиг.5 шаги (а)-(h) аналогичны описанным при обсуждении фиг.2. Однако при этом пользовательское устройство В одобрило запрос MODIFY, который был послан, и процесс назначения канала радиодоступа на стороне В начался. Как было сказано выше, запрос на назначение канала радиодоступа посылается (h) из MSC В в контроллер В радиосети. Однако согласно этому примеру контроллер В радиосети отклоняет запрос, в результате чего модифицировать назначение канала радиодоступа не удается (ii).
В результате неудавшейся попытки изменения назначения канала радиодоступа из MSC В в пользовательское устройство В посылается новое сообщение MODIFY, чтобы вернуться назад к исходному режиму, который в этом примере является речевым (n)-(о). После того как пользовательское устройство В возвращается назад к речевому режиму, инициирующая сторона А уведомляется (р) о неудавшемся изменении службы на стороне В. При этом пользовательское устройство А возвращается (q)-(r) из мультимедийного режима назад в речевой режим.
На фиг.6А, 6В поясняется сценарий, при котором контроллер радиосети на инициирующей стороне отклоняет изменение службы. Шаги (а)-(j) аналогичны описанным при обсуждении фиг.2. Как описано ниже, в этой точке как пользовательское устройство А, так и пользовательское устройство В перешли из мультимедийного режима в речевой. Поскольку для конечной стороны В назначение канала радиодоступа сейчас завершено, MSC A теперь посылает (j) сообщение с запросом на назначение канала радиодоступа в контроллер радиосети. По причинам, рассмотренным выше, запрос назначения у контроллера радиосети терпит неудачу, и об этом уведомляется (kk) центр MSC.
На шаге (t) пользовательское устройство В должно быть возвращено обратно в исходный режим, в этом случае речевой, путем посылки нового сообщения MODIFY. Как только это изменение будет одобрено (u), процедура начинает перевод конечной стороны В обратно в речевой режим.
В ответ на одобрение на шаге (u) пользовательским устройством В запроса на изменение посылают (v) новый запрос на назначение канала радиодоступа для стороны В. При этом после успешного назначения (w) канала радиодоступа на стороне В режим вызова переводится назад в речевой.
На шаге (х) процедура базовой сети передает и индицирует информацию об успешной модификации режима пользовательского устройства В и назначении канала радиодоступа на стороне В. Отметим, однако, что новое назначение канала радиодоступа для пользовательского устройства А не требуется, поскольку старые ресурсы не были освобождены. Таким образом, удается избежать ненужного назначения канала радиодоступа для инициирующей стороны.
Специалистам в данной области очевидно, что рассмотренное выше изобретение может быть осуществлено с другим порядком операций и/или с другими элементами аппаратных средств в конфигурациях, которые отличаются от раскрытых в описании. Поэтому, хотя изобретение было описано на основе предпочтительных вариантов его осуществления, специалистам в данной области очевидно, что возможны определенные модификации, вариации и альтернативы, которые, тем не менее, остаются в пределах объема настоящего изобретения. Например, изобретение может быть осуществлено в виде аппаратного обеспечения, программного обеспечения, компьютерного продукта, включающего считываемый компьютером носитель, программ, записанных в ПЗУ, специализированной интегральной схемы (ASIC) и т.п.
1. Способ инициирования изменения службы в беспроводной системе, содержащей инициирующую сторону, включающую первый терминал, и конечную сторону, включающую второй терминал, и сеть, при этом указанный способ включает:
инициирование узлом базовой сети беспроводной системы запроса на модификацию, который относится к изменению службы из первого режима во второй режим для первого и второго терминала;
реконфигурирование назначения радиоканала после того, как запрос на модификацию одобрен первым терминалом и вторым терминалом, при этом инициирование запроса модификации запускает модификацию первого терминала при условии приема узлом базовой сети одобрения модификации от первого терминала и от узла сети, обслуживающего второй терминал.
2. Способ по п.1, в котором:
инициирование запроса на модификацию включает инициирование запроса на модификацию на инициирующей стороне беспроводной системы.
3. Способ по п.1, в котором:
инициирование запроса на модификацию включает инициирование запроса на модификацию на инициирующей стороне беспроводной системы;
реконфигурирование назначения радиоканала включает реконфигурирование назначения радиоканала на инициирующей стороне, когда назначение радиоканала реконфигурировано на конечной стороне.
4. Способ по п.1, в котором:
инициирование запроса на модификацию включает инициирование запроса на модификацию на инициирующей стороне беспроводной системы;
а реконфигурирование назначения радиоканала включает реконфигурирование назначения радиоканала на конечной стороне после того, как запрос на модификацию одобрен вторым терминалом;
уведомление инициирующей стороны о реконфигурированном назначении
радиоканала на конечной стороне; и
реконфигурирование назначения радиоканала на инициирующей стороне.
5. Способ по п.1, в котором:
инициирование запроса на модификацию включает инициирование запроса на модификацию на инициирующей стороне беспроводной системы;
одобрение запроса на модификацию на инициирующей стороне;
уведомление конечной стороны о том, что инициирующая сторона одобрила запрос на модификацию; и
одобрение запроса на модификацию на конечной стороне;
а реконфигурирование назначения радиоканала включает реконфигурирование назначения радиоканала на конечной стороне после того, как запрос на модификацию одобрен вторым терминалом;
уведомление инициирующей стороны о реконфигурированном назначении радиоканала на конечной стороне; и
реконфигурирование назначения радиоканала на инициирующей стороне.
6. Способ по п.1, в котором:
инициирование запроса на модификацию включает инициирование запроса на модификацию на инициирующей стороне беспроводной системы;
одобрение запроса на модификацию инициирующей стороной;
уведомление конечной стороны о том, что инициирующая сторона одобрила запрос на модификацию; и
одобрение запроса на модификацию на конечной стороне;
а реконфигурирование назначения радиоканала включает реконфигурирование назначения радиоканала на конечной стороне после того, как запрос на модификацию одобрен вторым терминалом;
уведомление инициирующей стороны о реконфигурированном назначении радиоканала на конечной стороне;
уведомление конечной стороны о неудаче реконфигурирования назначения радиоканала на инициирующей стороне;
возврат второго терминала из второго режима в первый режим;
одобрение и реконфигурирование второго назначения радиоканала на конечной стороне;
уведомление инициирующей стороны о реконфигурированном втором назначении радиоканала; и
перевод первого терминала в первый режим из второго режима.
7. Узел базовой сети, инициирующий изменение службы в беспроводной системе, содержащей инициирующую сторону, включающую
первый терминал, и конечную сторону, включающую второй терминал, и сеть, при этом указанный узел содержит:
средство инициирования для инициирования запроса на модификацию, который относится к изменению службы из первого режима во второй режим для первого и второго терминалов;
средство приема для приема одобрения модификации от первого терминала и от узла сети, обслуживающего второй терминал.
средство реконфигурирования для реконфигурирования назначения радиоканала после одобрения запроса на модификацию первым терминалом и вторым терминалом;
при этом инициирование запроса модификации средством инициирования запускает модификацию первого терминала при условии одобрения модификации первым терминалом и узлом сети, обслуживающим второй терминал.
8. Узел базовой сети по п.7, в котором:
средство инициирования инициирует запрос на модификацию на инициирующей стороне беспроводной системы.
9. Узел базовой сети по п.7, в котором:
средство инициирования инициирует запрос на модификацию на инициирующей стороне беспроводной системы;
средство реконфигурации сконфигурировано для реконфигурации назначения радиоканала на инициирующей стороне, когда назначение радиоканала реконфигурировано на конечной стороне.
10. Узел базовой сети для инициирования изменения службы в беспроводной сети, содержащей инициирующую сторону, включающую первый терминал, и конечную сторону, включающую второй терминал, и сеть, при этом указанный узел содержит:
средство приема для приема от сети запроса на модификацию режима из первого режима во второй режим на инициирующей стороне беспроводной системы;
средство для запрашивания у первого терминала одобрения запроса на модификацию;
средство уведомления для уведомления конечной стороны о том, что инициирующая сторона одобрила запрос на модификацию, если запрос на модификацию одобрен первым терминалом; и
средство верификации для проверки, одобрил ли второй терминал запрос на модификацию;
при этом средство приема также конфигурировано для приема уведомления о том, что назначение канала реконфигурировано, после одобрения запроса на модификацию первым и вторым терминалом.
