СПОСОБ И УСТРОЙСТВО ДЛЯ ДОБАВЛЕНИЯ НОВОГО ЧЛЕНА К АКТИВНОМУ ГРУППОВОМУ ВЫЗОВУ В СЕТИ ГРУППОВОЙ СВЯЗИ Российский патент 2008 года по МПК H04Q7/28 

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

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

Предшествующий уровень техники

Класс беспроводной услуги, предназначенный для быстрой, эффективной связи от точки к точке двусторонней или от точки к множеству точек (групповой связи), существовал в разных видах на протяжении многих лет. В целом, эти услуги были полудуплексными, т.е. чтобы начать говорить, пользователю приходилось нажимать кнопку переключения режимов приема/передачи (тангенту) на своем телефоне/рации. Нажатие кнопки либо переключает его рацию, в некоторых реализациях, либо, в координируемой системе, где связь осуществляется через сервер некоторого типа, указывает запрос пользователя на режим передачи («право слова»). Если предоставлен режим передачи или разрешение говорить, пользователь обычно говорит несколько секунд, после чего отпускает тангенту, и другие пользователи могут запрашивать режим передачи. Связь осуществляется обычно от одного говорящего абонента к группе слушающих абонентов, но может осуществляться в двустороннем режиме. Эта услуга традиционно использовалась в приложениях, где одно лицо, «диспетчер», нуждается в связи с группой людей, например, персоналом полевого обслуживания или водителями такси, и отсюда происходит название «диспетчеризация» для услуги.

Аналогичные услуги обеспечиваются в Интернете и в общем случае известны как интерактивный речевой сеанс («речевой чат»). Эти услуги обычно реализуются в качестве приложений персонального компьютера, которые отправляют кадры вокодера в пакетах Интернет-протокола (IP), что представляет собой услугу передачи речи поверх IP (VOIP), на центральный сервер группового чата или, возможно, от клиента к клиенту в услуге связи одноранговых устройств.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перечень чертежей

Признаки и преимущества настоящего изобретения явствуют из подробного описания, приведенного ниже в сочетании с чертежами, снабженными сквозной системой обозначений:

фиг.1 - схема системы групповой связи;

фиг.2 - схема взаимодействия нескольких приложений друг с другом;

фиг.3 - схема иллюстративного процесса регистрации пользователя согласно одному варианту осуществления;

фиг.4 - схема иллюстративного процесса локального внутрирегионального установления вызова согласно одному варианту осуществления;

фиг.5 - схема иллюстративного процесса удаленного внутрирегионального установления вызова согласно одному варианту осуществления;

фиг.6 - схема иллюстративного процесса локального межрегионального установления вызова согласно одному варианту осуществления;

фиг.7 - схема иллюстративного процесса удаленного межрегионального установления вызова согласно одному варианту осуществления;

фиг.8 - схема иллюстративного процесса выхода из группового вызова согласно одному варианту осуществления;

фиг.9 - схема иллюстративного процесса завершения группового вызова согласно одному варианту осуществления;

фиг.10 - схема иллюстративного процесса отправки извещения о групповом вызове согласно одному варианту осуществления;

фиг.11 - схема иллюстративного процесса присоединения к групповому вызову согласно одному варианту осуществления;

фиг.12 - схема иллюстративного процесса прерывания обслуживания говорящего согласно одному варианту осуществления;

фиг.13 - схема иллюстративного процесса добавления новых членов к активному групповому вызову согласно одному варианту осуществления;

фиг.14 - схема иллюстративного процесса исключения участников из группового вызова согласно одному варианту осуществления;

фиг.15 - схема иллюстративного процесса отмены регистрации пользователя согласно одному варианту осуществления;

фиг.16 - схема взаимодействия нескольких устройств связи со средством управления (менеджером) связью (СУС, СМ) согласно одному варианту осуществления;

фиг.17 - схема буферизации полезной информации на стороне средства управления связью согласно одному варианту осуществления; и

фиг.18 - схема буферизации полезной информации на стороне клиента согласно одному варианту осуществления.

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

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

На фиг.1 показана иллюстративная функциональная блок-схема системы 100 групповой связи. Система 100 групповой связи известна, так же как система с переключением между приемом и передачей (РТТ), услуга сетевого широковещания (УСВ, NBS), система диспетчеризации или система связи от точки к множеству точек. Согласно одному варианту осуществления система 100 групповой связи включает в себя компоненты сервера приложений, например диспетчеры, локальные серверы, комплексы модуля управления полезной информацией (МУПИ, MCU), серверы регистрации использования и клиенты интернет-протокола (IP) (устройства беспроводной и/или проводной связи с возможностью соединения по IP). Компоненты сервера приложений могут быть развернуты либо в виде централизованной структуры, либо в виде региональных структур, в зависимости от функций компонентов. Централизованная структура может включать в себя опорный диспетчер (ОД, HD) 102, опорный сервер 104 определения местоположения (ОСП, HLS) и базу данных 106 пользователей/групп. Эти компоненты могут быть централизованно размещены в сети поставщика услуг и могут быть доступны региональным структурам. Централизованные компоненты могут использоваться при определении местоположения перемещающихся пользователей и при инициировании межрегиональных групповых вызовов. Региональная структура 108, 110 может включать в себя региональный сервер 112 определения местоположения (РСП, PLS), региональный диспетчер (РД, RD) 114, региональный комплекс 116 модуля управления полезной информацией (МУПИ) и региональный сервер 118 регистрации использования (СРИ, ULS).

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

Устройства 120, 122 групповой связи (клиенты), которые могут быть развернуты, например, в телефонной трубке cdma2000, запрашивают сеанс передачи пакетных данных с использованием стандартной опции услуги передачи данных и используют этот сеанс для регистрации своего IP-адреса с помощью сервера приложений и для осуществления инициирования групповых вызовов. Согласно одному варианту осуществления компоненты 108, 110 сервера приложений подключены к узлам обслуживания передачи пакетных данных (УОПД, PDSN) поставщика услуг. Клиенты 120 и 122, запросившие сеанс передачи пакетных данных у инфраструктуры беспроводной связи, имеют возможность связи по IP с компонентами 108, 110 сервера приложений через УОПД.

После включения питания, клиенты 120, 122 могут запросить сеанс передачи пакетных данных с использованием опции услуги передачи данных. В порядке установления сеанса передачи пакетных данных, клиенту назначается IP-адрес. В это время клиент также получает адрес сервера 124 службы доменных имен (СДИ, DNS). Клиент 120, 122 запрашивает сервер 124 СДИ, например, используя поиск записи услуги (SRV), чтобы найти адрес РСП 112. Определив местоположение РСП 112, клиент 120, 122 может осуществить регистрацию, сообщив серверу приложений свою информацию местоположения, например IP-адрес. Регистрация может осуществляться с использованием протокола IP, например протокола инициирования сеанса (SIP) поверх протокола дейтаграмм пользователя (UDP). IP-адрес клиента 120, 122 может использоваться для связи с клиентом, когда пользователь приглашается в групповой вызов.

Согласно одному варианту осуществления по завершении регистрации, клиент может осуществить поиск другой записи SRV в СДИ, чтобы найти адрес регионального диспетчера 114. Клиент связывается с региональным диспетчером всякий раз, когда пользователь запрашивает начало вызова или передает извещение. Интерфейсом между региональным диспетчером 114 и клиентом 120, 122 может служить протокол сигнализации поверх UDP.

После установления группового вызова, клиент 120, 122 и комплекс 116 МУПИ обмениваются полезной информацией и сообщениями сигнализации. Согласно одному варианту осуществления передача полезной информации между участниками вызова и комплексом 116 МУПИ может осуществляться с использованием протокола передачи в реальном времени (RTP) поверх UDP. Сообщения сигнализации могут также соответствовать протоколу сигнализации поверх UDP. Эти протоколы и обеспечиваемые ими функции описаны ниже.

Компоненты

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

Клиенты

Клиент 120, 122 групповой связи может работать на любой конечной точке IP, на которой имеется доступ к соответствующему вокодеру(вокодерам). Конечные точки IP могут включать в себя приложения, выполняющиеся в беспроводной системе, например cdma2000, платформе разработки приложений, например двоичной среде времени выполнения для беспроводной связи (BREW), и персональных компьютерах.

