Способ и устройство для управления разрешением на передачу в службе "push-to"

Изобретение относится к услугам быстрой связи (Push-to), далее, РТ-услуга, например, (push to talk - «нажмите и говорите»). Техническим результатом является обеспечение способа и устройства для управления состоянием РТ-сервера для эффективного управления пакетами данных мультимедиа. Указанный технический результат достигается тем, что предложен способ управления состоянием РТ-сервера, включающий в себя переход РТ-сервером, находящимся во «втором» состоянии, в «первое» состояние, когда РТ-сервером принято сообщение об освобождении пакета данных, и дальнейшее пребывание РТ-сервера в этом «первом» состоянии, если РТ-сервер, находящийся в первом состоянии, принимает от РТ-клиента пакет данных мультимедиа и если в предшествующем состоянии РТ-сервер принял сообщение об освобождении пакета данных мультимедиа. 5 н. и 7 з.п. ф-лы, 5 ил.

 

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

Техническое решение

[1] Данная заявка на патент заявляет преимущество приоритета предварительной заявки на патент США №60/852,412, зарегистрированной 18 октября 2005 года, и заявки на патент Республики Корея №10-2007-0062429, зарегистрированной 25 июня 2007 года в Республике Корея. Полный текст указанных заявок включен в данное описание в виде ссылок.

