Система и способ для осуществления хэндовера mbms во время доставки в режиме загрузки
Изобретение относится к использованию службы многоадресной/широковещательной передачи мультимедийной информации (MBMS, а именно касается хэндовера сеанса загрузки файла MBMS, когда устройство клиента перемещается из зоны обслуживания MBMS в зону потери обслуживания MBMS. Технический результат заключается в обеспечении целостности получаемого контента без его дублирования при снижении затрат ресурсов. Для этого используют режим кодирования передачи "порциями" НТТР/1.1 для доставки обновлений таблицы доставки файла (FDT) сеанса в режиме, подобном принудительной рассылке. Чтобы сделать возможной доставку контента сеанса FLUTE в режиме принудительной рассылки, каждый экземпляр таблицы FDT кодируют как одну часть сообщения в формате многоцелевых расширений электронной почты Интернета (MIME) с разбиением на части и передают как отдельную порцию данных. Приемник может интерпретировать каждую из отдельных порций данных так, чтобы извлечь из порций данных экземпляр таблицы FDT. Тип контента каждой части сообщения устанавливается на text/xml или другой тип MIME, чтобы указать, что контент является экземпляром таблицы FDT. После анализа экземпляра таблицы FDT и обновления таблицы FDT приемник способен идентифицировать, какие файлы сеанса связи представляют интерес, и может выполнить запрос HTTP GET для получения определенного файла. 7 н. и 14 з.п. ф-лы, 5 ил., 1 табл.
Область техники, к которой относится изобретение
[0001] Настоящее изобретение в целом относится к использованию службы многоадресной/широковещательной передачи мультимедийной информации (MBMS). Более конкретно, настоящее изобретение касается хэндовера сеанса загрузки файла MBMS, когда устройство клиента перемещается из зоны обслуживания MBMS в зону потери обслуживания MBMS.
Предпосылки создания изобретения
[0002] Этот раздел предназначен для представления предпосылок создания изобретения или контекста к изобретению, которое изложено в формуле изобретения. При этом описание может включать концепции, которые могут осуществляться, но не обязательно те, которые были ранее задуманы или осуществлены. Поэтому, если здесь не указано иное, описанное в этом разделе не является описанием известного уровня техники.
[0003] В последние годы решения мобильного широковещания были стандартизированы различными организациями, такими как группа по службе MBMS Проекта сотрудничества по созданию системы третьего поколения (3 GPP). MBMS является службой широковещательной передачи, которая может предлагаться через существующие сети сотовой связи глобальной системы связи с подвижными объектами (GMS) и универсальной системы подвижной связи (UMTS). Служба MBMS по стандарту 3GPP позволяет обеспечить эффективную с точки зрения использования ресурсов доставку популярного мультимедийного контента мобильным абонентам. Клиент MBMS может принимать контент посредством доставки в режиме загрузки (download), потоковой доставки (streaming) и комбинации потоковой доставки и доставки в режиме загрузки.
[0004] MBMS - возможность, описанная в спецификации 3GPP, версия 6. Однако служба MBMS может быть развернута операторами только в нескольких зонах, где эффективно по затратам иметь широковещательное/многоадресное распределение популярного контента. Когда абоненты MBMS перемещаются в районы, где нет зоны обслуживания MBMS, оператор может распределять контент MBMS в режиме одноадресной передачи. В таком случае использования требуется сигнализация прикладного/транспортного уровня, чтобы гарантировать бесшовный хэндовер между приемом контента MBMS в режиме широковещательной/многоадресной передачи и приемом контента MBMS в режиме одноадресной передачи.
[0005] Одной из целей рабочего объекта рабочей группы 3GPP SA4 версии 7 по расширениям служб для абонентов MBMS является определение сигнализации прикладного/транспортного уровня, необходимой для распределения контента MBMS в режиме одноадресной передачи (посредством потоковой передачи и по интерактивным каналам). Другая цель состоит в том, чтобы определить методы оптимизации для доставки контента MBMS.
[0006] Ниже в табл.1 приведены текущие рабочие допущения группы 3GPP SA4 для установления соответствия между протоколами, которые следует использовать в режимах широковещательной/многоадресной и одноадресной передачи.
| Табл.1 | |||
| Случай использования только загрузки | Случай использования только потоковой передачи | Случай использования потоковой передачи + загрузки | |
| Распределение контента MBMS в режиме широковещательной/ | FLUTE/UDP | MBMS-RTP/UDP-RTP/UDP FEC | MBMS-RTP/UDP-RTP/UDP FECFLUTE/UDP |
| многоадресной передачи | |||
| Распределение контента MBMS в режиме одноадресной передачи | OMA-PUSH -OTA-WSP ОТА-НТТР | PSSe-RTSP для управления сеансом -RTP/UDP для транспортировки мультимедийных данных | PSSe-RTSP для управления сеансом -RTP для транспортировки мультимедийных данных -FLUTE/UDP для загрузки файла в том же сеансе RTSP |
[0007] Доставка файлов по однонаправленному транспортному протоколу доставки файлов (FLUTE) рассмотрена в документе по технической политике (запросе комментариев) (RFC) 3926 комитета по инженерным проблемам Интернет (IETF), который доступен по адресу www.ietf.org/rfc/rfc3926.txt (включен в данное описание путем ссылки на источник). Протокол пользовательских дейтаграмм (UDP) рассмотрен в документе IETF RFC 768, который доступен по адресу www.ietf.org/rfc/rfc0768.txt (включен в данное описание путем ссылки на источник). RTP, транспортный протокол для приложений в реальном масштабе времени, рассмотрен в документе IETF RFC 3550, доступном по адресу www.ietf.org/rfc/rfc3550.txt (включен в данное описание путем ссылки на источник). Беспроводной протокол сеансового уровня (WSP) рассмотрен в документе WAP-230-WSP Открытого мобильного альянса, доступном по адресу www1.wapforum.org/tech/documents/WAP-230-WSP-20010705-a.pdf (включен в данное описание путем ссылки на источник). Потоковый протокол реального времени (RTSP) рассмотрен в документе IETF RFC 2326, доступном по адресу www.ietf.org/rfc/rfc2326.txt (включен в данное описание путем ссылки на источник).
[0008] Служба потоковой передачи с пакетной коммутацией (PSS) 3GPP является решением организации 3GPP, позволяющим обеспечить потоковую передачу с пакетной коммутацией в мобильных устройствах. Служба PSS определяет протоколы и кодеки мультимедийных данных для предоставления услуг потоковой передачи для мобильных устройств. Служба PSS основана на протоколе RTSP для установления и управления сеансом связи. Расширения службы потоковой передачи с пакетной коммутацией (PSSe) 3GPP в настоящее время определяются в организации 3GPP. Цель этих расширений состоит в том, чтобы определить расширения к службе 3GPP PSS версии №6 для оптимизации службы потоковой передачи. Общее описание службы PSS может быть найдено в документе 3GPP TS 26.233 V6.0.0 (2004-09): Transparent end-to-end packet switched streaming service (PSS); General description (Release 6), доступном на сайте www.3gpp.org/ftp/Specs/archive/26_seriees/26.233/ (включен в данное описание путем ссылки на источник).
[0009] Для случая использования "только загрузки" механизм хэндовера MBMS в настоящее время полностью не определен.
[0010] Сеанс принудительной автоматической рассылки по протоколу открытого мобильного альянса (OMA-PUSH) является одной из опций для осуществления такого хэндовера, но страдает от ряда недостатков. Система OMA-PUSH, как изложено ниже, в общем, соответствует предложению, сделанному в документе 3GPP TSG-SA4 #41 Tdoc S4-060662. В этой системе, если абонентское оборудование (UE) MBMS находится вне домашней сети, и если атрибут, обеспечивающий адрес доступа, например, такой как unicastAccessURI, является доступным в описании способа доставки, то оборудование MBMS UE регистрирует свои службы загрузки MBMS с помощью центра услуг широковещательной/многоадресной передачи мультимедийной информации (BM-SC). Запрос на регистрацию службы одноадресной доставки включает идентификацию службы абонента MBMS, например, serviceld службы абонента MBMS, и идентификацию устройства абонента, например, международный номер подвижной станции цифровой сети с интеграцией служб (MSISDN) оборудования MBMS UE.
[0011] Оборудование MBMS UE делает запрос на регистрацию службы одноадресной доставки, используя метод запроса GET протокола передачи гипертекста HTTP. Протокол HTTP подробно рассмотрен в документе IETF RFC 2616 (июнь 1999): "Hypertext Transfer Protocol - HTTP/1.1" (доступном на сайте www.ietf.org/rfc/rfc2616.txt и включенном в данное описание путем ссылки на источник). Идентификатор serviceld и номер MSISDN оборудования MBMS UE кодируются в часть запроса унифицированного идентификатора ресурса (URI), который подробно рассмотрен в документе IETF STD 0066/RFC 3986 (январь 2005): "Uniform Resource Identifier (URI)" (доступном по адресу www.ietf.org/rfc/rfc3986.txt и включенном в данное описание путем ссылки на источник), как определено ниже и включено в запрос HTTP GET.
GET/unicastReg?serviceld
=urn:3gpp:0010120123hotdog&MSISDN=436642012345 HTTP/1.1
Host: bmsc.example.com
[0012] Сеанс доставки в режиме загрузки MBMS может содержать один или более файлов. Файлы описываются в таблице доставки файлов (FDT) по протоколу FLUTE. Если способ доставки в режиме загрузки MBMS содержит более одного файла, то формат "многоцелевые расширения электронной почты Интернета с разбиением на части" (Multipart MIME), который определен в документе IETF RFC 2557 (март 1999): "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", J.Palme, A.Hopmann, N.Shelness, (доступном по адресу www.ietf.org/rfc/rfc3986.txt и включенном в данное описание путем ссылки на соответствующий источник), используется для того, чтобы инкапсулировать файлы в совокупный документ объявления службы.
[0013] Загрузка MBMS по каналам согласно протоколу с принудительной рассылкой HTTP форматируется в соответствии со спецификацией ОМА принудительной рассылки по радио (Push Over-the-Air (ОТА)), как рассмотрено в ОМА Push OTA Protocol (25-April-2001): WAP-235-PushOTA-20010425-a, доступном на сайте www.openmobilealliance.org/tech/affiliates/wap/wap-235-pushota-20010425-a.pdf (включенном в данное описание путем ссылки на источник). Протокол ОТА-НТТР используется в канале с принудительной рассылкой по протоколу HTTP. Адресация порта приложения используется, как определено в протоколе OMA Push OTA. Идентификатор (ID) приложения, который необходимо использовать при распределении, назначается уполномоченным по присвоению имен OMA (OMNA), как обсуждается в списке зарегистрированных ID приложений PUSH OMA OMNA на www.openmobilealliance.org/tech/omna/om na-push-app-id.htm (включенном в данное описание путем ссылки на соответствующий источник). Заголовок Content-Encoding (контент-кодирование) включается, если используется утилита компрессирования GZip.
[0014] Подход OMA-PUSH страдает от ряда недостатков. Например, в этой схеме центр службы широковещательной/многоадресной передачи (BM-SC) не имеет никакой информации о состоянии клиента MBMS, то есть центр BM-SC не имеет понятия о том, какие объекты, исходные блоки или символы еще должны быть доставлены клиенту MBMS посредством протокола ОТА-НТТР. Поведение центра BM-SC после приема вышеупомянутого запроса на регистрацию одноадресной передачи является неясным. Однако центр BM-SC может вести себя одним из двух способов. Если сеанс FLUTE включает многочисленные объекты различных размеров, то центр BM-SC должен передать все объекты сеанса FLUTE посредством сеанса ОТА-НТТР, включая те объекты, которые клиент уже принял во время сеанса FLUTE. Это вызывает существенные затраты ресурсов. Альтернативно, после приема вышеупомянутого запроса на регистрацию центр BM-SC может передавать только остающиеся объекты посредством протокола ОТА-НТТР, когда клиент имеет некоторые "дыры" в принятых данных. В этом сценарии клиент не имеет никаких данных с момента, когда он прекратил принимать передачу FLUTE, и до момента, когда центр BM-SC начинает передавать данные посредством протокола ОТА-НТТР.
[0015] Кроме того, в конце сеанса ОТА-НТТР клиент все еще должен инициировать другой сеанс HTTP для исправления неполных блоков объектов/исходных блоков в режиме передачи "от точки к точке" (PtP). Хотя объем служебной информации сигнализации может быть сокращен, если два сеанса HTTP могут быть объединены в один, в этих ситуациях один сеанс HTTP инициируется центром BM-SC, в то время как другой сеанс связи HTTP инициируется клиентом.
[0016] Когда таблица доставки файлов (FDT) является динамической, сервер BM-SC может выполнять операцию OMA-PUSH для клиента всякий раз, когда имеется обновленная таблица FDT. В этом случае клиент не должен делать какой-либо опрос для обновлений таблицы FDT. Однако вышеупомянутые недостатки все еще продолжают существовать.
[0017] Другая опция для осуществления хэндовера MBMS во время доставки в режиме загрузки включает использование FLUTE/UDP по системе одноадресной передачи. Однако этот способ требует излишней служебной информации для включения заголовков FLUTE и символов исправления для непосредственного исправления ошибок (FEC). В частности, и заголовки FLUTE, и символы исправления FEC не нужны для двухточечной доставки. Дополнительно, для транспортировки FLUTE/UDP должен быть установлен также новый сеанс RTSP.
[0018] В дополнение к вышеизложенному, механизм запроса на исправление/ответа PtP, специфицированный в документе MBMS TS 26.346 v.7.2.0, также может быть расширен для случая использования хэндовера MBMS при нескольких особых обстоятельствах. Когда клиент MBMS перемещается из зоны обслуживания MBMS в зону прекращения обслуживания MBMS, он может запускать механизм исправления PtP файла. Клиент тогда пытается выполнить декодирование FEC всех исходных блоков всех объектов, принятых к этому моменту, определить номер/ идентификационную информацию отсутствующих символов и передать запрос HTTP GET на сервер исправления с включением всех необходимых деталей (например, URI файла, номер исходного блока (SBN), номер отсутствующих символов, идентификаторы символов кодирования (ESI) отсутствующих символов и т.д). Если клиент уже принял таблицу FDT, и если таблица FDT остается статической для остальной части сеанса FLUTE, то тогда он знает, какие идентификаторы URI файла / объекты следует ожидать в оставшейся части сеанса FLUTE. Клиент может тогда запросить у сервера исправления оставшиеся исходные блоки текущего объекта и оставшиеся объекты текущего сеанса. Таким образом, клиент MBMS может многократно использовать механизм запроса на исправление PtP также для случая использования хэндовера MBMS. К сожалению, очень вероятно, что таблицы FDTs будут динамическими, то есть могут иметься новые экземпляры таблиц FDT, передаваемые в том же самом сеансе FLUTE. Поэтому клиент не может предполагать, что таблицы FDT являются статическими, так как FLUTE явно позволяет таблицам FDT быть динамическими, и это позволяет доставлять новые экземпляры таблиц FDT непосредственно в сеансе FLUTE. Поэтому механизм запроса на исправление в режиме PtP не может всегда перегружаться, чтобы охватывать случай использования хэндовера MBMS.
[0019] Поэтому было бы желательно предложить решение, которое может использоваться как для статических, так и динамических таблиц FDT, но не использует чрезмерный объем служебной информации.
Сущность изобретения
[0020] Различные формы осуществления настоящего изобретения включают использование режима кодирования передачи "порциями" (chunk) протокола НТТР/1.1, чтобы доставлять сеанс обновления FDT в режиме, подобном принудительной рассылке (push). Каждая часть сообщения MIME отделяется границей, которая объявляется в заголовке Content-Type. Любая строка, появление которой не ожидается в полезной информации сообщения, может использоваться как разделитель. Каждая часть сообщения MIME из нескольких частей также должна определять тип контента этой части. Чтобы сделать возможной принудительную рассылку контента сеанса связи FLUTE, каждый экземпляр таблицы FDT кодируется как одна часть сообщения MIME из нескольких частей и передается как отдельная порция данных. Приемник может интерпретировать каждую из отдельных порций данных, чтобы извлечь из порций данных экземпляр таблицы FDT. Тип контента каждой части сообщения устанавливается на text/xml или другой тип MIMI, чтобы указать, что контент является экземпляром таблицы FDT. После синтаксического анализа экземпляра таблицы FDT и обновления таблицы FDT приемник способен распознать, какие файлы сеанса связи представляют интерес, и может выполнить запрос HTTP GET на исправление определенного файла. Сервер может указать конец сеанса, используя поле заголовка Connection (Соединение) HTTP со значением, установленным на closed (завершено).
[0021] В различных формах осуществления настоящего изобретения нет никакой необходимости в полной реализации протокола ОТА-НТТР или OTA-WSP, чтобы реализовать принудительную доставку, так как поддержка протокола НТТР/1.1 уже требуется функциональными возможностями исправления файлов.
[0022] Эти и другие преимущества и особенности изобретения вместе с его структурой и способом работы станут очевидными из нижеследующего подробного описания, приводимого вместе с сопроводительными чертежами, на которых аналогичные элементы имеют похожие номера позиций на нескольких чертежах, описанных ниже.
Краткое описание чертежей
[0023] Фиг.1 представляет собой блок-схему, показывающую процесс, с помощью которого реализуется форма осуществления настоящего изобретения.
[0024] Фиг.2 является схемой, показывающей хэндовер MBMS во время сеанса загрузки файла согласно одной из форм осуществления настоящего изобретения.
[0025] Фиг.3 является схемой, показывающей передачу множества экземпляров таблицы FDT от сервера на терминал клиента посредством множества порций данных в соответствии с одной из форм осуществления настоящего изобретения.
[0026] На фиг.4 показано перспективное изображение электронного устройства, которое может использоваться при реализации настоящего изобретения.
[0027] На фиг.5 показана блок-схема электронного устройства фиг.4.
Подробное описание предпочтительных форм осуществления изобретения
[0028] Различные формы осуществления настоящего изобретения включают использование режима передачи "порциями" (chunk) НТТР/1.1 для доставки обновлений таблицы FDT сеанса в режиме, аналогичном принудительной рассылке (push). Режим передачи "порциями" определен в НТТР/1.1 для поддержки динамического формирования контента и его доставки от сервера. В некоторых случаях Web-сервер не может знать точную длину контента. Режим передачи "порциями" является формой кодирования передачи, которая позволяет разделять контент на порции известной длины, и тогда каждая порция может передаваться в приемник в части сообщения. Режим передачи "порциями" протокола HTTP 1.1 обычно используется с постоянными соединениями, что делает возможной доставку принудительного типа. Контент сообщения передается с использованием контента с несколькими частями / смешанного типа, при этом каждая часть сообщения доставляется в виде отдельной порции данных.
[0029] Приемник может интерпретировать каждую из отдельных порций данных так, чтобы извлекать из них экземпляр таблицы FDT. Тип контента каждой части сообщения устанавливается на text/xml или другой тип MIME, чтобы указать, что контент является экземпляром таблицы FDT. После синтаксического анализа экземпляра таблицы FDT и обновления таблицы FDT приемник способен распознать, какие файлы сеанса представляют интерес, и может выполнить запрос HTTP GET для извлечения определенного файла. Сервер может указывать конец сеанса, используя поле заголовка Connection (Соединение) HTTP со значением, установленным на closed (завершено).
[0030] На фиг.2 процесс хэндовера MBMS согласно одной из форм осуществления изобретения показан более подробно, с порциями данных широковещательной/многоадресной передачи согласно протоколу FLUTE до и во время хэндовера. Как показано на фиг.2, как только порции данных передаются для одноадресного приема, новый идентификатор транспортного объекта (TOI) используется для порций данных, а номер исходного блока (SBN) для порций данных сбрасывается.
[0031] Фиг.1 представляет блок-схему, показывающую процесс, с помощью которого может быть реализована форма осуществления настоящего изобретения. На шаге 100 на фиг.1 терминал, который находился в пределах зоны обслуживания MBMS, оставляет зону обслуживания MBMS. На шаге 105 терминал выбирает идентификатор unicastAccessURI из объявления службы. На шаге 110 терминал устанавливает постоянное соединение по протоколу управления передачей (TCP) с сервером HTTP или Web-сервером. На шаге 115 терминал передает запрос GET на сервер HTTP. Унифицированный указатель ресурсов (URL) запроса является идентичным идентификатору unicastAccessURI, который уникально идентифицирует сеанс FLUTE на сервере HTTP. Ниже приведен пример того, как может выглядеть такой запрос:
GET/flute_service?serviceld=2987324HTTP/1.1
Host: www.example.com
[0032] На шаге 120 сервер HTTP идентифицирует принятый от терминала запрос как запрос на инициирование одноадресной доставки сеанса FLUTE и идентифицирует службу на основании параметра serviceld, который является идентичным идентификатору serviceld, указанному при объявлении службы. На шаге 125 сервер HTTP создает ответное сообщение. Ответное сообщение указывает, желает ли он обслуживать терминал. Ниже приведен пример ответа, содержащий индикацию того, что сервер HTTP желает обслуживать терминал:
HTTP/1.1 200 OK
Content-type:multipart/mixed
Transfer-encoding: chunked
[0033] На шаге 130 становится доступным новый экземпляр таблицы FDT. Когда новый экземпляр FDT становится доступным, на шаге 135 сервер HTTP создает новую порцию данных и посылает новый экземпляр таблицы FDT как новую часть сообщения MIMI из нескольких частей. Это повторяется каждый раз, когда становится доступным новый экземпляр таблицы FDT. Фиг.3 представляет изображение, показывающее передачу экземпляров таблицы FDT от сервера HTTP на терминал посредством множества порций данных после того, как было послано сообщение 125 ответа HTTP. На шаге 140 приемник принимает и проверяет порцию (порции) данных и соответственно обновляет таблицу FDT. В последующее время, представленное на шаге 140, приемник может передать запрос GET, чтобы выполнить выборку файлов, представляющих интерес.
[0034] На фиг.4 и 5 показано типичное электронное устройство 12, в котором может быть реализовано настоящее изобретение. Однако должно быть понятно, что настоящее изобретение не ограничено электронным устройством 12 одного конкретного типа. Электронное устройство, показанное на фиг.4 и 5, содержит корпус 30, дисплей 32 в виде дисплея на жидких кристаллах, клавиатуру 34, микрофон 36, телефонный капсюль 38, аккумуляторную батарею 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде универсальной карты с интегральными микросхемами (UICC) согласно одной из форм осуществления изобретения, устройство 48 считывания с карт, схемы 52 радиоинтерфейса, схемы 54 кодека, контроллер 56, запоминающее устройство 58 и батарею 80. Отдельные схемы и элементы представляют собой устройства хорошо известного в данной области техники типа, например, по ассортименту мобильных телефонов фирмы Nokia.
[0035] Различные формы осуществления изобретения, описанные здесь, представлены в общем контексте шагов или процессов способа, которые могут быть реализованы в одной форме осуществления в виде компьютерного программного продукта на машиночитаемом носителе, который содержит выполняемые компьютером команды, такие как программный код, выполняемый компьютерами в сетевых средах. Машиночитаемый носитель может быть выполнен в виде съемных и несъемных запоминающих устройств, включая, в качестве неограничивающих примеров, постоянное запоминающее устройство (ROM), оперативное запоминающее устройство (RAM), компакт-диски (CD), цифровой универсальный диск (DVD) и т.д. Вообще, программные модули включают подпрограммы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют конкретные абстрактные типы данных. Исполняемые машинные команды, связанные структуры данных и программные модули представляют собой примеры программного кода для выполнения шагов способов, раскрытых здесь. Конкретная последовательность таких выполнимых команд или связанных структур данных представляет примеры соответствующих действий для реализации функций, описанных на таких шагах.
[0036] Программные и Web-реализации различных форм осуществления изобретения могут быть выполнены стандартными методами программирования с логикой на основе правил и другой логики для выполнения различных шагов или процессов поиска в базе данных, шагов или процессов корреляции, шагов или процессов сравнения и шагов или процессов решения. Следует отметить, что слова "компонент" и "модуль", которые используются здесь и в формуле изобретения, предназначены для охвата реализаций, использующих одну или несколько строк программного кода, и/или аппаратных реализаций, и/или оборудования для приема данных, вводимых вручную.
[0037] Вышеизложенное описание предпочтительных форм осуществления изобретения было представлено с целью иллюстрации и описания. Оно не является исчерпывающим и не ограничивает изобретение только раскрытой формой; модификации и разновидности возможны в свете вышеприведенных идей или могут быть получены в результате практического применения изобретения. Формы осуществления, рассмотренные здесь, были выбраны и описаны с целью объяснения принципов и характера различных форм осуществления настоящего изобретения и его практического применения, чтобы позволить специалистам в данной области техники использовать настоящее изобретение в различных формах осуществления и с различными модификациями, которые подходят для конкретного использования. Признаки форм осуществления изобретения, описанные здесь, могут объединяться во всевозможных комбинациях способов, устройств, модулей, систем и компьютерных программных продуктов.
1. Способ осуществления хэндовера MBMS во время доставки контента в режиме загрузки, включающий:
передачу терминалом первого запроса через постоянное соединение по протоколу управления передачей на сервер протокола передачи гипертекста после выхода из зоны обслуживания службы многоадресной/широковещательной передачи,
прием от сервера протокола передачи гипертекста ответного сообщения, указывающего, что сервер протокола передачи гипертекста желает предоставить обслуживание; и
прием от сервера протокола передачи гипертекста нового экземпляра таблицы доставки файлов в порции данных после того, как новый экземпляр таблицы доставки файлов становится доступным.
2. Способ по п.1, дополнительно включающий обновление таблицы доставки файлов после приема нового экземпляра таблицы доставки файлов, чтобы отразить новый экземпляр таблицы доставки файлов.
3. Способ по п.1, дополнительно включающий передачу второго запроса на получение от сервера протокола передачи гипертекста файлов, представляющих интерес.
4. Способ по п.1, отличающийся тем, что порция данных является частью сообщения в формате многоцелевых расширений электронной почты Интернета.
5. Способ по п.1, отличающийся тем, что постоянное соединение по протоколу управления передачей устанавливается с использованием идентификатора unicastAccessURI, принимаемого из предшествующего объявления службы.
6. Способ по п.5, отличающийся тем, что первый запрос включает унифицированный указатель ресурсов запроса, который является идентичным идентификатору unicastAccessURI.
7. Машиночитаемый носитель, содержащий код программы для выполнения процессов по любому из пп.1-6.
8. Устройство для осуществления хэндовера MBMS во время доставки контента в режиме загрузки, содержащее:
процессор и
запоминающее устройство, содержащее код программы,
причем запоминающее устройство и код программы сконфигурированы так, чтобы при работе с процессором заставлять устройство выполнять по меньшей мере следующие операции:
установление постоянного соединения по протоколу управления передачей с сервером протокола передачи гипертекста после выхода из зоны обслуживания службы многоадресной/широковещательной передачи;
передачу первого запроса на сервер протокола передачи гипертекста;
обработку принимаемого от сервера протокола передачи гипертекста ответного сообщения, указывающего, что сервер протокола передачи гипертекста хочет предоставить обслуживание; и
прием от сервера протокола передачи гипертекста новой таблицы доставки файлов в порции данных после того, как становится доступным новый экземпляр таблицы доставки файлов.
9. Устройство по п.8, отличающееся тем, что запоминающее устройство и код программы дополнительно сконфигурированы так, чтобы при работе с процессором заставлять устройство после приема новой таблицы доставки файлов обновлять таблицу доставки файлов, чтобы отразить новый экземпляр таблицы доставки файлов.
10. Устройство по п.8, отличающееся тем, что запоминающее устройство и код программы дополнительно сконфигурированы так, чтобы при работе с процессором заставлять устройство передавать второй запрос на получение файлов, представляющих интерес, от сервера протокола передачи гипертекста.
11. Устройство по п.8, отличающееся тем, что порция данных является частью сообщения в формате многоцелевых расширений электронной почты Интернета.
12. Устройство по п.8, отличающееся тем, что постоянное соединение по протоколу управления передачей устанавливается с использованием идентификатора unicastAccessURI, принимаемого из предшествующего объявления службы.
13. Устройство по п.12, отличающееся тем, что первый запрос включает унифицированный указатель ресурсов запроса, который является идентичным идентификатору unicastAccessURI.
14. Способ осуществления хэндовера MBMS во время доставки контента в режиме загрузки, включающий:
прием первого запроса GET от терминала, который вышел из зоны обслуживания службы многоадресной/широковещательной передачи;
идентификацию первого запроса как запроса терминалом MBMS инициирования одноадресной доставки файла посредством сеанса однонаправленной транспортировки;
передачу на терминал ответного сообщения после принятия решения обслужить терминал и
передачу на терминал нового экземпляра таблицы доставки файлов в порции данных, когда становится доступным новый экземпляр таблицы доставки файлов.
15. Машиночитаемый носитель, содержащий код программы для выполнения процессов по п.14.
16. Устройство для осуществления хэндовера MBMS во время доставки контента в режиме загрузки, содержащее:
процессор и
запоминающее устройство, содержащее код программы,
причем запоминающее устройство и код программы сконфигурированы так, чтобы при работе с процессором заставлять устройство выполнять по меньшей мере следующие операции:
обработку первого запроса, принимаемого от терминала, выходящего из зоны обслуживания многоадресной/широковещательной передачи;
идентификацию первого запроса как запроса этим терминалом инициирования одноадресной доставки файла посредством сеанса однонаправленной транспортировки;
передачу ответного сообщения на терминал после принятия решения обслужить терминал и
передачу на терминал в порции данных нового экземпляра таблицы доставки файлов, когда становится доступным новый экземпляр таблицы доставки файлов.
17. Устройство по п.16, отличающееся тем, что порция данных является частью сообщения в формате многоцелевых расширений электронной почты Интернета.
18. Устройство по п.16, отличающееся тем, что первый запрос включает унифицированный указатель ресурсов запроса, который является идентичным идентификатору unicastAccessURI, принимаемому из предшествующего объявления службы.
19. Устройство по п.16, отличающееся тем, что запоминающее устройство и код программы дополнительно сконфигурированы так, чтобы при работе с процессором заставлять устройство:
обрабатывать принимаемый второй запрос для получения файлов, представляющих интерес, и
в ответ на второй запрос передавать файлы, представляющие интерес.
20. Устройство по п.16, отличающееся тем, что запоминающее устройство и код программы дополнительно сконфигурированы так, чтобы при работе с процессором заставлять устройство идентифицировать службу, запрашиваемую терминалом, используя параметр serviceID, причем параметр serviceID является идентичным идентификатору, содержащемуся в предшествующем объявлении службы.
21. Система для осуществления хэндовера MBMS во время доставки контента в режиме загрузки, содержащая:
терминал и
сервер протокола передачи гипертекста,
причем терминал сконфигурирован так, чтобы:
после выхода из зоны обслуживания службы многоадресной/широковещательной передачи устанавливать постоянное соединение по протоколу управления передачей с сервером протокола передачи гипертекста и
передавать первый запрос на сервер протокола передачи гипертекста;
а сервер протокола передачи гипертекста сконфигурирован так, чтобы:
идентифицировать первый запрос как запрос терминалом инициирования одноадресной доставки файла посредством сеанса однонаправленной транспортировки,
после принятия решения обслужить терминал, передавать ответное сообщение на терминал; и
после того, как становится доступным новый экземпляр таблицы доставки файлов, передавать на терминал в порции данных новый экземпляр таблицы доставки файлов.