Клиент может включать в себя прикладную программу, которая может быть разработана с использованием BREW, и интерфейсы к программному обеспечению модема мобильной станции (ММС, MSM), которые могут загружаться на клиент, содержащий среду BREW. BREW - это платформа, позволяющая разработчикам создавать приложения, которые могут работать на клиентских устройствах связи. BREW обеспечивает разработчику приложений слой изоляции, позволяющий разрабатывать приложения, не имея непосредственного контакта с программным обеспечением ММС и программным обеспечением производителя оригинального оборудования (ПОО, ОЕМ). Она позволяет быстро разрабатывать и усовершенствовать приложения независимо от программного обеспечения ММС и/или ПОО. Она также позволяет загружать приложения в любое устройство, содержащее среду BREW. Согласно фиг.2 клиентская прикладная программа 202 групповой связи может выполняться параллельно с другими приложениями 204, 206, 208, 210. В то время, как эти услуги могут предоставляться непосредственно через интерфейсы ПОО 212 и ММС 214, BREW обеспечивает изоляцию от модификаций, произведенных приложением на этих уровнях. Это позволяет развивать ПОО 212 и ММС 214 отдельно от приложений 202, 204, 206, 208, 210 передачи данных.

Чтобы клиент работал эффективно на персональном компьютере, персональный компьютер может обеспечивать доступ к совместимому вокодеру, доступ к драйверам звуковой платы и возможность соединения по IP с серверами приложений.

Сервер определения местоположения

Согласно одному варианту осуществления сервер определения местоположения (СП, LS) может принимать и/или поддерживать информацию местоположения пользователя, например IP-адрес сетевого уровня, физическое местоположение пользователя, например широту и долготу, и/или идентификатор зоны пакетных данных, т.е. системный идентификатор, рассылаемый в эфире по прямым общим каналам, который идентифицирует возможности УОПД, обеспечивающего услугу передачи пакетных данных для данного сектора. Согласно одному варианту осуществления СП может включать в себя компонент, обрабатывающий регистрации клиентов и выдающий информацию местоположения пользователя другим приложениям, например услуге мгновенного обмена сообщениями, с использованием интерфейса SIP.

СП может включать в себя два функциональных элемента, а именно региональный сервер 112 определения местоположения (РСП) и опорный сервер 104 определения местоположения (ОСП). РСП 112 может быть развернут в каждом регионе, а ОСП 104 может быть централизованным. Подробности относительно этих элементов и выполняемых ими функций описаны ниже.

Региональный сервер определения местоположения

РСП 112 может обрабатывать и поддерживать регистрации клиентов, находящихся в его регионе. Согласно одному варианту осуществления РСП 112 является стандартным СП на основе SIP, с которым связано хранилище информации местоположения пользователя. В порядке поддержания записей регистрации, РСП 112 может проверять дату истечения срока действия, поля «истечение срока», для каждой регистрации. РСП обеспечивает удаление записей, срок действия которых истек, и информирует региональный диспетчер и ОСП об удаленных записях.

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

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

РСП 112 может уведомлять РД 114 в случае обновления информации местоположения пользователя или ее удаления из РСП 112. Благодаря этому РСП 112 и РД 114 располагают последней информацией о пользователях, зарегистрированных в регионе.

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

Опорный сервер определения местоположения

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

Если ОСП 104 является централизованным компонентом и серверы РСП связываются с ним, то ОСП может разрешать конфликты, связанные с множественными регистрациями в разных регионах для перемещающихся пользователей. ОСП 104 может принимать информацию регистрации от каждого РСП. Если ОСП 104 принимает множество регистраций для одного и того же пользователя, то ОСП 104 может сохранять самую последнюю регистрацию и запрашивать удаление устаревшей регистрации (регистраций) пользователя из РСП. Это, в свою очередь, может приводить к удалению кэшированной информации для этого пользователя из РД 114, связанного с РСП, который содержит устаревшую регистрацию.

Диспетчер

Диспетчер может способствовать установлению вызова, определяя местоположение пользователей и назначая групповые вызовы комплексу 116 модуля управления полезной информацией (МУПИ). Диспетчер является компонентом сервера, который играет важнейшую роль в удовлетворении требования «мгновенного доступа». Чтобы обеспечить минимальное время установления вызова, диспетчер может включать в себя два функциональных элемента с аналогичной структурой и функциями, но имеющие разные стратегии развертывания. Эти два элемента, региональный диспетчер (РД) 114 и опорный диспетчер (ОД) 102, подробно описаны в следующих разделах.

Региональный диспетчер

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

Согласно одному варианту осуществления групповая информация, которую РД сохраняет в кэше, включает в себя список членов группы и адрес комплекса 116 МУПИ, на котором действует группа. РД 114 может поддерживать список членов и адрес МУПИ на протяжении времени действия вызова. Это помогает РД 114 быстро определять, содержит ли входящий запрос на установление вызова определение группы, которое идентично определению группы, имеющей связанный с ней вызов, уже действующий в системе, и это позволяет РД быстро отвечать на запросы на установление вызова и уверенно удовлетворять или отклонять запрос на режим передачи, в качестве реакции.

РД 114 может удовлетворять или отклонять запрос на режим передачи. РД 114 может принимать решение, запросить ли комплекс 116 МУПИ о добавлении пользователя к вызову в качестве «присоединившегося» участника или начать новый вызов с соответствующим списком членов.

При обработке запроса на установление вызова, РД 114 может использовать кэшированную информацию о пользователях для извлечения информации местоположения для пользователей, указанных в запросе на установление вызова. Если не удается установить местоположение пользователя, то РД 114 может запросить ОД 102 определить местоположение пользователя. Согласно одному варианту осуществления, если определено местоположение, по меньшей мере, одного или более целевых пользователей, то РД 114 продолжает установление вызова. После определения местоположения целей, РД 114 может принимать решение, какому МУПИ следует назначить вызов. Это определение может базироваться на IP-адресах пользователей в группе, включая инициатора.

РД 114 может обрабатывать запросы на извещение аналогично запросам на установление вызова. Согласно одному варианту осуществления запрос на извещение назначается локальному комплексу 116 МУПИ для обработки независимо от местоположения целей.

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

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

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

Опорный диспетчер

Опорный диспетчер (ОД) 102 может отслеживать информацию местоположения зарегистрированных пользователей. ОД может содержать информацию местоположения для пользователей, которые заранее зарегистрировались с помощью РСП 112.

Согласно рассмотренному выше каждый РСП 112 может уведомить связанный с ним РД 114 всякий раз, когда происходит регистрация, перерегистрация, отмена регистрации или истечение срока действия регистрации пользователя. РД 114 может использовать эту информацию для загрузки информации о пользователях в свой локальный кэш или ее удаления. Каждый РД 114 может обновлять ОД 102 информацией местоположения пользователя. Поскольку ОД 102 принимает обновления от РД 114, то ОД 114 может помогать в отыскании пользователей, разнесенных географически по разным регионам. РД 114 может запрашивать помощь у ОД 102, когда он принимает запрос в отношении пользователя, который на данный момент не зарегистрирован в регионе, т.е. не значится в кэше РД с информацией о пользователях.

Сервер СДИ

Согласно одному варианту осуществления система 100 групповой связи может использовать сервер 124 СДИ поставщика услуг для предоставления информации о местоположении РСП 112 и РД 114 клиентам. Эта информация может конфигурироваться на каждой региональной структуре и обновляться для обеспечения ее точности.

Согласно одному варианту осуществления каждый клиент узнает адрес сервера СДИ посредством согласования по протоколу управления Интернет-протоколом (IPCP) в ходе установления сеанса протокола двухточечной связи (PPP), когда клиент запрашивает сеанс передачи пакетных данных. Таким образом, о сервере 124 СДИ может быть сообщено таким образом для каждого региона. Это позволяет клиенту перемещаться из региона в регион и связываться с сервером 124 СДИ в том регионе, где находится клиент. Сервер 124 СДИ развернут для каждого региона, совместно с каждым УОПД. Согласно одному варианту осуществления, сервер 124 СДИ может обновляться каждым РД 124 и РСП, который обслуживает УОПД, с которым связан сервер 124 СДИ.