[2] Это изобретение относится к услугам быстрой связи (Push-to), далее РТ-услуга [например, (push to talk - «нажмите и говорите»), (push to view - «нажмите и смотрите») или (push to data - «нажмите и передавайте данные»], и более конкретно к способу и устройству управления разрешением на передачу (выход в эфир), (полномочиями на передачу речевых пакетов или данных мультимедиа, разрешением на передачу данных мультимедиа и т.д.) в рамках РТ-услуги.

[3] РТ-услуга представляет собой разновидность многоточечной полудуплексной связи, такой как РТТ-услуга (push to talk - «нажмите и говорите»), предназначенной для передачи речевых (звуковых) данных, PTV-услуга (push to view - «нажмите и смотрите»), предназначенной для передачи движущегося изображения (видеоданных), или PTD-услуга (push to data - «нажмите и передавайте данные»), предназначенной для передачи данных. Среди клиентов, участвующих в сеансе связи, установленном через сервер в рамках РТ-услуги, один из клиентов имеет полномочия на передачу речевых пакетов (или имеющий полномочия на передачу данных мультимедиа, или разрешение на передачу), или разрешение на передачу данных мультимедиа, передает данные мультимедиа (например, речевые пакеты или пакеты данных мультимедиа), включая аудио- или видеоинформацию, а затем остальные клиенты, участвующие в сеансе связи, принимают переданные данные мультимедиа.

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

[5] РТ-услуга в соответствии с известным уровнем техники включает в себя: выбор конкретным клиентом одного или нескольких клиентов и приглашение их к участию в РТ-сеансе, установление сеанса связи между приглашающим клиентом (вызывающим клиентом) и приглашенными клиентами (вызываемыми клиентами), а также передачу/прием голосовых (аудио) и/или других данных между клиентами, участвующими в установленном между ними сеансе связи.

[6] В РТ-услуге, перед тем как пользователь передает данные мультимедиа, например аудио, видео или прочие данные через свой РТ-терминал (терминал, поддерживающий РТ-услугу), пользователь должен запросить разрешение на передачу данных мультимедиа (или полномочия на речевые пакеты или полномочия на пакеты данных мультимедиа, или разрешение на передачу, которые далее по тексту именуются «полномочия на пакеты данных мультимедиа») от сервера, поддерживающего РТ-услугу, далее РТ-сервер (например, РоС-сервер (Push-To-Talk Over Cellular = многоточечная полудуплексная связь в сети подвижной радиотелефонной связи). Пользователь может передавать данные мультимедиа после получения от РТ-сервера полномочий на пакеты данных мультимедиа. В этом случае управление полномочиями пользовательского терминала на данные мультимедиа именуется как «управление речевыми пакетами» (или «управление пакетами данных мультимедиа»). В дополнение к этому, относительно управления пакетами данных мультимедиа следует отметить, что полномочия на данные мультимедиа, обладая которыми конкретный пользователь может передавать данные мультимедиа по каналу связи, могут быть ограничены, такая функция именуется «отмена речевых пакетов» (Talk Burst Revoke).

[7] На Фиг.1 представлена схема изменения состояний (машина состояний) РТ-сервера (с позиции РТ-сервера) для прохождения пакета данных к РТ-клиенту в соответствии с известным уровнем техники. На Фиг.1 показано каждое состояние РТ-сервера для режима передачи пакета данных мультимедиа (или речевого пакета) к РТ-клиенту (т.е. терминалу). Состояния, показанные на Фиг.1 в овалах, могут быть подразделены на стабильные состояния и переходные состояния, в зависимости от характеристики каждого состояния. События показаны на Фиг.1 в прямоугольниках.

[8] Относящиеся к заявке состояния, показанные на Фиг.1, рассмотрены ниже.

[9] (а) - состояние «Start-stop» (Старт/стоп) означает состояние, в котором отсутствует сеанс связи по протоколу SIP (Session Initiation Protocol = протокол установления сеанса связи) между РТ-сервером и связанным с ним РТ-клиентом. Далее по тексту данное состояние «Start-stop» будет именоваться «нулевым» состоянием «0 (zero) state»;

[10] (b) - состояние «U: not permitted and MB_Idle» («Пользование: не разрешено и МВ_Ожидание») является стабильным состоянием и означает состояние, в котором РТ-сервер может получить запрос о полномочиях на речевой пакет (пакет мультимедиа - MB пакет) от РТ-клиента. Другими словами, это состояние, в котором РТ-клиент может направить РТ-серверу запрос на передачу речевого пакета (пакета мультимедиа), именуемый как «MB_Request» («MB_Запрос»), с целью передачи пакета данных мультимедиа. Далее по тексту состояние 'U: not permitted and MB Idle' именуется как «первое состояние» («first state»);

[11] (с) - состояние «U: permitted» («Пользование: разрешено») является стабильным состоянием и означает состояние, в котором РТ-сервер дал разрешение на передачу пакета данных мультимедиа связанному с ним РТ-клиенту, при этом связанный с ним РТ-клиент может передать пакет данных мультимедиа РТ-серверу. Далее по тексту состояние 'U: permitted' («Пользователь: разрешено») именуется как «второе состояние» («second state»). В этом состоянии РТ-сервер приводит в действие (запускает) таймер Т1 (т.е. таймер окончания передачи данных мультимедиа по протоколу реального времени [End of RTP (Real Time Protocol) media timer] и таймер Т2, т.е. таймер времени прекращения разговора («Stop talking timer»). Описание этих таймеров будет дано ниже;

[12] (d) - состояние «U: not permitted but sends media» («Пользование: не разрешено, но данные мультимедиа передаются») является переходным состоянием, и оно означает состояние, в котором РТ-сервер принимает данные мультимедиа (или пакеты данных мультимедиа по протоколу RTP) от РТ-клиента, не имеющего полномочий на передачу речевых пакетов. Далее по тексту указанное состояние «U: not permitted gut sends media» именуется как «третье состояние» («third state»). В этом состоянии РТ-сервер приводит в действие/запускает таймер Т8 (т.е. таймер отмены передачи пакета мультимедиа);

[13] (е) - состояние «U: pending MB_Revoke» («Пользование: задержка МВ_Отменить») является переходным состоянием, и РТ-сервер использует данное состояние в течение льготного периода времени после передачи сообщения об отмене передачи пакета данных мультимедиа протокола управления пакетами данных мультимедиа МВСР (Media Burst Control Protocol). Далее по тексту данное состояние «U: pending MB_Revoke» именуется как «четвертое состояние» («fourth state»). В этом состоянии РТ-сервер приводит в действие/запускает таймер Т3 (т.е. таймер начала отсчета льготного периода времени для разговоров), а период, в течение которого таймер Т3 работает, соответствует льготному периоду времени;

[14] (f) - состояние «U: waiting MB_Revoke» («Пользование: ожидание МВ_Отменить») является стабильным состоянием и означает состояние, в котором РТ-сервер не дает разрешения на передачу данных мультимедиа, запрошенного связанным с ним РТ-клиентом, в течение определенного периода времени, в продолжении которого действует/работает таймер Т9. В случае, когда связанный с ним РТ-клиент продолжает передачу пакетов данных мультимедиа вне пределов времени действия разрешения на передачу пакетов мультимедиа (то есть период времени, в течение которого работает таймер Т2, и до истечения этого периода), РТ-сервер штрафует связанного с ним РТ-клиента. В этом состоянии РТ-сервер приводит в действие/запускает таймер Т9 (т.е. «перезапускаемый после» таймер). Далее по тексту данное состояние «U: waiting MB_Revoke» именуется как «пятое» состояние («a fifth state»);

[15] (g) - состояние «U: not permitted and MB_Taken» («Пользование: не разрешено и МВ_Принят») является стабильным состоянием и означает состояние, в котором, если другой РТ-клиент (т.е. не связанный с ним РТ-клиент), не являющийся РТ-клиентом, связанным с этим сервером, которому было разрешено передавать пакет данных мультимедиа, запрашивает разрешение на передачу пакетов данных мультимедиа, РТ-сервер информирует этого другого РТ-клиента, что разрешение на передачу пакетов данных мультимедиа дано. Далее по тексту данное состояние «U: not permitted and MB_Taken» именуется как «шестое» состояние («a sixth state»).

[16] Таймеры T1, Т2, Т3, Т8 и Т9, упомянутые в вышеприведенном описании фигуры 1, используются для ограничения или управления передачей пакетов данных мультимедиа (MB) между РТ-сервером и связанным(и) с ним РТ-клиентом (клиентами). Далее по тексту приводится описание работы этих таймеров. Обычно, передача данных мультимедиа осуществляется в виде пакетов протокола реального времени (RTP=Real Time Protocol), далее протокол RTF.

[17] Таймер Т1 (таймер «Окончание передачи данных мультимедиа по протоколу RTP»)

[18] Таймер 1 предназначен, чтобы отсчитывать, получил ли РТ-сервер поступающий пакет данных по протоколу RTP в пределах доступного периода времени, имеющегося после получения предыдущего пакета по протоколу RTP. Таймер Т1 обычно устанавливается на период в 4 секунды, что является значением «по умолчанию». После того как терминал посылает РТ-серверу данные мультимедиа, например пакеты данных мультимедиа по протоколу RTP, по получении РТ-сервером первого пакета данных по протоколу RTP, таймер Т1 запускается, и его запуск осуществляется вновь с поступлением последующего пакета данных по протоколу RTP. При приеме РТ-сервером последнего пакета данных по протоколу RTP таймер Т1 останавливается, или истекает время его работы.

[19] Таймер Т2 (таймер «Времени до прекращения разговора»)

[20] Таймер Т2 предназначен, чтобы отсчитывать разрешенный (выделенный) период времени, в течение которого терминал, имеющий разрешение на передачу пакетов данных мультимедиа (разрешение на передачу или полномочия на речевые пакеты), может передавать данные мультимедиа. Когда терминал передает первый пакет данных по протоколу RTP, РТ-сервер запускает таймер Т2. Обычно таймер Т2 «по умолчанию» устанавливается на 30 секунд.

[21] Таймер Т3 (таймер «Льготное время до прекращения разговора»

[22] Таймер Т3 предназначен, чтобы отсчитывать льготный период времени, в течение которого РТ-сервер может дополнительно принимать данные мультимедиа даже после того, как истекает время работы таймера Т2. При этом льготный период времени относится к предельно допустимому превышению времени, в течение которого РТ-сервер может принимать данные мультимедиа даже по истечении времени работы таймера Т2. То есть, даже тогда, когда терминал, имеющий разрешение на передачу пакетов данных мультимедиа, передал данные мультимедиа по истечению периода времени, в течение которого терминалу было разрешено передавать данные мультимедиа, РТ-сервер разрешает прием данных мультимедиа от терминала в течение заданного таймеру Т3 периода времени, то есть до истечения времени работы таймера Т3.

[23] Таймер Т9 (таймер, «перезапускаемый после»)

[24] Таймер Т9 предназначен, чтобы рассчитывать начисленное терминалу штрафное время, когда он передает данные мультимедиа вне пределов разрешенного периода времени, т.е. штрафное время, в течение которого терминал не может иметь разрешение на запрос полномочий на передачу пакетов данных мультимедиа у РТ-сервера. Когда терминал передает данные мультимедиа вне пределов (после) значения (периода времени), установленного на таймере Т2 (то есть после разрешенного для передачи данных мультимедиа периода времени), РТ-сервер посылает терминалу сообщение «МВСР Revoke» (Отменить - протокол управления передачей пакетов данных мультимедиа) или «ТВСР Revoke» (Отменить - протокол управления передачей пользовательской информации), а затем запускает таймер Т3. В случае, если РТ-сервер не может принять от терминала сообщение «МВСР Release» (Протокол управления передачей пакетов данных мультимедиа - Освободить) или «ТВСР Release» (Протокол управления передачей пользовательской информации - Освободить) в течение установленного на таймере Т3 периода времени, сервер запускает таймер Т9 так, что терминал не получает разрешение на запрос полномочий на передачу пакетов данных мультимедиа и передает данные мультимедиа в течение определенного периода времени, соответствующего установленному таймером Т9 значению времени (то есть в течение времени работы таймера Т9).

[25] Таймер Т8 (таймер «Отмена передачи речевых пакетов»)

[26] Таймер Т8 запускается во время передачи РТ-сервером сообщения «MB_Revoke» («МВ_Отменить»). Если терминал не передал сообщение «MB_Release» («МВ_Освободить») в пределах значения (то есть периода времени), установленного на таймере Т8, РТ-сервер перезапускает таймер Т8, чтобы ожидать приема сообщения «MB_Release», переданного терминалом.

[27] На Фиг.3 приведена блок схема прохождения сигналов, иллюстрирующая получение разрешения на передачу пакета данных мультимедиа и передачу данных мультимедиа между РТ-сервером и терминалами в соответствии с известным уровнем техники.

[28] Далее приводится описание со ссылкой на Фиг.1 и 2. Здесь на фигуре 1 предполагается, что сеанс связи по протоколу SIP (протокол установления сеанса связи) был инициирован при «нулевом» состоянии РТ-сервера, а затем РТ-сервер был переведен (переключен) в «первое» состояние путем передачи сообщения «MB_Idle» («МВ_Ожидание») каждому терминалу (устройству РТ-клиента). То есть РТ-сервер находится в состоянии, в котором каждый терминал может запросить от РТ-сервера разрешение (т.е. полномочия на передачу пакетов данных мультимедиа) на передачу пакета данных мультимедиа.

[29] Каждый из терминалов А, В и С направляет РТ-серверу сообщение с запросом на передачу (выход в эфир), получение полномочий на пакеты мультимедиа или речевые пакеты, или на получение разрешения на передачу пакета данных мультимедиа (т.е. сообщение «MB_Request» («МВ_Запрос») (шаг S1). Если РТ-сервер принимает решение выдать терминалу А разрешение на передачу пакета данных мультимедиа, РТ-сервер посылает сообщение с разрешением «MB_Granted» («МВ_Разрешен») в ответ на указанное сообщение с запросом «MB_Request». Одновременно РТ-сервер направляет терминалам В и С (шаг S2) сообщение, указывающее, что терминал А принял разрешение на передачу пакета данных мультимедиа (то есть сообщение «MB_Taken» («МВ_Принят»)). В ходе выполнения шагов S1 и S2 режим работы РТ-сервера может переходить из «первого» состояния во «второе» состояние (то есть состояние «U: permitted»/«Пользование: разрешено»), как показано на Фиг.1. Следовательно, терминал А может теперь передавать данные мультимедиа (то есть пакеты данных мультимедиа по протоколу RTP) РТ-серверу в течение периода времени, установленного на таймере Т2 (то есть в период работы таймера Т2). Кроме того, поскольку в ходе выполнения шагов S1 и S2 терминалы В и С получили сообщение «MB_Taken», рабочее состояние РТ-сервера относительно терминалов В и С соответствует «шестому» состоянию («U: not permitted and MB_Taken»), как показано на Фиг.1.

[30] Так как состояние РТ-сервера относительно терминала А на Фиг.1 соответствует «второму» состоянию (то есть «U: permitted»/«Пользование: разрешено»), терминал А может передавать данные мультимедиа (или пакеты данных мультимедиа протокола RTP) РТ-серверу (шаг S3). В этом случае при приеме от терминала А первого пакета данных мультимедиа по протоколу RTP РТ-сервер может одновременно запустить таймер Т1 и таймер Т2.

[31] Если терминал А передает сообщение для освобождения разрешения на передачу пакета данных мультимедиа (то есть сообщение «MB_Release»), в пределах периода времени, в течение которого разрешено передавать данные мультимедиа (то есть в течение значения (периода времени), установленного на таймере Т2) состояние РТ-сервера относительно терминала А может быть изменено из «второго» состояния на «первое» состояние, как показано на фигуре 1. Кроме того, РТ-сервер может остановить работу таймера Т2 (то есть таймер Т2 может быть остановлен до истечения времени его действия). Однако, если период времени, в течение которого терминалу А разрешено передавать данные мультимедиа (то есть значение (период времени), установленное таймером Т2) истекает, РТ-сервер посылает терминалу А сообщение об отмене разрешения на передачу данных мультимедиа (то есть сообщение «МВ_Rеvоkе»/«МВ_Отменить»).

[32] В общем случае сообщения и данные мультимедиа (или пакеты данных мультимедиа протокола RTP) могут быть переданы из терминала по различным путям маршрутизации в сети в соответствии с физической средой передачи данных. Однако такая физическая среда передачи данных может содержать транзитные задержки при приеме сообщений и данных мультимедиа по различным путям маршрутизации в сети. В дополнение к этому, такая ситуация может непреднамеренно превратить текущее состояние РТ-сервера относительно терминала в «третье» состояние (например, состояние «U: permitted but sends media»), как показано на диаграмме машины состояний на Фиг.1.

[33] Например, когда РТ-сервер находится во «втором» состоянии, а затем получает от терминала сообщение об освобождении «MB_Release», РТ-сервер переходит из «второго» состояния в «первое» состояние. Если РТ-сервер принимает затем данные мультимедиа (пакет по протоколу RTP), направленные терминалом раньше, чем было передано сообщение «MB_Release», но прибывшие на РТ-сервер позже этого сообщения из-за задержки на пути маршрутизации, то РТ-сервер переходит из «первого» состояния в «третье» состояние, как показано на Фиг.1. Однако «третье» состояние не требуется для данного момента, потому что терминал не может запросить разрешение на передачу пакета данных мультимедиа от РТ-сервера, находящегося в «третьем» состоянии, и РТ-серверу необходимо вернуться в «первое» состояние для того чтобы терминал смог послать запрос на передачу пакета данных мультимедиа. Далее, РТ-сервер может быть не способен вернуться в «первое» состояние в данный момент времени потому, что для того чтобы так сделать, РТ-серверу необходимо получить другое сообщение «MB_Release», что маловероятно для данного момента времени. В результате, терминал, в соответствии с диаграммой машины состояний известного уровня техники на Фиг.1, может быть вынужден оставаться в непредусмотренном состоянии (например, «третьем» состоянии), в котором он не может запрашивать разрешения на передачу пакета данных мультимедиа от РТ-сервера, что является проблемой.

[34] Например, при последовательной передаче терминалом пакетов данных мультимедиа протокола RTP и сообщения «MB_Release», сообщение «MB_Release» может достичь РТ-сервер раньше, чем пакеты данных мультимедиа по протоколу RTP, и наоборот. В этом случае РТ-сервер может принять часть пакетов данных мультимедиа по протоколу RTP (например, последний или другой пакет данных мультимедиа по протоколу RTP из переданных терминалом пакетов данных мультимедиа по протоколу RTP) по определенным путям маршрутизации в сети после приема сообщения «MB_Release» по другим путям маршрутизации в сети. В это время, поскольку РТ-сервер уже принял сообщение «MB_Release», состояние РТ-сервера относительно терминала, на диаграмме состояний на Фиг.1, переводится из «второго» состояния (то есть «U: permitted»/«Пользование: разрешено») в «первое» состояние (то есть «U: not permitted and МВ_Idle»/«Пользование: не разрешено и МВ_Ожидание»). После этого, даже если РТ-сервер получил последний пакет данных мультимедиа по протоколу RTP, он не может распознать, что полученный последним пакет данных мультимедиа по протоколу RTP был передан раньше, чем уже принятое сообщение «MB_Release». Соответственно, РТ-сервер определяет, что терминал, не имеющий разрешения на передачу пакета данных мультимедиа, передал данные мультимедиа (то есть принятый последним пакет данных мультимедиа по протоколу RTP). Поэтому РТ-сервер отвергает принятый последним пакет данных мультимедиа по протоколу RTP, а затем посылает терминалу сообщение об отмене «MB_Revoke» (указывая, что разрешение на передачу пакета данных мультимедиа, выданное терминалу, было отозвано), то есть это соответствует ситуации 1 (Situation 1) на Фиг.1. То есть на диаграмме состояний на Фиг.1 в соответствии с известным уровнем техники, состояние РТ-сервера относительно терминала изменено с «первого» состояния (то есть «U: not permitted and МВ_Idle»/«Пользование: не разрешено и МВ_Ожидание») на «третье» состояние (то есть «U: not permitted but sends media»/«Пользование: не разрешено, но данные мультимедиа передаются»). В условиях «третьего» состояния на Фиг.1 РТ-сервер передает терминалу сообщение «МВ_Rеvоkе»/«МВ_Отменить» и одновременно приводит в действие таймер Т8 (то есть это соответствует ситуации 2 «Situation 2» на Фиг.1). Однако ситуация 2 (Situation 2) повторяется до тех пор, пока РТ-сервер не получит от терминала сообщения «MB_Release», и состояние РТ-сервера относительно терминала может оставаться «третьим» состоянием на диаграмме машины состояний на Фиг.1. С позиции терминала, если ситуация 2 (Situation 2) повторяется, терминал может оказаться в неблагоприятной ситуации, так как он не сможет запрашивать полномочий на пакет данных мультимедиа (разрешения на передачу пакета данных мультимедиа) у РТ-сервера, несмотря на предварительную отправку сообщения «MB_Release». Это проблема, которая может возникнуть из-за различий путей маршрутизации в сети, по которым сообщения передаются терминалом.

[35] В дополнение к этому, поскольку для передачи сообщений терминалом используются различные пути маршрутизации в сети, терминал в результате может непреднамеренно достичь «пятого» состояния (то есть «U: waiting MB_Revoke»/«Пользование: ожидание МВ_Отменить») на диаграмме состояний на Фиг.1. То есть после получения разрешения на передачу пакета данных мультимедиа терминал (или РТ-клиент) может передавать данные мультимедиа (то есть последовательность пакетов данных мультимедиа протокола RTP) РТ-серверу в течение разрешенного периода времени передачи данных мультимедиа (то есть периода времени, соответствующего установленному таймером Т2 значению). В некоторых случаях переданные терминалом последовательности пакетов данных мультимедиа по протоколу RTP имеют порядковые номера. Кроме того, информация о порядковом номере последнего пакета данных мультимедиа по протоколу RTP может быть включена в сообщение «MB_Release».

[36] Несмотря на то, что терминал передает в определенном порядке последовательность пакетов данных мультимедиа по протоколу RTP (то есть данные мультимедиа) и сообщение «MB_Release» РТ-серверу в течение установленного на таймере Т2 периода времени (например, 30 секунд), сообщения (то есть пакеты данных мультимедиа по протоколу RTP и сообщение «MB_Release») могут быть приняты РТ-сервером не в том порядке, в котором они были переданы, из-за разных путей их маршрутизации в сети. Например, при передаче пакетов данных мультимедиа по протоколу RTP и сообщения «MB_Release» в определенном порядке, сообщение «MB_Release» может достичь РТ-сервер раньше, чем пакеты данных мультимедиа по протоколу RTP. То есть после получения сообщения «MB_Release», посланного терминалом, РТ-сервер может принять часть пакетов данных мультимедиа по протоколу RTP (то есть последний пакет данных мультимедиа по протоколу RTP из посланных терминалом пакетов данных мультимедиа по протоколу RTP). В данном случае РТ-сервер проверяет (то есть отыскивает и анализирует) информацию о порядковом номере последнего пакета данных мультимедиа по протоколу RTP, включенную в сообщение «MB_Release», a затем ждет момента приема этого последнего пакета данных мультимедиа по протоколу RTP. То есть состояние РТ-сервера относительно терминала продолжает пока оставаться «вторым» состоянием (то есть состояние «U: permitted»/«Пользование: разрешено»), см. Фиг.1. Однако, если время таймера Т2 истекает, пока РТ-сервер ожидает приема этого последнего пакета данных мультимедиа по протоколу RTP, РТ-сервер посылает сообщение об отмене «MB_Revoke» терминалу (то есть это соответствует ситуации 3 (Situation 3) на Фиг.1). Здесь, состояние РТ-сервера относительно терминала переходит из «второго» состояния в «четвертое» состояние (то есть состояние «U: pending МВ_Rеvоkе»/«Пользование: задержка МВ_Отменить»). Затем, после получения упомянутого последнего пакета данных мультимедиа по протоколу RTP РТ-сервер может рассматривать этот полученный последним пакет данных мультимедиа по протоколу RTP недействительным (не разрешенным пакетом), который не достиг сервера в течение периода времени, разрешенного для передачи данных мультимедиа (то есть установленного для таймера Т2 периода времени), и поэтому он оштрафует терминал. Соответственно, состояние РТ-сервера относительно терминала переводится из «четвертого» состояния в «пятое» состояние (то есть состояние «U: waiting МВ_Rеvоkе»/«Пользование: ожидание МВ_Отменить), а именно в состояние, в котором на терминал налагается штраф (наказание). То есть терминал в «пятом» состоянии не может запрашивать у РТ-сервера полномочия на данные мультимедиа в течение всего периода штрафного времени (то есть периода времени, соответствующего установленному на таймере Т9 значению).

[37] Соответственно, в случае когда терминал в определенном порядке передает пакеты мультимедиа по протоколу RTP (данных мультимедиа) и сообщение «MB_Release» в течение разрешенного для передачи данных мультимедиа периода времени (то есть периода времени, установленного на таймере Т2), например 30 секунд, и если разрешенный для передачи данных мультимедиа период времени истекает в состоянии, при котором РТ-сервер принял в первую очередь сообщение «MB_Release», но еще не получил часть пакетов данных мультимедиа по протоколу RTP (то есть последний пакет данных мультимедиа по протоколу RTP) из-за задержки передачи по путям маршрутизации в сети, терминал может нежелательно оказаться в состоянии, в котором он не сможет запросить полномочия на пакеты данных мультимедиа у РТ-сервера в течение периода времени, установленного на таймере Т9 (например, 30 секунд), что является неприемлемым условием.

[38] Целью настоящего изобретения является предложение способа и устройства для управления состоянием РТ-сервера, которые обращают внимание на ограничения и недостатки известного уровня техники.

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

[40] Далее, раскрытие настоящего изобретения заключается в том, чтобы обеспечить терминалу (устройству РТ-клиента) возможность запроса разрешения на передачу пакета данных мультимедиа (разрешения на передачу/выход в эфир или на полномочия на пакет данных мультимедиа), даже если РТ-сервер принимает определенные данные мультимедиа после получения от терминала сообщения об освобождении (разъединении) разрешения на передачу пакета данных мультимедиа.

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

[42] В соответствии с одним из аспектов настоящего изобретения предлагается способ управления состоянием сервера для Push-To услуги (РТ-сервер), включающий в себя: переход, при помощи РТ-сервера во «втором» состоянии, в «первое» состояние, когда РТ-сервером принимается сообщение об освобождении пакетов данных мультимедиа; и пребывание, при помощи РТ-сервера, в «первом» состоянии, если в «первом» состоянии РТ-сервер принимает пакет данных мультимедиа от РТ-клиента и если РТ-сервер в предшествующем «втором» состоянии получил сообщение об освобождении пакетов данных мультимедиа.

[43] В соответствии с другим аспектом настоящего изобретения предлагается способ управления состоянием РТ-сервера, включающий в себя: переход, при помощи РТ-сервера, находящегося во «втором» состоянии, в «первое» состояние при приеме сообщения об освобождении пакета данных мультимедиа; определение РТ-сервером, если в предыдущем «втором» состоянии получено сообщение об освобождении пакетов данных мультимедиа, когда принят пакет данных мультимедиа, пока РТ-сервер находится в переходном «первом» состоянии; и пребывание РТ-сервером в переходном «первом» состоянии при приеме пакета данных мультимедиа, если на шаге определения было определено, что сообщение об освобождении пакета данных мультимедиа было получено в предыдущем «втором» состоянии. Кроме того, данный способ включает в себя: прием РТ-сервером во «втором» состоянии одного или более пакетов данных мультимедиа от РТ-клиента, пока работает таймер Т2, а также прием РТ-сервером во «втором» состоянии от РТ-клиента сообщения об освобождении пакета данных мультимедиа, пока работает таймер Т2.

[44] В соответствии с другим аспектом настоящего изобретения, предлагается способ управления состоянием РТ-сервера, включающий в себя: определение, при помощи РТ-сервера, находящегося во «втором» состоянии, было принято или не было принято сообщение об освобождении пакета данных мультимедиа по истечении времени работы таймера Т2 (когда истек период времени, установленный для таймера Т2); а также переход РТ-сервером либо из «второго» состояния в «первое» состояние, если на шаге определения было определено, что сообщение об освобождении пакета данных мультимедиа было получено, либо из «второго» состояния в «четвертое» состояние, на основании результата определения.

[45] В соответствии с еще одним аспектом настоящего изобретения, предлагается способ управления состоянием РТ-сервера, включающий в себя: прием РТ-сервером сообщения об освобождении пакета данных мультимедиа при работающем таймере Т2; определение РТ-сервером, было ли это сообщение об освобождении пакета данных мультимедиа получено по истечении времени работы таймера Т2 (когда истек период времени, установленный для таймера Т2); а также переход РТ-сервером в состояние ожидания пакетов данных мультимедиа, если на шаге определения было установлено, что сообщения об освобождении пакета данных мультимедиа было получено.

[46] В соответствии с другим аспектом настоящего изобретения, предлагается устройство клиента РТ-услуги (РТ-клиента), содержащее: контроллер, чтобы передать РТ-серверу, как минимум, один пакет данных мультимедиа и сообщение об освобождении пакетов данных мультимедиа, чтобы принимать от РТ-сервера сообщения об ожидании передачи пакетов данных мультимедиа в ответ на сообщение об освобождении пакетов данных мультимедиа и чтобы передавать РТ-серверу запрос на передачу пакетов данных мультимедиа после получения сообщения об ожидании передачи пакетов данных мультимедиа, причем сообщение об ожидании передачи пакетов данных мультимедиа принимается от РТ-сервера, если РТ-сервер получил сообщение об освобождении для пакетов данных мультимедиа перед таймером Т2.

[47] В соответствии с другим аспектом настоящего изобретения, предлагается устройство РТ-клиента, содержащее: контроллер, чтобы передавать РТ-серверу, как минимум, один пакет данных мультимедиа и сообщение об освобождении пакета данных мультимедиа, чтобы получать от РТ-сервера сообщение об ожидании пакета данных мультимедиа в ответ на сообщение об освобождениии пакетов данных мультимедиа и чтобы передавать РТ-серверу запрос на передачу пакета данных мультимедиа после получения сообщения об ожидании пакета данных мультимедиа, причем запрос на передачу пакета данных мультимедиа передается, если РТ-сервер принимает, как минимум, один пакет данных мультимедиа в «первом» состоянии после получения сообщения об освобождении пакета данных мультимедиа, при этом сообщение об освобождении пакета данных мультимедиа было получено РТ-сервером в предшествующем состоянии.

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

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

[50] На Фиг.1 показана диаграмма машины состояний, иллюстрирующая передачу и прием пакета данных мультимедиа между РТ-клиентом и РТ-сервером в соответствии с известным уровнем техники.

[51] На Фиг.2 показана блок-схема прохождения сигнала, иллюстрирующая получение разрешения на передачу пакета данных мультимедиа и передачу данных мультимедиа между РТ-сервером и терминалами (например, РТ-клиентами) в соответствии с известным уровнем техники.

[52] На Фиг.3 показана блок-схема прохождения сигнала, иллюстрирующая управление пакетом данных мультимедиа в соответствии с первым вариантом осуществления настоящего изобретения.

[53] На Фиг.4 показана блок-схема прохождения сигнала, иллюстрирующая управление пакетом данных мультимедиа в соответствии со вторым вариантом осуществления настоящего изобретения.

[54] На Фиг.5 показана архитектура услуги быстрой связи (РТ) («Нажми и...»), иллюстрирующая пользовательское оборудование «UE» (или терминал) в соответствии с настоящим изобретением.

[55] Данное описание предпочтительных вариантов осуществления настоящего изобретения может быть применено к РТ системам связи, предоставляющих РТ-услуги, и относящимся к ним устройствам. Однако описание не может быть ограничено только этим и может быть применимо к любой системе проводной и беспроводной связи и относящимся к ней устройствам, к которым могут быть применены технические характеристики настоящего изобретения.

[56] В соответствии с одним из аспектов настоящего изобретения, когда терминал, имеющий разрешение на передачу пакетов данных мультимедиа [разрешение на передачу (выход в эфир) или полномочия на пакеты данных мультимедиа], передает РТ-серверу данные мультимедиа (например, пакеты данных мультимедиа по протоколу RTP, не имеющие порядковых номеров) и сообщение об освобождении разрешения на передачу пакета данных мультимедиа (то есть сообщение «MB_Release») в течение периода действия разрешения на передачу пакета данных мультимедиа, даже если РТ-сервер принимает часть данных мультимедиа (например, последний пакет данных мультимедиа по протоколу RTP или, как минимум, один пакет данных мультимедиа по протоколу RTP, который не является последним пакетом данных мультимедиа по протоколу RTP) после получения сообщения об освобождении «MB_Release» по причине задержки передачи по различным путям маршрутизации в сети, терминалу может быть разрешено запросить разрешение на передачу пакета данных мультимедиа без каких-либо ограничений со стороны РТ-сервера.

[57] В соответствии с другим аспектом настоящего изобретения, когда терминал, имеющий разрешение на передачу пакетов данных мультимедиа, передает, в порядке очередности, данные мультимедиа (например, пакеты данных мультимедиа по протоколу RTP, имеющие порядковый номер) и сообщение об освобождении «MB_Release» в течение периода действия разрешения на передачу пакета данных мультимедиа, то, даже если РТ-сервер принимает в первую очередь сообщение об освобождении «MB_Release» по причине задержки передачи по различным путям маршрутизации в сети, а затем получает часть данных мультимедиа (например, последний пакет данных мультимедиа по протоколу RTP или, как минимум, один пакет данных мультимедиа по протоколу RTP, который не является последним пакетом данных мультимедиа по протоколу RTP) до истечения периода действия разрешения на передачу пакета данных мультимедиа, терминалу может быть разрешено запросить разрешение на передачу пакета данных мультимедиа без каких-либо ограничений.

[58] Далее будет дано описание структуры и операций предпочтительных вариантов осуществления настоящего изобретения со ссылкой на прилагаемые чертежи. Данное раскрытие изобретения может предложить первый и второй варианты осуществления изобретения только в качестве иллюстративных примеров.

[59] Первый вариант осуществления изобретения применим в случаях, когда пакеты данных мультимедиа по протоколу RTP (данные мультимедиа) имеют порядковые номера или когда пакеты данных мультимедиа по протоколу RTP не имеют порядковых номеров. Второй вариант осуществления изобретения применим в случае, когда пакеты данных мультимедиа по протоколу RTP (данные мультимедиа) имеют порядковые номера, поэтому РТ-сервер узнает о том, что еще один или несколько пакетов данных мультимедиа по протоколу RTP могут быть дополнительно получены, путем проверки информации о «порядковом номере последнего пакета», включенной в принятое сообщение об освобождении пакетов данных мультимедиа (например, сообщение «MB_Release») и, таким образом, он может ожидать получения дополнительных пакетов данных мультимедиа по протоколу RTP. В этом случае порядковый номер каждого пакета данных мультимедиа по протоколу RTP (данных мультимедиа) действует в качестве идентификатора каждого пакета, а также он действует в качестве разновидности индикатора, информирующего о последовательности (очередности) каждого пакета. Каждое сообщение об освобождении «MB_Release» включает в себя информацию, указывающую последний пакет данных мультимедиа по протоколу RTP, например «порядковый номер последнего пакета». Однако каждый пакет данных мультимедиа по протоколу RTP может включать или может не включать в себя свой порядковый номер.

[60] На Фиг.3 показана блок-схема прохождения сигнала, иллюстрирующая управление пакетом данных мультимедиа в соответствии с первым вариантом осуществления настоящего изобретения.

[61] Далее приводится описание со ссылкой на Фиг. 1 и 3. Здесь предполагается, что установлен сеанс по протоколу SIP при «нулевом» состоянии РТ-сервера, см. Фиг.1, и затем РТ-сервер находится в «первом» состоянии, посылая сообщение об ожидании «MB_Idle» каждому терминалу. То есть каждый терминал находится в состоянии, в котором он может запрашивать полномочия на пакеты данных мультимедиа (разрешение на передачу или разрешение на передачу пакета данных мультимедиа) у РТ-сервера. Однако в данном случае описание приводится с предположением, что терминал А получил от РТ-сервера разрешение на передачу пакета данных мультимедиа только в качестве примера.

[62] Каждый из терминалов А, В и С (устройств РТ-клиента) направляет РТ-серверу сообщение с запросом разрешения на передачу пакета данных мультимедиа (т.е. сообщение «MB_Request»/«MB_3апрос») (шаг S10). Когда РТ-сервер решает выдать разрешение на передачу пакета данных мультимедиа терминалу А, он посылает терминалу А сообщение о выдаче разрешения (т.е. сообщение «MB_Granted») в ответ на запрос терминалом А разрешения на передачу пакета данных мультимедиа, но направляет терминалам В и С сообщение для информирования о том, что разрешение на передачу пакета данных мультимедиа было получено терминалом А (шаг S20). В ходе шагов S10 и S20 состояние РТ-сервера относительно терминала А переходит (изменяется или перемещается) из «первого» состояния на Фиг.1 во «второе» состояние (то есть состояние «U: permitted»/«Пользование: разрешено»). Таким образом, терминал А может передавать данные мультимедиа (пакеты данных мультимедиа по протоколу RTP) РТ-серверу в течение разрешенного времени, установленного на таймере Т2. Таким же образом, в ходе шагов S10 и S20 терминалы В и С получают сообщение «МВ_Таkеn»/«МВ_Принят» и, следовательно, рабочее состояние РТ-сервера относительно терминалов В и С соответствует «шестому» состоянию (состояние «U: not permitted and МВ_Таkеn»/«Пользование: не разрешено и МВ_Принят») на Фиг.1. Поскольку терминал А находится во «втором» состоянии (то есть состояние «U: permitted»/«Пользование: разрешено»), терминал А может передавать данные мультимедиа (или пакеты данных мультимедиа по протоколу RTP) РТ-серверу (шаг S30). В этом случае при приеме первого пакета данных мультимедиа по протоколу RTP РТ-сервер приводит в действие как таймер Т1, так и таймер Т2. То есть терминал А может передавать РТ-серверу последовательность пакетов данных мультимедиа по протоколу RTP в течение времени (периода времени), установленного на таймере Т2 (например, 39 секунд) (шаги с S31 по S33). В этом случае РТ-сервер перезапускает таймер Т1, когда он принимает каждый из пакетов данных мультимедиа протокола RTP. Таймер Т1 отсчитывает период времени с момента приема одного пакета данных мультимедиа по протоколу RTP до момента приема следующего пакета данных мультимедиа по протоколу RTP.

[63] Когда время таймера Т1 истекает или когда происходит прием сообщения об освобождении «MB_Release» от терминала А, РТ-сервер определяет, что терминал А полностью передал свои данные мультимедиа, а затем переходит из «второго» состояния, см. Фиг.1, в «первое» состояние, см. Фиг.1, а именно в состояние, в котором терминал А может запросить полномочия на данные мультимедиа (разрешение на передачу пакета данных мультимедиа).

[64] Теперь рассмотрим более подробно шаги этапа S30. Как показано на Фиг.3, терминал А передал РТ-серверу последовательность пакетов данных мультимедиа по протоколу RTP в пределах периода времени, разрешенного терминалу А для передачи данных мультимедиа (то есть значения (периода временим), установленного на таймере Т2) (шаги с S31 по S33), а затем передал сообщение об освобождении «MB_Release» (шаг S34). В этом случае сообщения (то есть пакеты данных мультимедиа по протоколу RTP и сообщение «MB_Release»), переданные терминалом А, могут быть переданы РТ-серверу по различным путям маршрутизации в сети, что может вызвать задержку передачи по причине использования различных путей маршрутизации в сети. Следовательно, РТ-сервер может получить последний пакет данных мультимедиа по протоколу RTP или один и более пакетов данных мультимедиа по протоколу RTP (который может не быть последним пакетом данных мультимедиа по протоколу RTP) после приема сообщения об освобождении «MB_Release», посланного терминалом А (шаг S34).

[65] Поскольку РТ-сервер принял сообщение об освобождении «MB_Release» на шаге S34, пока таймер Т2 еще работает, в протоколе ТВСР (или протоколе МВСР) состояние РТ-сервера относительно терминала А переходит в из «второго» состояния (которое является текущим состоянием), (то есть «U: permitted»/«Пользование: разрешено») в «первое» состояние (то есть «U: not permitted and МВ_Idle»/«Пользование: не разрешено и МВ_Ожидание»). РТ-сервер может принять сообщение о запросе разрешения на передачу пакетов данных мультимедиа (например, сообщение с запросом «MB_Request») от терминала А, что означает, что в этом состоянии терминал А может снова передавать пакет данных мультимедиа РТ-серверу, если это требуется.

[66] Затем, в соответствии с настоящим изобретением, как и на шаге S33, если РТ-сервер, находящийся в «первом» состоянии, принимает последний пакет данных мультимедиа по протоколу RTP или любой другой пакет(ы) данных мультимедиа, то затем РТ-сервер определяет, было ли уже принято сообщение об освобождении «MB_Release» [то есть сообщение, которое РТ-сервер уже принял во «втором» состоянии (состояние «U: permitted»/«Пользование: разрешено»)]. Если определяется, что сообщение об освобождении «MB_Release» уже было принято, РТ-сервер не переходит в «третье» состояние («U: not permitted but sends media»/«Пользование: не разрешено, но данные мультимедиа передаются»), отвергает полученный последний или любой другой пакет данных мультимедиа по протоколу RTP (без его передачи другому РТ-клиенту (клиентам)) и остается в «первом» состоянии, таким образом, терминал А может вновь запрашивать разрешение на передачу пакета данных мультимедиа, если требуется. С другой стороны, если определено, что сообщение об освобождении «MB_Release» не было принято, тогда РТ-сервер переходит из «первого» состояния в «третье» состояние.

[67] В примере, показанном на Фиг.3, РТ-сервер в «первом» состоянии определяет, что сообщение об освобождении «MB_Release» [то есть сообщение, которое РТ-сервер уже принял во «втором» состоянии (состояние «U: permitted»/«Пользование: разрешено»)] было принято (например, на шаге S34), и поэтому отвергает принятый пакет(ы) данных мультимедиа по протоколу RTP, остается в «первом» состоянии и не переходит в «третье» состояние (шаг S35), в отличии от известного уровня техники, показанном на Фиг.1. То есть, когда РТ-сервер, находясь в «первом» состоянии, принимает пакет данных мультимедиа по протоколу RTP шага S33, состояние РТ-сервера в отношении терминала А не изменяется с «первого» состояния на «третье» состояние (то есть состояние «U: not permitted but sends media»/«Пользование: не разрешено, но данные мультимедиа передаются» на Фиг.1). В результате, даже, хотя РТ-сервер принял пакет данных мультимедиа по протоколу RTP шага S33 после получения сообщения об освобождении «MB_Release» шага S34, РТ-сервер не может решить, что передававший данные мультимедиа терминал А не имеет разрешения на передачу пакетов данных мультимедиа.

[68] В вышеприведенном случае РТ-сервер отвергает последний пакет данных мультимедиа по протоколу RTP (или любой другой пакет данных мультимедиа по протоколу RTP), принятый на шаге S33 после получения сообщения об освобождении «MB_Release» на шаге S34, а затем все еще позволяет терминалу А запросить разрешение на передачу пакета данных мультимедиа. То есть в протоколе ТВСР (или протоколе МВСР) состояние РТ-сервера относительно терминала А все еще остается «первым» состоянием. Поэтому существует возможность защитить терминал А от неблагоприятных ситуаций, возникающих из-за задержек передачи данных по путям маршрутизации в сети, когда терминал А передает сначала данные мультимедиа (то есть последовательности пакетов данных мультимедиа по протоколу RTP) в течение времени (периода времени), установленного на таймере Т2, а именно в период действия разрешения на передачу пакета данных мультимедиа, а затем направляет сообщение об освобождении «MB_Release». Соответственно, машина состояний РТ-сервера в отношении терминала не переходит от «первого» состояния к «третьему» состоянию. И следовательно, в соответствии с настоящим изобретением терминал А может снова запрашивать разрешение на передачу пакета данных мультимедиа у РТ-сервера без угрозы быть оштрафованным, что является выгодным и эффективным фактором.

[69] На Фиг.4 приведена блок-схема прохождения сигнала, иллюстрирующая управление пакетом данных мультимедиа в соответствии со вторым вариантом осуществления настоящего изобретения. На схеме предположено, что сеанс по протоколу SIP (протокол установления сеанса связи) установлен при «нулевом» состоянии РТ-сервера, что на Фиг.1, а затем РТ-сервер находится в «первом» состоянии, посылая каждому терминалу сообщение «МВ_Idle»/«МВ_Ожидание». То есть каждый терминал находится в состоянии, позволяющем запрашивать у РТ-сервера разрешение на передачу пакета данных мультимедиа. Поэтому описание приводится с предположением, что терминал А получил от РТ-сервера разрешение на передачу пакета данных мультимедиа только в качестве примера. Во втором варианте осуществления настоящего изобретения, показанном на Фиг.4, операции и функции шагов (S10 и S20) аналогичны тем, что указаны для шагов S10 и S20 первого варианта осуществления изобретения на Фиг.3. В данном примере, однако, в отличие от первого варианта осуществления изобретения на Фиг.3, во втором варианте осуществления изобретения на Фиг.4 каждый пакет данных мультимедиа по протоколу RTP (данные мультимедиа) имеет порядковый номер, а сообщение об освобождении «MB_Release» включает в себя информацию о порядковом номере последнего пакета данных мультимедиа по протоколу RTP.

[70] Во втором варианте осуществления настоящего изобретения, как показано на Фиг.4, даже если сообщение об освобождении «MB_Release» от терминала А принимается РТ-сервером до получения последнего пакета данных мультимедиа по протоколу RTP или, как минимум, до получения одного пакета данных мультимедиа до протоколу RTP, который может не быть последним пакетом данных мультимедиа по протоколу RTP и который был передан раньше сообщения об освобождении «MB_Release», состояние РТ-сервера не переходит (не изменяется) из «второго» состояния в «первое» состояние, но скорее «второе» состояние РТ-сервера по отношению к терминалу А все еще продолжает сохраняться. Это указывает на то, что РТ-сервер ожидает приема последнего пакета данных мультимедиа по протоколу RTP (или любого другого пакета/пакетов данных мультимедиа по протоколу RTP) от терминала А, пока не истечет время таймера Т2. На Фиг.4 каждый пакет данных мультимедиа по протоколу RTP может иметь порядковый номер так, что РТ-сервер может ждать последний пакет данных мультимедиа по протоколу RTP, отслеживая информацию «порядковый номер последнего пакета», содержащуюся в полученном сообщении об освобождении «MB_Release».

[71] Кроме того, второй вариант осуществления изобретения на Фиг.4 показывает, что, хотя последовательность пакетов данных мультимедиа по протоколу RTP (предпочтительно имеющих порядковые номера) и сообщение об освобождении «MB_Release» были переданы РТ-серверу терминалом А до истечения времени отсчета таймером Т2, сообщение об освобождении «MB_Release» может быть принято РТ-сервером в первую очередь из-за задержки передачи данных по путям маршрутизации в сети. В результате, время отсчета таймером Т2 истекает в состоянии, при котором РТ-сервер не принял часть пакетов данных мультимедиа по протоколу RTP (например, последний или, как минимум, один из пакетов данных мультимедиа по протоколу RTP). Теперь, в соответствии с настоящим изобретением, рассмотрим более подробно со ссылкой на этап S40 операции, связанные с приемом РТ-сервером сообщения об освобождении «MB_Release» и любого пакета данных мультимедиа по протоколу RTP.

[72] При рассмотрении этапа S40 видно, что терминал А, имеющий разрешение на передачу пакета данных мультимедиа, передает РТ-серверу последовательность пакетов данных мультимедиа по протоколу RTP в период времени, в течение которого терминалу А разрешено передавать пакеты данных мультимедиа [то есть значения (периода времени), установленного на таймере Т2], (шаги с S41 по S43). Здесь предпочтительно каждый пакет данных мультимедиа по протоколу RTP имеет порядковый номер. Затем, терминал А направляет РТ-серверу сообщение об освобождении «MB_Release» в течение периода времени, выделенного для передачи пакета данных мультимедиа [то есть значения (периода времени), установленного на таймере Т2], (шаг S44). Однако, даже если пакеты данных мультимедиа по протоколу RTP и сообщение об освобождении «MB_Release» были переданы терминалом А в определенном порядке РТ-серверу, каждый пакет данных мультимедиа по протоколу RTP и сообщение об освобождении «MB_Release» могут быть переданы по различным путям маршрутизации в сети. Соответственно, может произойти задержка передачи данных из-за различных путей маршрутизации, по которым были переданы пакеты данных и сообщение.

[73] В примере, показанном на Фиг.4, до истечения времени отсчета таймером Т2 РТ-сервер принимает пакет данных мультимедиа по протоколу RTP (порядковый номер 1), пакет данных мультимедиа по протоколу RTP (порядковый номер 2) и т.д., (шаги S41 и S42). Далее, РТ-сервер может принять сообщение об освобождении «MB_Release» до приема последнего или любого другого пакета данных мультимедиа по протоколу RTP (например, пакета данных мультимедиа по протоколу RTP, имеющего порядковый номер n) из-за задержки передачи данных (шаги S43 и S44). В данном примере РТ-сервер может определить, является ли принятый пакет данных мультимедиа по протоколу RTP последним пакетом данных мультимедиа по протоколу RTP, анализируя информацию о порядковом номере (например, n) последнего пакета данных мультимедиа по протоколу RTP, включенную в принятое сообщение об освобождении «MB_Release». Например, может быть проверена информация/параметр «порядковый номер последнего пакета», представленная в полученном сообщении об освобождении «MB_Release». Впоследствии РТ-сервер может сохранить информацию о порядковом номере последнего пакета данных мультимедиа по протоколу RTP в специальном запоминающем устройстве [например, встроенном (оборудованном) в РТ-сервере или внешнем запоминающем устройстве/памяти].

[74] Поскольку информация «порядковый номер последнего пакета», включенная в полученное сообщение об освобождении «MB_Release», указывает, что РТ-сервер еще должен принять последний пакет, РТ-сервер ожидает приема последнего пакета данных мультимедиа по протоколу RTP (с порядковым номером n), см. шаг S43, когда РТ-сервер принимает сообщение об освобождении «MB_Release». Состояние РТ-сервера относительно терминала А не переходит из «второго» состояния в «первое» состояние, но предпочтительнее РТ-сервер остается в это время во «втором» состоянии (шаг S45) в соответствии с настоящим изобретением. В результате, РТ-сервер может принимать данные мультимедиа (например, последний пакет данных мультимедиа по протоколу RTP с порядковым номером n), передаваемые терминалом А до истечения времени, отсчитываемого таймером Т2.

[75] Однако, если последний пакет данных мультимедиа по протоколу RTP (с порядковым номером n) не был принят по истечении времени, отсчитываемого таймером Т2 (например, на шаге S43 последний пакет данных мультимедиа по протоколу RTP принят по истечении времени, отсчитываемого таймером Т2), то затем РТ-сервер определяет, было ли уже получено или нет сообщение об освобождении «МВ_Release» (шаг S46). То есть, когда истекает время, отсчитываемое таймером Т2, а РТ-сервер находится во «втором» состоянии («U: permitted»/«Пользование: разрешено»), РТ-сервер не переходит в «четвертое» состояние, а остается во «втором» состоянии (шаг S45), а затем определяет, было ли уже принято РТ-сервером сообщение об освобождении «MB_Release» (шаг S46). Если определено, что сообщение об освобождении «MB_Release» уже было принято, то тогда РТ-сервер переходит из «второго» состояния в «первое» состояние («U: not permitted and MB_Idle»/«Пользование: не разрешено и МВ_Ожидание»), передает терминалу А сообщение «МВ_Idle»/«МВ_Ожидание» и отвергает любой полученный позже пакет данных мультимедиа по протоколу RTP. В примере на Фиг.4, так как РТ-сервер уже получил сообщение об освобождении «МВ_Release» на шаге S44, на шаге S45 РТ-сервер определяет, что сообщение об освобождении «МВ_Release» было уже получено, а затем переходит из «второго» состояние в «первое» состояние, а после этого передает терминалу А сообщение «МВ_Idle»/«МВ_Ожидание», оставаясь в «первом» состоянии (шаги S47 и S48).

[76] С другой стороны, если РТ-сервер определяет на шаге S45, что сообщение об освобождении «MB_Release» не было получено, то тогда РТ-сервер передает терминалу А сообщение «MB_Revoke»/«MB_Отменить» (шаг S49) и переходит из «второго» состояния в «четвертое» состояние («U: pending MB_Revoke»/«Пользование: задержка МВ_Отменить») (шаг S50).

[77] Как было рассмотрено выше, в соответствии с определением на шаге S45 РТ-сервер может узнать, что он уже получил сообщение об освобождении «MB_Release» на шаге S44, до того как истекло время, отсчитываемое таймером Т2. Поэтому РТ-сервер перешел из «второго» состояния в «первое» состояние так, что терминал А может запрашивать разрешение на передачу пакета данных мультимедиа, что является выгодным фактором. То есть в соответствии с настоящим изобретением РТ-сервер не направляет терминалу А сообщение «MB_Revoke»/«MB_Отменить», как только истекает время, отсчитываемое таймером Т2. Кроме того, в данном случае состояние РТ-сервера относительно терминала А не переходит (не изменяется) из «второго» состояния в «четвертое» состояние (то есть «U: pending МВ_Rеvоkе»/«Пользование: задержка МВ_Отменить»). Однако, если на шаге S45 определено, что РТ-сервер еще не получил сообщение об освобождении «MB_Release», в момент истечения времени, отсчитываемого таймером Т2, РТ-сервер передает терминалу А сообщение «МВ-Rеvоkе»/«МВ_Отменить» (шаг S49). В этом случае состояние РТ-сервера относительно терминала А переходит из «второго» состояния в «четвертое» состояние (то есть «U: pending MB_Revoke»/«Пользование: задержка МВ_Отменить») (шаг S50).

[78] Между тем РТ-сервер может привести в действие таймер Т3, когда истекает время таймера Т2. Если РТ-сервер принимает последний пакет данных мультимедиа по протоколу RTP (с порядковым номером n) до истечения времени, отсчитываемого таймером Т3, РТ-сервер передает последний пакет данных мультимедиа по протоколу RTP (с порядковым номером n) терминалу В и/или терминалу С (то есть, в соответствии с Ситуацией 4 на Фиг.1). Однако, когда истекает время таймера Т3, или РТ-сервер, находящийся в «четвертом» состоянии, получает последний пакет данных мультимедиа по протоколу RTP (с порядковым номером n), то РТ-сервер должен считать, что терминал А передал данные мультимедиа (то есть последний пакет данных мультимедиа по протоколу RTP с порядковым номером n) без полномочий на пакеты данных мультимедиа (без разрешения на передачу пакетов данных мультимедиа). Соответственно, состояние РТ-сервера относительно терминала А должно перейти (измениться) из «четвертого» состояния (то есть «U: pending МВ_Rеvоkе»/«Пользование: задержка МВ_Отменить») в «пятое» состояние (то есть «U: waiting МВ_Rеvоkе»/«Пользование: ожидание МВ_Отменить»). В «пятом» состоянии РТ-сервер штрафует терминал А, запрещая ему в течение определенного времени запрашивать разрешение на передачу пакетов данных мультимедиа (то есть в течение периода времени, установленного на таймере Т9).

[79] Таким образом, во втором варианте осуществления настоящего изобретения, если РТ-сервер получил сообщение об освобождении «MB_Release» до приема последнего пакета данных мультимедиа по протоколу RTP от терминала А в течение определенного периода времени, установленного на таймере Т2, то РТ-сервер проверяет (анализирует) информацию, связанную с порядковым номером последнего пакета данных мультимедиа по протоколу RTP, включенную в сообщение об освобождении «MB_Release», а затем ожидает приема последнего пакета данных мультимедиа по протоколу RTP, не переходя из «второго» состояния в «первое» состояние. Однако, даже если РТ-сервер не принял последний пакет RTP данных мультимедиа, в момент, когда истекает время таймера Т2, РТ-сервер не направляет автоматически терминалу А сообщение «МВ-Rеvоkе»/«МВ_Отменить», но проверяет, было ли получено сообщение об освобождении «MB_Release», и может перейти из «второго» состояния в «четвертое» состояние, основываясь на результате этого определения. В известном уровне техники РТ-сервер автоматически переходит из «второго» состояния в «четвертое» состояние, когда истекает время таймера Т2, что вызывает включение в работу таймеров Т3 и Т9, причем в течение времени, установленного на таймере Т9, терминалу запрещено запрашивать разрешение на передачу пакета данных мультимедиа. Это является проблемой, потому что наказание является слишком строгим. Настоящее изобретение касается этого ограничения потому, что РТ-сервер выборочно переходит из «второго» состояния в «четвертое» состояние, основываясь на результате определения на шаге S46. В результате, в соответствии с настоящим изобретением, пользователь (терминал А) не штрафуется без необходимости, и РТ-сервер может позволить терминалу А запросить разрешение на передачу пакета данных мультимедиа. Поэтому терминалу А, если требуется, может быть предоставлена РТ-услуга без каких-либо ограничений по причине задержки передачи данных.

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

[81] Каждый терминал (например, терминал А, В, С и т.д.) в соответствии с настоящим изобретением является устройством РТ-клиента (любое устройство, имеющее РТ-клиента), способным предоставить РТ-услугу. Каждый терминал может включать в свой состав: контроллер, запоминающее устройство и любые другие компоненты для реализации способа в соответствии с рассматриваемым в описании изобретением. Например, каждый терминал может быть одним из всех существующих типов терминалов подвижной связи, ноутбуков с функцией РТ-услуги, настольных компьютеров, переносных игровых приставок, микропроцессорных систем (MPS) и других видов бытовой техники. Кроме того, в описании настоящего изобретения каждый терминал, предпочтительно, означает физический модуль, включающий в себя РТ-клиента, а РТ-клиент, предпочтительно, означает логический или физический модуль, включенный в состав терминала. Соответственно, в целях упрощения описания настоящего изобретения понятие «терминал» может подразумевать устройство РТ-клиента, и наоборот.

[82] На Фиг.5 представлена структура системы, поддерживающей РТ-услугу (Push-To), РТ-системы, включающая в себя терминал (или пользовательское оборудование UE), в соответствии с настоящим изобретением. Последующее описание будет дано со ссылкой на Фиг.5.

[83] В примере на Фиг.5 РТ-клиент может быть помещен в мобильный терминал и использоваться для доступа к РТ-услуге. РТ-клиент может быть сконфигурирован, чтобы разрешить инициацию РТ-сеанса (например, согласование с кодеком), участие в РТ-сеансе (например, говорить или слушать) и отключение РТ-сеанса. РТ-клиент может быть сконфигурирован, чтобы выполнять регистрацию в базовой сети SIP/IP, использующей протоколы SIP/IP, и аутентифицировать пользователя в базовой сети SIP/IP. РТ-клиент может быть сконфигурирован на формирование и передачу пакетов речевых данных (Talk Bursts) [пакетов данных мультимедиа (Media Bursts)] путем записи и кодирования аудиоинформации. РТ-клиент может быть сконфигурирован, чтобы принимать пакеты речевых данных и формировать аудиоинформацию путем декодирования полученных пакетов речевых данных. РТ-клиент может быть сконфигурирован, чтобы поддерживать процедуры управления пакетами речевых данных и согласование протоколов управления пакетами речевых данных (ТВСР). РТ-клиент может быть сконфигурирован, чтобы объединять данные РТ-конфигурации, предоставленные DM-клиентом (клиентом с функциями управления устройством). РТ-клиент может быть сконфигурирован, чтобы поддерживать функции «Индикация режима ответа» (ответ в ручном режиме = Manual Answer и ответ в автоматическом режиме = Automatic Answer), запрета входящего РТ-сеанса (Incoming PT Session Barring), запрета немедленного персонального предупреждения, одновременной поддержки РТ-сеансов. РТ-клиент может быть сконфигурирован, чтобы поддерживать процедуры адаптации плоскости пользователя (Support User Plane), если это инициировано РТ-сервером. РТ-клиент может быть сконфигурирован, чтобы поддерживать прием немедленного персонального предупреждения (Instant Personal Alert). РТ-клиент может быть сконфигурирован, чтобы поддерживать передачу немедленного персонального предупреждения и обеспечение группового оповещения (Group Advertisement). РТ-клиент может быть сконфигурирован, чтобы поддерживать множественные протоколы управления передачей пользовательской информации (Talk Burst Control Protocols) и постановку в очередь запроса речевого пакета, которая может базироваться на приоритетности или метках времени. РТ-клиент может быть сконфигурирован, чтобы передать отчеты обратной связи о качестве обработки после окончания пакета речевых данных. РТ-клиент может быть сконфигурирован, чтобы поддерживать предварительно назначенные сеансы. РТ-клиент может быть сконфигурирован, чтобы поддерживать одновременные сеансы связи и процедуры удержания сеанса связи и, чтобы запрашивать конфиденциальность данных для идентификации пользователя.

[84] В примере на Фиг.5 XDM-клиент (XDMC = клиент управления документами на основе языка XML) может быть ХСАР-клиентом, управляющим хранящимися в сети XML-документами (например, документы, относящиеся к РТ-услуге в стандарте РТ XDMS, списки унифицированных указателей ресурса (URI lists), используемые в качестве примера, списки контактов в системе XDMS коллективного пользования и т.д.). Функции управления включают такие операции, как: создать, изменить, извлечь (отыскать) и удалить.

[85] В примере на Фиг.5 источник контроля присутствия является объектом Presentity [Presentity = Presence+Entity (примечание переводчика)], который предоставляет (раскрывает) информацию о наличии службы присутствия. Наблюдатель (Watcher) является объектом, запрашивающим информацию о наличии или информацию для средства отслеживания от службы присутствия.

[86] Как было рассмотрено выше, в настоящем раскрытии изобретения терминал может запрашивать разрешение на передачу пакета данных мультимедиа (или полномочий на передачу речевого пакета, разрешения на передачу/выход в эфир) без каких-либо ограничений со стороны РТ-сервера, связанных с задержками передачи данных в сети. Поэтому, терминал и РТ-сервер могут использовать РТ-услугу без проблем и по своему усмотрению.

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

1. Способ управления состоянием РТ-сервера [сервер, поддерживающий услугу полудуплексной связи (Push-To)], включающий в себя: прием РТ-сервером, находящемся в состоянии «Пользование: разрешено» («U: permitted»), от РТ-клиента [клиент, поддерживающий услугу полудуплексной связи (Push-To)] одного или нескольких пакетов данных мультимедиа, в то время как работает таймер Т2; прием РТ-сервером, находящемся в состоянии «Пользование: разрешено» («U: permitted»), от РТ-клиента сообщения об освобождении пакета данных мультимедиа, в то время как работает таймер Т2; переход РТ-сервера, находящегося в состоянии «Пользование: разрешено» («U: permitted»), в состояние ожидания пакетов данных мультимедиа (media burst idle), когда РТ-сервером получено сообщение об освобождении пакета данных мультимедиа; определение РТ-сервером, в то время как РТ-сервер находится в переходном состоянии ожидания пакетов данных мультимедиа (Media burst idle), когда принимается пакет данных мультимедиа, было ли в предшествующем состоянии «Пользование: разрешено» («U: permitted») получено сообщение об освобождении пакета данных мультимедиа; дальнейшее пребывание РТ-сервера в переходном состоянии ожидания пакетов данных мультимедиа, когда идет прием пакета данных мультимедиа, если на шаге определения было выявлено, что в предшествующем состоянии «Пользование: разрешено» («U: permitted») было принято сообщение об освобождении пакета данных мультимедиа.

2. Способ управления состоянием РТ-сервера, включающий в себя: определение РТ-сервером, находящемся в состоянии («Пользование: разрешено» («U: permitted»), no истечении времени работы таймера Т2 было получено или нет сообщение об освобождении пакета данных мультимедиа; переход РТ-сервера на основании результата определения, либо из состояния «Пользование: разрешено» («U: permitted») в состояние ожидания пакетов данных мультимедиа (Media burst idle), если на шаге определения было выявлено, что было получено сообщение об освобождении пакета данных мультимедиа, либо из состояния «Пользование: разрешено» («U: permitted») в состояние «Пользование: задержка МВ_Отменить» («U: pending MB_Revoke»), при этом на шаге перехода РТ-сервер переходит из состояния «Пользование: разрешено» («U: permitted») в состояние «Пользование: задержка МВ_Отменить» («U: pending MB_Revoke»), по истечении времени работы таймера Т2, если на шаге определения было выявлено, что сообщение об освобождении пакета данных мультимедиа не было принято.

3. Способ по п.2, в котором состояние «Пользование: разрешено» («U: permitted») является состоянием, в котором РТ-сервер выдал разрешение РТ-клиенту на передачу пакета данных мультимедиа, а состояние «Пользование: задержка МВ_Отменить» («U: pending MB_Revoke») является состоянием с льготным периодом времени, в течение которого этот РТ-клиент избавлен от запроса у РТ-сервера разрешения на передачу пакета данных мультимедиа или в течение которого РТ-сервер может передавать дополнительный пакет данных мультимедиа от этого РТ-клиента другому РТ-клиенту.

4. Способ по п.2, в котором состояние «Пользование: разрешено» («U: permitted») является состоянием, в котором РТ-клиенту разрешена передача пакета данных мультимедиа, а состояние («Пользование: задержка МВ_Отменить» («U: pending MB_Revoke») является состоянием с близкой отменой задержки пакета медиаданных.

5. Способ управления состоянием РТ-сервера, включающий в себя: получение РТ-сервером сообщения об освобождении пакета данных мультимедиа, пока работает таймер Т2; определение РТ-сервером по истечении времени работы таймера Т2, было ли получено сообщение об освобождении пакета данных мультимедиа; переход РТ-сервера в состояние ожидания пакета данных мультимедиа, когда на шаге определения выявлено, что сообщение об освобождении пакета данных мультимедиа было получено.

6. Способ по п.5, в котором состояние ожидания пакета данных мультимедиа является состоянием «Пользование: не разрешено» и поток медиаданных «МВ»_Ожидание» («U: not permitted and MB_Idle»).

7. Устройство клиента, поддерживающего услугу полудуплексной связи (Push-To), далее РТ-клиент, содержащее: контроллер, чтобы передавать РТ-серверу, как минимум, один пакет данных мультимедиа и сообщение об освобождении пакета данных мультимедиа, чтобы принимать от этого РТ-сервера сообщение об ожидании пакета данных мультимедиа в ответ на сообщение об освобождении пакета данных мультимедиа и чтобы передавать РТ-серверу запрос на пакет данных мультимедиа после получения сообщения об ожидании пакета данных мультимедиа, где сообщение об ожидании пакета данных мультимедиа принимается от РТ-сервера, если РТ-сервер получил сообщение об освобождении пакета данных мультимедиа до истечения времени работы таймера Т2.

8. Устройство РТ-клиента по п.7, в котором указанному контроллеру отказано в получении сообщения об отмене пакета данных мультимедиа от РТ-сервера по причине получения РТ-сервером сообщения об освобождении пакета данных мультимедиа до истечения времени работы таймера Т2.

9. Устройство клиента, поддерживающего услугу полудуплексной связи (Push-To), далее РТ-клиент, включающее в себя: контроллер, чтобы передавать РТ-серверу, как минимум, один пакет данных мультимедиа и сообщение об освобождении пакета данных мультимедиа, чтобы принимать от РТ-сервера сообщение об ожидании пакета данных мультимедиа в ответ на сообщение об освобождении пакета данных мультимедиа и чтобы передать РТ-серверу запрос относительно пакета данных мультимедиа после получения сообщения об ожидании пакета данных мультимедиа, где запрос относительно пакета данных мультимедиа передается, если РТ-сервер принял, как минимум, один пакет данных мультимедиа в состоянии ожидания пакетов данных мультимедиа (Media burst idle) после получения сообщения об освобождении пакета данных мультимедиа, при этом сообщение об освобождении пакета данных мультимедиа получено РТ-сервером при нахождении его в предшествующем состоянии.

10. Устройство РТ-клиента по п.9, в котором РТ-клиент переводится РТ-сервером из состояния «Пользование: разрешено» («U: permitted») в состояние ожидания пакетов данных мультимедиа (Media burst idle) после получения сообщения об освобождении пакета данных мультимедиа.

11. Устройство РТ-клиента по п.9, в котором предшествующее состояние представляет собой состояние «Пользование: разрешено» («U: permitted»).

12. Устройство РТ-клиента по п.10, в котором состояние ожидания пакетов данных мультимедиа является состоянием, в котором РТ-клиент может направить РТ-серверу запрос в отношении пакета данных мультимедиа, а состояние «Пользование: разрешено» («U: permitted») является состоянием, в котором РТ-сервер выдает РТ-клиенту разрешение на передачу пакета данных мультимедиа.