Согласно одному варианту осуществления механизм, используемый для определения местоположения соответствующих РД 114 и РСП 112 основан на комбинации адресации СДИ и SIP. Поиск записи услуги (SRV) СДИ может осуществляться на основании раздела «<domain>» («<домен>») уникального идентификатора ресурса (URI) SIP, под которым регистрируется клиент. Запрос на запись SRV может включать в себя протокол или услугу, которую запрашивающая сторона пытается найти. Например, в случае попытки определения местоположения РСП 112, клиент может запрашивать «услугу регистрации» при поиске записи SRV СДИ. Ответ СДИ может включать в себя один или несколько действительных адресов сети и порта для сервера, который предоставляет запрашиваемую услугу. Сервер 124 СДИ можно использовать для выравнивания нагрузки между серверами, которые предоставляют одну и ту же услугу, позволяя серверу 124 СДИ циклически переключаться между множеством серверов при возвращении ответов на клиентские запросы.

База данных пользователей/групп

Согласно одному варианту осуществления база данных 106 пользователей/групп является центральным хранилищем информации о пользователях и группах. Для каждого пользователя база данных может включать в себя такую информацию, как адрес пользователя, ранг прерывания обслуживания, информация аутентификации, контактная информация пользователя и флаг законного перехвата, который указывает на то, находится ли пользователь под надзором. База данных также может включать в себя определения заранее заданных групп, которые являются списками пользователей, и соответствующее имя группы, для модели разговорной комнаты услуг диспетчеризации. Каждую группу можно однозначно идентифицировать, например, адресом группы. Клиент может использовать адрес группы для идентификации группы в запросе на установление группового вызова. РД 114 может использовать адрес группы для извлечения соответствующего списка членов из базы данных 106 пользователей/групп, когда он принимает запрос на установление группового вызова с заранее заданной группой в нем.

Комплекс модуля управления полезной информацией

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

- Обработку назначений вызовов от РД 114.

- Отправку информации статуса и нагрузки на ХУПИ.

- Отправку информации инициирования вызова клиентом.

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

- Обеспечение надежной доставки сообщений сигнализации клиентам.

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

- Обеспечение преобразования полезной информации с использованием соответствующего транскодера для вызовов «от одного ко множеству» со «смешанным» вокодером.

- Мониторинг активности вызова и инициирование завершения вызова на основании неактивности переноса полезной информации.

- Формирование информации об использовании для сервера 118 регистрации использования (СРИ).

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

МУПИ может обрабатывать запросы на извещение от РД 114, отправлять извещающее уведомление клиенту и ожидать подтверждений приема от клиентов. После приема подтверждений приема от целей, МУПИ высвобождает любые ресурсы, назначенные транзакции извещения. В это время МУПИ может обрабатывать другие назначения вызова или запросы на извещение.

Сервер регистрации на использования

СРИ 118 может существовать в каждом регионе и может размещаться совместно с комплексом 116 МУПИ. СРИ 118 может собирать события на использования от комплекса 116 МУПИ для каждого вызова или обработки извещения, форматировать их в запись данных использования (ЗДИ, UDR) и затем сохраняет эти ЗДИ в последовательности файлов ЗДИ. Записи ЗДИ для вызовов могут содержать информацию, касающуюся отдельных вызовов, включая список участников и итоги использования для участников. ЗДИ для извещений может содержать информацию, которая указывает инициатора извещения и целевых пользователей, которым было отправлено извещение. Файлы ЗДИ могут быть собраны поставщиком услуг для анализа тарификации и могут быть удалены по истечении определенного периода времени.

СРИ 118 может записывать по одной ЗДИ на экземпляр вызова в конце каждого вызова. СРИ 118 может также записывать одну ЗДИ каждый раз при обработке запроса на извещение. ЗДИ, записанные СРИ 118, могут содержать следующую информацию.

- Идентификатор экземпляра вызова или идентификатор экземпляра извещения.

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

- Время начала вызова или извещения.

- Время конца вызова или извещения.

- Имя и/или идентификатор инициирующего пользователя.

- IP-адрес инициирующего пользователя.

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

Согласно одному варианту осуществления для каждого вызова создается отдельная ЗДИ, которая может представлять полное собрание речевых фрагментов в ходе вызова. Если необходима регистрация событий посредством ЗДИ для каждого речевого фрагмента, его можно реализовать за счет дополнительной нагрузки на обработку данных, файловых операций ввода/вывода и требований к дисковому пространству.

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

Регистрация

В системе беспроводной связи, например в системе множественного доступа с кодовым разделением каналов (МДКР, CDMA), регистрация - это процесс, посредством которого мобильная станция информирует инфраструктуру системы беспроводной связи о своем местоположении. Эта информация местоположения может включать в себя географическую область, где находится мобильная станция, и идентификационные данные базовой станции, обслуживающей мобильную станцию, что может использоваться для содействия в более эффективном использовании каналов поискового вызова и доступа.

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

Регистрация может включать в себя процесс осуществления клиентом IP связи с компонентом сервера SIP для объявления и поддержания своей информации местоположения, например IP-адреса. Компонент сервера SIP, который обеспечивает эту функцию, представляет собой сервер определения местоположения. Способ, посредством которого клиент извещает сервер определения местоположения о своем местоположении или изменениях своего местоположения, это способ SIP REGISTER (способ регистрации SIP).

Согласно одному варианту осуществления клиенты регистрируют свою информацию местоположения с помощью регионального сервера местоположения. Другие приложения на основе IP, например приложения мгновенного обмена сообщениями, могут пользоваться информацией об IP-адресе каждого клиента на сервере определения местоположения. Регистрацию может осуществлять внешняя служба или клиент. На фиг.3 показана иллюстративная последовательность операций для осуществления функции регистрации.

После включения питания 302, клиент может запросить сеанс передачи пакетных данных и начать процесс регистрации своего IP-адреса с помощью РСП 112. Для осуществления регистрации, клиент может осуществлять поиск 304 записи SRV в СДИ, чтобы определить адрес РСП. После извлечения 306 адреса РСП, клиент может зарегистрировать свою информацию местоположения, например, с использованием сообщения 308 регистрации SIP. РСП может аутентифицировать 310 пользователя и выдать ответ 312 клиенту. РСП может известить 314 регионального диспетчера о том, что пользователь зарегистрирован, и региональный диспетчер может использовать эту информацию для предварительной загрузки соответствующей записи данных, ассоциированной с этим пользователем, чтобы способствовать сокращению времени ответа в ходе установления вызова. В этот момент к клиенту можно обращаться с приглашением принять участие в групповом вызове. Согласно одному варианту осуществления клиентам может понадобиться осуществлять регистрацию для приема группового вызова, независимо от имеющегося у них типа соединений для передачи данных, т.е. беспроводных или проводных.

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

После завершения первоначальной регистрации, клиент может позволить своему сеансу передачи пакетных данных перейти в неактивный режим, что может освободить выделенный канал трафика. Клиент может отслеживать свой сеанс передачи пакетных данных, чтобы гарантировать, что он остается действительным в течение продолжительных периодов бездействия. Условия, которые могут влиять на действительность сеанса, включают в себя перемещение в область с другим идентификатором зоны пакетных данных, замирание или потерю обслуживания и прием и/или размещение вызова телефонной сети общего пользования (ТСОП, PSTN). IP-адрес клиента может измениться, и клиенту может потребоваться повторно установить соединения для обмена данными с инфраструктурой. Когда клиент повторно устанавливает свой сеанс передачи пакетных данных, он получает новый IP-адрес. Новый IP-адрес нужно передать на сервер определения местоположения, чтобы гарантировать, что информация местоположения клиента остается точной. Для этого можно осуществить перерегистрацию.

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

Инициирование группового вызова

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

«Группа» ассоциативно связана с инициатором, пользователем, инициировавшим создание группы, и списком членов, содержащим целевого пользователя или пользователей. Список членов может содержать одного или нескольких пользователей, одну или несколько заранее заданных групп или комбинацию того и другого. Если список членов содержит только одного пользователя, то вызов, инициированный с использованием этого списка членов, обычно называют частным вызовом. Если список членов содержит какие-либо заранее заданные группы, то региональный диспетчер может расширить заранее заданные группы в список из одного или нескольких целевых пользователей, например, заменив идентификатор заранее заданной группы в исходном списке членов списком членов, связанным с заранее заданной группой. После расширения заранее заданных групп, результирующий список членов может содержать только имена целевых пользователей. В этот момент, региональный диспетчер пытается определить местоположение целевых пользователей в списке членов, например, сканируя кэш регионального диспетчера, содержащий информацию о пользователях. Если цели находятся в кэше регионального диспетчера, то члены группы могут регистрироваться в одном с региональным диспетчером регионе. Этот тип группового вызова помечается как «внутрирегиональный» вызов. При наличии пользователей, местоположение которых региональный диспетчер не способен определить, региональный диспетчер может запросить помощь у опорного диспетчера для определения местоположения пользователей. Вызов, связанный с группой, содержащей членов из двух или более регионов, называется «межрегиональным» вызовом.

После того как региональный диспетчер определил, является ли вызов внутрирегиональным или межрегиональным, он может начать процесс определения того, какой модуль управления полезной информацией (МУПИ) может брать на себя функции обработки вызова. Для внутрирегиональных вызовов, региональный диспетчер может назначить вызов МУПИ, расположенному в том же регионе, что и региональный диспетчер, если имеются ресурсы МУПИ, доступные в этом регионе. Результирующий вызов с использованием этого типа установления вызова называется «локально размещенный» вызов или локальный вызов. Для межрегиональных вызовов, региональный диспетчер может по выбору назначать вызов МУПИ в том же регионе или в удаленном или стороннем регионе. Региональный диспетчер может принимать это решение на основании информации местоположения пользователя для нахождения оптимального пути переноса IP-пакетов, содержащих полезную информацию и сигнализацию. Если большинство пользователей находятся в конкретном регионе, то вызов можно назначить этому региону. Если пользователи равномерно распределены по регионам, то вызов можно назначить одному из регионов, содержащих целевых пользователей. Если межрегиональный вызов назначается МУПИ в регионе, отличном от региона, в котором находится региональный диспетчер, то вызов называют «удаленно размещенным» или удаленным вызовом. Региональный диспетчер может располагать информацией о сетевой топологии и/или возможности связи между модулями МУПИ и обслуживающими их УОПД и может использовать эту информацию для принятия более обоснованного решения по назначению вызовов.

Внутрирегиональные вызовы

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

Инициирование локального вызова

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

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

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

Региональный диспетчер может использовать местоположения целевых пользователей, чтобы определить регион, в котором может быть размещен вызов. Если определено, что целевые пользователи находятся в том же регионе, что и региональный диспетчер, как показано на фиг.4, то региональный диспетчер может назначить вызов региональному МУПИ. МУПИ может разослать всей группе объявление 414 о начале вызова. Для целевых пользователей, отправка объявления может обуславливать выход их сеансов передачи пакетных данных из неактивного состояния и повторное установление их каналов трафика.

После того как клиент примет объявление о вызове от МУПИ, и канал трафика мобильной станции будет повторно установлен, клиент может отправить 416 буферизованную полезную информацию на МУПИ. МУПИ может буферизовать 418 полезную информацию, принятую от инициатора. Согласно одному варианту осуществления МУПИ может буферизовать полезную информацию прежде, чем будет достигнут или превзойден «порог ответа цели». Порог ответа цели указывает количество ответов цели, необходимое для перехода к отправке полезной информации. Порог может быть регулируемым параметром. По достижении порога, МУПИ дублирует и пересылает 420 полезную информацию целевым пользователям, ответившим 422 на объявление о вызове.

Обмен сообщениями посредством короткого пакета данных

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

Чтобы гарантировать, что система групповой связи обеспечивает «мгновенный ответ», можно отправлять короткие IP-дейтаграммы в любое время в любом направлении, т.е. исходящие с мобильного устройства или приходящие на мобильные устройства, независимо от состояния сеанса передачи пакетных данных. Согласно одному варианту осуществления IP-дейтаграммы можно отправлять в виде сообщения короткого пакета данных (SDB). В случаях, когда сеанс передачи пакетных данных находится в неактивном режиме, сообщение SDB будет передаваться по служебным каналам. При наличии возможности связи по выделенному каналу трафика, сообщение SDB передается по каналу трафика.

Согласно фиг.4 запрос 404 на установление группового вызова может быть отправлен посредством сообщения SDB. Ответ 408 на запрос на установление группового вызова от сервера приложений также может передаваться посредством сообщения SDB. Сообщения запроса на установление вызова и ответа на него, переданные посредством сообщений SDB, могут позволить системе 100 групповой связи решить задачу «мгновенного ответа».

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

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

Инициирование удаленного вызова

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

Инициирование внутрирегионального вызова на удаленном хосте аналогично сценарию установления вызова, рассмотренному в связи с фиг.4, за исключением назначения вызова МУПИ региональным диспетчером. После того как региональный диспетчер извлек местоположение членов группы, он может определить МУПИ, которому можно назначить вызов. Региональный диспетчер может принимать это решение на основании информации местоположения пользователей, нагрузки и доступности модулей МУПИ. При внутрирегиональном вызове пользователи могут находиться в одном и том же регионе, поэтому региональный диспетчер может контролировать нагрузку и доступность комплекса МУПИ в локальном регионе. Если региональный диспетчер принимает указание о том, что локальный комплекс МУПИ перегружен или временно испытывает сбои в работе, он может назначить вызов удаленному МУПИ. Согласно одному варианту осуществления модули МУПИ могут представлять собой дубликаты с идентичными функциями за исключением конфигурации вызова; поэтому удаленный МУПИ может обрабатывать вызов аналогично локальному МУПИ.

Межрегиональные вызовы

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

Инициирование локального вызова

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

Инициирование удаленного вызова

На фиг.7 показано иллюстративное установление удаленного межрегионального вызова. Инициирование межрегионального вызова на удаленном хосте аналогично сценарию установления вызова, описанного в связи с фиг.4, за исключением назначения вызова МУПИ региональным диспетчером. После того как региональный диспетчер (РД) 114 извлекает информацию местоположения членов группы, он может определить МУПИ, которому можно назначить вызов. РД 114 может принимать это решение на основании информации местоположения пользователей, нагрузки и доступности модулей МУПИ. Используя местоположения членов группы, РД пытается найти оптимальный путь переноса IP-пакетов, содержащих полезную информацию и сигнализацию, по сети поставщика услуг, для большинства членов. Если большинство пользователей находится в конкретном регионе, то вызов может быть назначен этому региону. Если пользователи равномерно распределены по регионам, то вызов может быть назначен одному из регионов, содержащих целевых пользователей.

Завершение группового вызова

Групповой вызов может окончиться по двум причинам: либо все участники запросили выход из вызова, либо все участники прекратили говорить на заранее заданный период времени, называемый «временем зависания». Каждый участник может по выбору прекратить участвовать в вызове до запланированного окончания вызова. Если все участники выходят из вызова, МУПИ может завершить вызов и освободить все назначенные ему ресурсы. Если все участники, кроме одного, выходят из вызова, МУПИ может известить об этом участника, именуемого «одиноким пользователем». Одинокий пользователь имеет возможность либо немедленно выйти из вызова, либо подождать, пока не истечет таймер времени зависания, что может инициировать сброс вызова модулем МУПИ.

МУПИ может прекратить вызов по истечении таймера времени зависания. МУПИ может отслеживать каждый отрезок разговора и устанавливать таймер по завершении отрезка разговора. Этот таймер именуется «таймером времени зависания» и может отслеживать длительность молчания, т.е. отсутствия разговора или деятельности по переносу полезной информации в процессе вызова. Если в вызове имеет место молчание на протяжении времени зависания, которое может регулироваться поставщиком услуг, то МУПИ может предположить, что участники более не заинтересованы в вызове, и поэтому закончить вызов.

Прекращение вызова, инициированное пользователем

На фиг.8 показан иллюстративный сценарий, в котором пользователь решил прекратить участие в групповом вызове. Этот сценарий указывает последовательность обмена сообщениями для прекращения участия пользователя. Когда пользователь решает 802 прекратить участие в групповом вызове, клиент может отправить 804 запрос модулю МУПИ на удаление пользователя из вызова. МУПИ может удалить 806 пользователя из вызова и уведомить 808 клиент о том, что пользователь удален 810.

Прекращение вызова, инициированное сервером

На фиг.9 показана иллюстративная последовательность обмена сообщениями, которая осуществляется, когда истекает таймер времени зависания и МУПИ прекращает групповой вызов. По истечении 902 таймера времени зависания, МУПИ может отправить 904 участникам уведомление о завершении вызова. Каждый клиент, принявший уведомление о завершении вызова, может ответить 906 посредством подтверждения приема. Приняв подтверждения приема, МУПИ может уведомить 908 РД об окончании вызова и освободить ресурсы, назначенные вызову.

Отправка извещения

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

Инициатор может выбрать 1002 одного или нескольких целевых пользователей, одну или несколько заранее заданных групп или комбинацию того и другого, и может указать извещение, подлежащее отправке. Клиент может отправить 1004 запрос региональному диспетчеру на рассылку извещения целевым пользователям, указанным в запросе. Когда РД принимает 1006 запрос, он может расширить заранее заданные группы, указанные в запросе, в списки членов с целевыми пользователями, и РД может извлечь информацию местоположения целевых пользователей. Определив местоположение, по меньшей мере, одного из целевых пользователей, РД может отправить ответ 1008 обратно клиенту. РД может назначить 1010 МУПИ запрос на извещение для рассылки сообщений 1012 извещения целевым пользователям.

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

Присоединение

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

На фиг.11 показан иллюстративный случай присоединения, в котором пользователь может выбрать вызов из списка истории вызовов. Пользователь может выбрать 1102 вызов из списка истории вызовов и нажать тангенту. Клиент может направить 1104 запрос региональному диспетчеру на инициирование группового вызова. РД может определить, что вызов уже выполняется 1106 и отправить ответ 1108 клиенту о том, что пользователь добавляется к действующему вызову. Если вызов уже выполняется, то режим передачи может не предоставляться пользователю, поскольку текущий участник вызова может уже удерживать режим передачи в то время, пока присоединяющийся пользователь готовится к приему полезной информации, т.е. сеанс передачи пакетных данных выводится из неактивного режима. РД может запросить 1110 МУПИ, в котором размещен вызов, добавить присоединяющегося пользователя к группе. МУПИ добавляет пользователя и отправляет 1112 объявление пользователю, содержащее контактную информацию МУПИ. После повторного установления канала трафика присоединяющегося пользователя, поток полезной информации в вызове можно передавать пользователю. В это время присоединяющийся пользователь может попытаться запросить привилегию на разговор.

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

Разрешение конфликтов между говорящими

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

На фиг.12 показаны иллюстративные события, которые могут произойти в процессе разрешения конфликта. Схема разрешения конфликта, используемая в этом сценарии, предусматривает прерывание обслуживания пользователя В, когда пользователь А запрашивает режим передачи. Пользователь В находится в режиме передачи, т.е. пользователь В говорит, когда пользователь А запрашивает разрешение на разговор, нажимая 1202 тангенту. Клиент может отправить 1204 сообщение на МУПИ, запрашивающее разрешение на разговор. МУПИ может осуществить разрешение конфликта между говорящими абонентами 1206 и определить, что можно прервать обслуживание пользователя В и дать возможность пользователю А перейти в режим передачи. Чтобы гарантировать перерыв в переносе полезной информации, т.е. того, что пользователь В может прекратить говорить перед передачей полезной информации пользователя А, МУПИ сначала отправляет 1208 сообщение клиенту для пользователя В, указывающее, что режим передачи перехвачен другим пользователем, после чего отправляет 1210 ответ, предоставляющий режим передачи пользователю А.

Добавление пользователей к активному групповому вызову

Система 100 групповой связи позволяет участнику группового вызова добавлять новых пользователей к действующему групповому вызову. Для этого участник вызова выбирает одного или нескольких целевых пользователей, одну или несколько заранее заданных групп или комбинацию того и другого и указывает, что участник хотел бы добавить цели к групповому вызову, в котором участник в данный момент находится. На фиг.13 показаны события, происходящие при добавлении новых целей в действующий групповой вызов. Участник вызова может выбрать 302 одного или несколько целевых пользователей, одну или несколько групп или комбинацию того и другого, подлежащие добавлению к вызову. Клиент может отправить 1304 сообщение на РД, запрашивающее добавление указанных целевых пользователей к действующему групповому вызову, которые могут быть указаны в запросе. Когда РД получает запрос, он может расширить заранее заданные группы, указанные в запросе, в списки членов с целевыми пользователями. Затем, РД может извлечь 1306 информацию местоположения целевых пользователей. Определив местоположение, по меньшей мере, одного из целевых пользователей, РД может отправить 1308 ответ клиенту, указывающий, что цели добавляются к вызову. РД может отправить 1310 запрос модулю МУПИ на добавление указанных пользователей к вызову. МУПИ может разослать 1312 объявление вызова новым целям, что может инициировать процесс вывода своих сеансов передачи пакетных данных из неактивного режима. Объявления можно рассылать по надежному расписанию, чтобы гарантировать, что цели примут сообщение. После повторного установления каналов трафика целей, цели могут отправлять 1314 подтверждения приема на МУПИ. Дополнительные цели могут быть включены 1316 в передачу полезной информации и сигнализации, которая происходит в процессе вызова.

Исключение членов из активного группового вызова

Система 100 групповой связи позволяет участнику группового вызова исключать членов из активной группы. Согласно одному варианту осуществления для этого участник вызова выбирает одного или нескольких целевых участников и указывает, что их нужно исключить из группового вызова. На фиг.14 показаны иллюстративные события, которые могут происходить при исключении участников из выполняющегося группового вызова. Участник группового вызова может выбрать 1402 одного или нескольких целевых участников, подлежащих исключению из вызова. Клиент может отправить 1404 сообщение на РД, запрашивающее исключение целей, которые могут быть указаны в этом сообщении, из группового вызова. Приняв запрос, РД может извлечь 1406 информацию местоположения целей и отправить 1408 ответ клиенту, указывающий на то, что исключение целей выполняется. РД может отправить 1410 запрос модулю МУПИ на исключение целей из вызова. МУПИ может разослать 1412 сообщения целям, которые могут быть указаны в запросе на исключение с указанием на то, что выполняется их исключение из вызова. Цели могут отправить 1414 подтверждения на МУПИ.

Отмена регистрации

Если пользователь больше не желает контактировать с сервером приложений или любым другим приложением IP, которое использует IP-адрес пользователя для контакта с пользователем, может осуществляться функция отмены регистрации. Функция отмены регистрации удаляет IP-адрес пользователя и другую контактную информацию из РСП и освобождает любые ресурсы, выделенные от имени пользователя. На фиг.15 показано, как регистрация пользователя удаляется из РСП в результате отключения питания мобильной станции, согласно одному варианту осуществления. Клиент может получить 1502 указание на то, что мобильная станция, на которой размещен этот клиент, отключается. В процессе отключения, клиент может отправить 1504 сообщение на РСП, указывающее, что информация местоположения пользователя должна быть удалена. РСП может выполнить аутентификацию 1506 запроса, чтобы удостовериться в том, что он исходит из достоверного источника. После успешной аутентификации, РСП может уведомить 1508 клиента об успешном завершении операции и уведомить 1510 РД об удалении пользователя. РД может удалить записи данных пользователя из своего кэша и может освободить ресурсы, которые могли быть выделены пользователю. В случае неудачи отмены регистрации, информация местоположения может, в конце концов, быть удалена из РСП по истечении времени, связанного с полем истечения срока.

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

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

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

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

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

Сетка может функционировать поверх существующей системы связи, не требуя существенных изменений существующей инфраструктуры. Таким образом, контроллер и пользователи в сетке могут работать в любой системе, способной передавать и принимать пакетную информацию с использованием Интернет-протокола (IP), например в системе множественного доступа с кодовым разделением каналов (МДКР, CDMA), множественного доступа с временным разделением каналов (МДВР, TDMA), Глобальной системе мобильной связи (GSM), спутниковой системе связи, например Globalstar™ или Iridium™ или в различных других системах.

Члены сетки могут осуществлять связь друг с другом с использованием назначенного устройства связи, показанного в виде устройств связи (УС, CD) 120 и 122. УС 120 и 122 могут быть устройствами проводной или беспроводной связи, например телефонами наземной беспроводной связи, телефонами проводной связи, выполненными с возможностью переключения между приемом и передачей, спутниковыми телефонами, снабженными функцией переключения между приемом и передачей, цифровыми видеокамерами с возможностью беспроводной связи, фотоаппаратами, аудиоустройствами, например магнитофонами или плеерами, портативными или настольными компьютерами, пейджерами или любой комбинацией вышеперечисленного. Например, УС 120 может содержать телефон наземной беспроводной связи, имеющий видеокамеру и дисплей. Кроме того, каждый УС может иметь возможность отправлять и принимать информацию либо в защищенном режиме, либо в незащищенном (прозрачном) режиме. В нижеследующем рассмотрении, ссылка на отдельно УС подразумевает телефон беспроводной связи с переключением между приемом и передачей. Однако следует понимать при этом, что не подразумевается, что ссылка на УС не является сама по себе ограничительной и может охватывать другие устройства связи, выполненные с возможностью передавать и принимать пакетную информацию в соответствии с Интернет-протоколом (IP).

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

Чтобы участвовать в системе 100, каждое из устройств УС 120 и 122 может быть выполнено с возможностью запрашивания привилегии на передачу у контроллера или МУПИ 116. МУПИ 116 может управлять операциями реального времени и административными операциями в отношении групп. МУПИ представляет собой любой тип компьютерного устройства, имеющего, по меньшей мере, один процессор и память. МУПИ 116 может работать удаленно через поставщика услуг системы связи, членов или всех в совокупности, в предположении о том, что полномочия предоставляются поставщиком услуг. МУПИ 116 может принимать определения групп через внешний административный интерфейс. Члены группы могут запрашивать административные действия через их поставщика услуг или функции администрирования сетки через заданные системы, например менеджер безопасности (МБ, SM), эксплуатируемый пользователем, который согласуется с административным интерфейсом МУПИ. МУПИ 116 может выполнять аутентификацию стороны, пытающейся создать или модифицировать сетку.

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

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

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

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

Когда первый член сетки желает передать информацию другим членам этой сетки, первый член сетки запрашивает привилегию на передачу, нажав тангенту своего УС, которое генерирует запрос, форматированный для передачи по распределенной сети 128. В случае УС 120 и 122, запрос может передаваться через эфир на одну или несколько базовых станций 126. Центр коммутации мобильной связи (ЦКМ, MSC) 130, который может включать в себя общеизвестный функциональный элемент межсетевого взаимодействия (ФМСВ, IWF), узел обслуживания пакетных данных (УОПД) или функциональный элемент управления передачей пакетов (ФУП, PCF) для обработки пакетов данных, может быть размещен между БС 126 и распределенной сетью 128. Запрос может передаваться через телефонную сеть общего пользования (ТСОП) на банк модемов, который может принимать запрос и предоставлять его распределенной сети 128. Терминал может отслеживать трафик системы 100 посредством своего соединения с распределенной сетью 128.

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

Согласно альтернативному варианту осуществления МУПИ 116 встроен в ЦКМ 130, так что пакеты данных от поддерживающих базовых станций направляются непосредственно на МУПИ 116 без маршрутизации по распределенной сети 128. Согласно данному варианту осуществления МУПИ 116 по-прежнему подключен к распределенной сети 128, что позволяет другим системам и устройствам связи участвовать в групповой связи. Согласно еще одному варианту осуществления МУПИ 116 может быть встроен в модули УОПД или ФУП из состава ЦКМ 130.

Согласно одному варианту осуществления МУПИ 116 поддерживает одну или более баз данных для обработки информации, относящейся к отдельным членам сетки, а также к каждой заданной сетке. Например, для каждого члена сетки, база данных может содержать такую информацию, как имя пользователя, номер лицевого счета, телефонный номер, связанный с УС члена, идентификационный номер мобильного устройства, связанный с УС, текущий статус члена в сетке, указывающий, например на то, участвует ли этот член активно в сетке, код приоритета для определения того, как назначается привилегия на передачу, телефонный номер для передачи данных, связанный с УС, IP-адрес, связанный с УС, и указание на то, с какими сетками член уполномочен осуществлять связь. Другие родственные типы информации также могут храниться в базе данных в отношении каждого члена сетки.

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

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

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

На фиг.16 показана иллюстративная группа 1600 для демонстрации того, как устройства 1602, 1604 и 1606 связи взаимодействуют с МУПИ 1608. Множество МУПИ могут быть развернуты, по желанию, для больших групп. Согласно фиг.16 УС 1602 имеет разрешение передавать полезную информацию другим членам группы. В этом случае, УС 1602 называется говорящим абонентом и передает полезную информацию по каналу. Когда УС 1602 обозначается как говорящий абонент, остальные участники, УС 1604 и УС 1604, не могут иметь разрешения передавать полезную информацию группе. Соответственно, УС 1604 и УС 1606 обозначаются как слушающие абоненты.

Согласно описанному выше УС 1602, 1604 и 1606 подключены к МУПИ 1608 с использованием, по меньшей мере, одного канала. Согласно одному варианту осуществления канал подразделяется на отдельные каналы, содержащие канал 1610 протокола инициирования сеанса (SIP), канал 1612 сигнализации полезной информации и канал 1614 трафика полезной информации. Канал 1610 SIP и канал 1612 сигнализации полезной информации могут использоваться в любой момент, когда позволяет пропускная способность, любым из УС 1602, 1604 и 1606 независимо от того, обозначено ли оно как говорящий или слушающий абонент. SIP представляет собой протокол прикладного уровня, утвержденный проблемной группой проектирования Интернета (IETF), который описывает механизмы управления для установления, модификации и прекращения мультимедийных сеансов, функционирующий поверх Интернет-протокола (IP). SIP обеспечивает общее решение проблем сигнализации вызова для приложений интернет-телефонии за счет поддержки механизмов регистрации и определения местоположения пользователей, механизмов, которые задают возможности пользователя и описывают параметры полезной информации, и механизмов определения доступности пользователей, установления вызова и обработки вызовов.

Согласно одному варианту осуществления канал 1610 SIP используется для инициирования и завершения участия УС в группе 1600. В канале 1610 SIP также может использоваться сигнал протокола описания сеанса (SDP). При конфигурировании участия УС в группе, например путем использования канала 1610 SIP, имеет место управление вызовом в режиме реального времени и сигнализация между УС и МУПИ, например путем использования канала 1612 сигнализации полезной информации УСВ. Согласно одному варианту осуществления канал 1612 сигнализации полезной информации используется для обработки запросов и переключения режима между приемом и передачей освобождениями ресурсов, разрешения конфликтов между запросами режима передачи, объявления о начале и окончании передачи информации, управления неактивным режимом сетки, отслеживания возможности соединения конечных точек, запрашивания статуса сетки и обмена информацией о статусе сетки, а также уведомления посредством любых сообщений об ошибках. Протокол канала 1612 сигнализации полезной информации минимизирует длину большинства общих сообщений и упрощает задачу интерпретации ответов и реагирования на запросы, в то же время поддерживая гибкость для дальнейших усовершенствований. Протокол канала 1612 сигнализации полезной информации также позволяет повторно отправлять запросы без неблагоприятного влияния на состояние протокола.

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

Согласно одному варианту осуществления сигнализация установления вызова и управления вызовом осуществляется согласно семантике SIP. Хотя SIP может транспортироваться с использованием либо общеизвестного протокола дейтаграмм пользователя (UDP), либо протокола управления передачей (TCP), согласно одному варианту осуществления каждое УС осуществляет функции сигнализации на основе SIP с использованием UDP. Кроме того, каждый СУС может ожидать приема запросов сигнализации SIP через UDP. Сигнализация в режиме реального времени может осуществляться посредством динамического интерфейса UDP/IP на СУС и каждом УС. Другая сигнализация может осуществляться посредством фиксированного интерфейса TCP/IP между СУС и УС, например, с использованием SIP.

Задержка перехода в режим передачи

Согласно одному варианту осуществления, когда услуга передачи пакетных данных активна, ресурсы в инфраструктуре, например приемопередающая подсистема базовой станции (ППБС, BTS), контроллер базовых станций (КБС, BSC), функциональный элемент межсетевого взаимодействия (ФМСВ) и линия радиосвязи, активным образом назначены мобильной станции (МС, MS). В услуге диспетчеризации VoIP на основе IP, в то время, как между участниками группы продолжается активный разговор, соединение передачи пакетных данных для каждого пользователя остается активным. Однако, после периода отсутствия активности, т.е. «времени зависания» в групповой связи, каналы пользовательской связи могут переходить в неактивное состояние.

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

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

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

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

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

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

Сообщения сигнализации вызова в виде коротких пакетов данных

Согласно одному варианту осуществления значительного сокращения фактического суммарного времени выхода из неактивного режима и задержки перехода в режим передачи, ощущаемой говорящим абонентом, можно добиться путем использования сообщений в виде коротких пакетов данных (SDB), предусмотренных, например, в Стандартах «TIA/EIA/IS-2000 Standarts for cdma2000 Spread Spectrum Systems», ниже именуемых «стандартом cdma2000». Согласно одному варианту осуществления сообщения SDB можно посылать как по выделенным физическим каналам, например прямому основному каналу (FCH) или прямому выделенному общему каналу управления (F-DCCH), так и по общим физическим каналам, например обратному каналу доступа (R-ACH), обратному каналу расширенного доступа (R-EACH), прямому общему каналу управления (F-CCCH) или каналу поискового вызова (PCH). Передача сообщений SDB может осуществляться в соответствии с протоколом пакетной радиосвязи (RBP), который отображает сообщения на соответствующий и доступный канал физического уровня. Поскольку сообщения SDB могут переносить произвольный IP-трафик, и их можно передавать по общим физическим каналам, сообщения SDB обеспечивают механизм обмена служебными сигналами группового вызова, когда мобильное устройство вызывающего клиента не имеет выделенных каналов трафика.

Сообщения сигнализации вызова с мобильных устройств

Согласно одному варианту осуществления сообщения сигнализации полезной информации могут переносить IP-дейтаграммы по обратной линии связи или линии связи с мобильного устройства. Клиентская мобильная станция может быстро сигнализировать МУПИ всякий раз, когда пользователь запрашивает режим передачи, и обратный выделенный канал трафика сразу не доступен. Предполагая, что клиентская мобильная станция освободила все выделенные каналы трафика, клиентская мобильная станция может немедленно направить запрос режима передачи по обратному общему каналу беспроводной инфраструктуры, которая может ретранслировать этот запрос на МУПИ. Например, либо обратный канал доступа, либо обратный канал расширенного доступа можно использовать для отправки таких сообщений, когда обратный выделенный канал недоступен. Согласно одному варианту осуществления клиентская мобильная станция может передавать сообщение запроса режима передачи на МУПИ в качестве сообщения SDB.

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

Затем, клиентская МС может начать повторное установление своего выделенного канала трафика, например, осуществляя «реорганизацию опции 33 обслуживания». Клиентская МС также может начать синхронизацию протокола линии радиосвязи (RLP). Согласно одному варианту осуществления клиентская МС может повторно установить свой выделенный канал трафика и синхронизировать RLP одновременно с отправкой запроса 404 режима передачи, что является преимуществом.

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

Согласно фиг.4 инфраструктура беспроводной связи может отправить запрос 404 режима передачи на узел обслуживания пакетных данных (УОПД), а затем на МУПИ. Согласно одному варианту осуществления, приняв запрос режима передачи, МУПИ может выполнить арбитраж этого запроса, отправить сообщения активации сигнализации полезной информации (запускающие сигналы) группе целевых участников (слушающих абонентов), и/или запустить повторное установление каналов трафика 414 участников (слушающих абонентов). Если МУПИ удовлетворяет запрос режима передачи, то МУПИ может отправить предоставление 408 режима передачи на клиентскую МС. Согласно одному варианту осуществления РД может отправить предоставление 408 режима передачи на клиентскую МС по доступному прямому общему каналу, например прямому каналу поискового вызова и прямому общему каналу управления, если выделенный канал трафика клиента еще не установлен. Согласно одному варианту осуществления инфраструктура может отправить предоставление 408 режима передачи на клиентскую МС в виде SDB независимо от того, какой канал используется.

Согласно одному варианту осуществления МУПИ может ожидать истечения таймера ответа неактивного режима прежде, чем ответить на запрос режима передачи. Если таймер ответа неактивного режима группы установлен на нуль, СУС может немедленно ответить на запрос режима передачи. Согласно одному варианту осуществления, если клиентская МС завершила повторное установление своего канала трафика и синхронизацию RLP, клиентская МС может последовательно передавать МУПИ полезную информацию 416, которая могла быть буферизована 412 на клиентской МС.

Сообщения сигнализации вызова от сети

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

Согласно фиг.4, приняв запрос режима передачи, МУПИ может отправить запускающие сигналы 414 активации, адресованные целевым пользователям. МУПИ может определить, существует ли сеанс передачи пакетных данных для целевого мобильного устройства, и отправляет запускающий пакет на соответствующий элемент инфраструктуры, например базовую станцию. Инфраструктура может выполнить поисковый вызов в отношении каждой отдельной целевой МС, чтобы начать повторное установление ее выделенного канала трафика. Затем целевая МС может начать повторное установление своего выделенного канала трафика, например, осуществляя «реорганизацию опции 33 обслуживания». Целевая МС может также начать синхронизацию протокола линии радиосвязи (RLP). Согласно одному варианту осуществления целевые МС могут повторно устанавливать свои выделенные каналы трафика и синхронизировать свои RLP параллельно с теми же функциями, осуществляемыми клиентской МС, что является преимуществом.

Согласно одному варианту осуществления, завершив повторное установление своего выделенного канала трафика и синхронизацию своего RLP, целевая МС может отправить ответ 422 на сигнал активации на МУПИ, указывающий на то, что целевая МС готова к приему полезной информации. МУПИ может отправить объявление говорящего абонента на клиентскую МС перед потоковой передачей полезной информации 420, которая могла быть буферизована на МУПИ, на целевую МС.

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

Сетевые интерфейсы для сообщений сигнализации вызова

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

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

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

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

Инициированные мобильным устройством инициирование услуги и поисковый вызов

Согласно одному варианту осуществления клиент может отправить запрос 404 режима передачи, который может иметь вид SDB, за которым сразу же следует запрос на инициирование услуги, адресованный инфраструктуре беспроводной связи, например МДКР, для быстрого повторного установления его каналов трафика. Однако, если таймер ответа неактивного режима установлен на малое значение, то РД может быстро ответить на запрос режима передачи и передать ответ 408 обратно клиенту. Если этот ответ поступает в инфраструктуру в течение ранних фаз транзакции инициирования услуги, то инфраструктура отмечает, что МС говорящего абонента не имеет активного канала трафика и может попытаться ответить МС говорящего абонента по каналу поискового вызова. Однако это действие по выполнению поискового вызова может прервать уже действующую транзакцию инициирования услуги. Согласно одному варианту осуществления МС говорящего абонента может ответить на сообщение, переданное по каналу поискового вызова, гарантируя тем самым, что ответное сообщение на запрос режима передачи доставлено говорящему абоненту, и снова запросить инициирование услуги, но, вследствие прерванной первоначальной попытки инициирования услуги, возникает нежелательная задержка в повторном установлении канала трафика говорящего абонента.

Согласно первому варианту осуществления во избежание состязания между процессом инициирования услуги и поисковым вызовом, РД может быть настроен так, чтобы не отвечать сразу на запрос 404 режима передачи. Соответственно, таймер ответа неактивного режима можно отрегулировать так, чтобы МУПИ передавал ответ 408 на МС говорящего абонента по завершении процесса инициирования услуги.

Согласно второму варианту осуществления УОПД, принимающий ответ 408, и центр коммутации мобильной связи (ЦКМ), отвечающий на запрос говорящего абонента на инициирование услуги, координируют свои действия. Это значит, что, если УОПД определяет, что процесс инициирования услуги передачи пакетных данных для МС говорящего абонента уже идет, когда ответ 408 поступает в инфраструктуру, ЦКМ может задерживать выполнение поискового вызова в отношении МС говорящего абонента. УОПД может кэшировать ответ и отправить его по прямому каналу трафика мобильного устройства говорящего абонента после завершения процесса инициирования услуги. Альтернативно, ЦКМ может отправить ответ на МС говорящего абонента в виде сообщения SDB, если процесс создания услуги все еще идет.

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

Кэширование запускающих сигналов передачи пакетных данных, инициированных сетью

Дейтаграмма IP, включающая в себя запускающий сигнал 414 активации, которая поступает в инфраструктуру беспроводной связи, например МДКР, и адресована мобильному устройству слушающего абонента, не имеющему выделенных каналов трафика, может быть потеряна либо сетью, в целом, либо инфраструктурой беспроводной связи, в частности. Согласно одному варианту осуществления запускающий сигнал 414 активации, отправленный на мобильное устройство слушающего абонента, повторно передается в настойчивой манере по заданному расписанию до тех пор, пока слушающие абоненты не ответят, или не истечет таймер активации группы. Например, запускающий сигнал 414 активации можно повторно передавать каждые 500 мс. Однако повторная передача запускающих сигналов 414 активации с такой периодичностью может привести к максимальной задержке до 500 мс или средней задержке 250 мс, с момента повторного установления канала трафика слушающего абонента до момента, когда следующий запускающий сигнал активации, адресованный этому слушающему абоненту, поступает в инфраструктуру.

Согласно одному варианту осуществления инфраструктура или другая сущность в сети может кэшировать запускающий сигнал 414 активации, отправленный модулем МУПИ, и доставлять его на целевую МС, как только целевая МС повторно установит свой канал трафика. Это избавляет от необходимости в повторной передаче запроса на активацию модулем МУПИ и сокращает суммарное время выхода из неактивного режима. Кэширование запускающего сигнала 414 активации, в отличие от повторной передачи его с периодичностью, например, 500 мс, может устранить задержку, составляющую до 500 мс, из суммарного времени выхода из неактивного режима.

Буферизация полезной информации

Согласно одному варианту осуществления пользователь может иметь возможность начать говорить после того, как он запросил режим передачи, благодаря буферизации полезной информации до повторного установления выделенных каналов между клиентом и слушающими абонентами. За счет буферизации речи говорящего абонента, система позволяет говорящему абоненту начать говорить до того, как каналы трафика слушающих абонентов будут полностью повторно установлены. Это позволяет говорящему абоненту начать говорить раньше, уменьшая его воспринимаемую задержку перехода в режим передачи. Поскольку слушающие абоненты не испытывают задержку перехода в режим передачи, на них это не влияет, т.е. задержка перехода в режим передачи смещается от говорящего абонента к другим частям системы. Говорящему абоненту просто придется ожидать до приема слушающего абонента на свой первый отрезок разговора, но, как отмечено выше, он уже готов к тому, что ответ на его первый отрезок разговора придется ждать дольше, чем ответы на следующие отрезки разговора, когда он войдет в активные переговоры. Буферизация первого отрезка разговора говорящего абонента может осуществляться на стороне МУПИ или на стороне клиентской МС.

Буферизация на стороне МУПИ

Согласно одному варианту осуществления МУПИ может буферизовать первый отрезок разговора говорящего абонента. После того как пользователь нажал на тангенту и каналы трафика пользователя повторно установились, он получает возможность осуществлять связь с МУПИ. В это время, поскольку каналы трафика слушающих абонентов еще не установлены, МУПИ 418 буферизует речь говорящего абонента для последующей передачи целевым слушающим абонентом. Буферизация МУПИ может уменьшить воспринимаемую задержку перехода в режим передачи, которую говорящий абонент ощущает, приблизительно до времени, которое необходимо для активации канала трафика говорящего абонента. На фиг.17 показана описанная ниже буферизация на стороне МУПИ согласно одному варианту осуществления:

(1) Нет выполняющихся вызовов, каналы трафика инициатора и цели находятся в неактивном режиме.

(2) Пользователь нажимает тангенту. Сервер принимает от клиента запрос «установить групповой вызов».

(3) Пользователю предоставляется режим передачи после того, как клиент принимает от сервера ответ «установление выполняется» или после регулируемой задержки (1 секунда) и начинает буферизовать полезную информацию пользователя.

(4) Сервер начинает процесс повторного установления каналов трафика пакетных данных целей.

(5) Сервер отправляет клиенту сообщение «объявление группового вызова» в виде SDB.

(6) Клиент успешно повторно устанавливает канал трафика, начинает передавать буферизованную полезную информацию на сервер.

(7) Клиент осуществляет потоковую передачу полезной информации на сервер.

(8) Каналы трафика целей повторно установлены (достигнут «порог ответа цели»).

(9) Пользователь отпускает тангенту. Клиент прекращает буферизацию полезной информации.

(10) Клиент прекращает потоковую передачу буферизованной полезной информации на сервер, запрашивает у сервера выход из режима передачи.

(11) Сервер отправляет клиенту подтверждение выхода из режима передачи.

Буферизация на стороне клиента

Согласно одному варианту осуществления когда нужна более короткая воспринимаемая задержка, говорящий абонент получает возможность говорить даже до повторного установления его канала трафика. Поскольку клиентская МС еще не осуществляет связь с МУПИ, сигнал говорящему абоненту начать говорить подает клиентская МС. Если говорящему абоненту разрешено говорить до повторного установления канала трафика говорящего абонента, то клиентская МС может буферизовать 412 речь. Поскольку связь с СУС еще не установлена, разрешение на разговор дается «оптимистическим образом». На фиг.18 показана описанная ниже буферизация на стороне клиента согласно одному варианту осуществления:

(1) Нет выполняющихся вызовов, канал трафика инициатора находится в неактивном режиме.

(2) Пользователь нажимает тангенту. Клиент отправляет на сервер запрос «установить групповой вызов» в виде SDB.

(3) Клиент начинает процесс повторного установления канала трафика пакетных данных.

(4) Пользователю предоставляется режим передачи после того, как клиент принимает от сервера ответ «установление выполняется» или после регулируемой задержки (1 секунда) и начинает буферизовать полезную информацию пользователя.

(5) Клиент принимает от сервера сообщение «объявление группового вызова» в виде SDB.

(6) Клиент успешно повторно устанавливает канал трафика

(7) Клиент осуществляет потоковую передачу буферизованной полезной информации на сервер.

(8) Пользователь отпускает тангенту. Клиент прекращает буферизацию полезной информации.

(9) Клиент прекращает потоковую передачу буферизованной полезной информации на сервер, запрашивает у сервера выход из режима передачи.

(10) Клиент принимает от сервера подтверждение выхода из режима передачи.

Согласно одному варианту осуществления, как буферизация 418 на стороне МУПИ, так и буферизация 412 на стороне клиента могут осуществляться одновременно. Буферизация на стороне клиента может позволять уменьшать воспринимаемую задержку перехода в режим передачи. Согласно одному варианту осуществления клиентская МС может буферизовать полезную информацию, чтобы управлять воспринимаемой задержкой перехода в режим передачи, испытываемой пользователем. Сочетание SDB с мобильного устройства и буферизации полезной информации на стороне клиента может уменьшать задержки, связанные с повторным установлением активных каналов трафика.

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

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

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

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

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

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

принимают запрос на добавление списка членов к активному групповому вызову,

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

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

принимают подтверждение от члена в списке членов, который желает участвовать в групповом вызове, и

пересылают этому члену полезную информацию.

средство для приема запроса на добавление списка членов к активному групповому вызову,

средство для добавления списка членов к активному групповому вызову,

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

средство для приема подтверждения от члена в списке членов, который желает участвовать в групповом вызове, и

средство для пересылки этому члену полезной информации.

приемник,

передатчик и

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

приема запроса на добавление списка членов к активному групповому вызову,

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

приема подтверждения от члена, который желает участвовать в групповом вызове, и

пересылки этому члену полезной информации.

диспетчер, который принимает запрос на добавление нового члена к активному групповому вызову на основании списка членов,

при этом диспетчер определяет информацию местоположения для каждого члена в списке членов, и

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