Сокращение служебной информации протокола

Сокращение служебной информации протокола

Иллюстрации

Показать все

Реферат

Предпосылки создания изобретения

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

[2] Мобильный терминал может принимать программу или услугу в транспортном потоке (transport stream, TS). Транспортный поток способен переносить отдельные элементы программы или услуги, например, ее аудиокомпоненты, видеокомпоненты или компоненты данных. Как правило, мобильный терминал способен находить различные компоненты определенной программы или услуги при помощи следующих структур, включенных в состав транспортного потока: информации о программах (Program Specific Information, PSI) или информации об услугах (Service Information, SI).

Краткое описание примеров осуществления изобретения

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

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

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

Краткое описание чертежей

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

[7] Фиг.1 иллюстрирует систему цифрового широкополосного вещания, в которой могут быть реализованы один или более примеров осуществления настоящего изобретения.

[8] Фиг.2 иллюстрирует пример мобильного устройства.

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

[10] Фиг.4А-В иллюстрируют примеры осуществления заголовков протокола.

[11] Фиг.5А-В демонстрируют пакет IPv4 и пример пакета протокола, сформированного на основе этого пакета протокола IPv4.

[12] Фиг.6А-В демонстрируют пакет IPv6 и пример пакета протокола, сформированного на основе этого пакета IPv6.

[13] Фиг.7А-В демонстрируют пакет UDP и пример пакета протокола, сформированного на основе исходного пакета UDP, с заголовками UDP и IPv6.

[14] Фиг.8А-С демонстрируют примеры осуществления заголовков расширения для пакета IPv6.

[15] Фиг.9А-В демонстрируют примеры осуществления пакетов протокола, формируемых на основе исходного пакета, с заголовками IPv4, UDP и RTP, а также исходного пакета с заголовками IPv4, UDP и RTP.

[16] Фиг.10 иллюстрирует пример способа формирования транспортного потока.

[17] Фиг.11 иллюстрирует пример блок-схемы алгоритма для способа обнаружения услуги с целью идентификации транспортного потока.

[18] Фиг.12 иллюстрирует пример блок-схемы алгоритма для способа обработки транспортного потока, сформированного при помощи способа фиг.10.

[19] Фиг.13 иллюстрирует пример блок-схемы алгоритма для способа сжатия данных в динамическом поле.

[20] Фиг.14 иллюстрирует пример блок-схемы алгоритма для способа обнаружения услуги.

Подробное описание примеров осуществления изобретения

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

[22] Фиг.1 иллюстрирует систему 102 цифрового широкополосного вещания, подходящую для реализации одного или более примеров осуществления настоящего изобретения. В системах, подобных проиллюстрированной, может применяться одна из технологий цифрового широкополосного вещания, к примеру, технология цифрового видеовещания (Digital Video Broadcast, DVB), технология портативного DVB (Handgeld, DVB-H) или технология сетей DVB следующего поколения (next generation DVB, DVB-NGH). Примеры других стандартов цифрового вещания, подходящих для применения в системе 102 цифрового широкополосного вещания, включают стандарт наземного цифрового видеовещания (Digital Video Broadcast Terrestrial, DVB-T), систему цифрового наземного телевещания второго поколения (second generation digital terrestrial television broadcasting system, DVB-T2), стандарт комплексной службы наземного цифрового вещания (Integrated Services Digital Broadcasting - Terrestrial, ISDB-T), стандарт широковещательной передачи данных Комитета по перспективным телевизионным системам (Advanced Television Systems Committee), стандарты DMB-T и T-DMB наземного цифрового мультимедийного вещания (Digital Multimedia Broadcast-Terrestrial, DMB-T) и (Terrestrial Digital Multimedia Broadcasting, T-DMB), стандарт спутникового мультимедийного вещания (Satellite Digital Multimedia Broadcasting, S-DMB), стандарт передачи данных только по прямой линии связи (Forward Link Only, FLO), стандарт цифрового аудиовещания (Digital Audio Broadcasting, DAB), и стандарт всемирного цифрового радиовещания (Digital Radio Mondiale, DRM). Различные аспекты примеров осуществления настоящего изобретения допускают также применение и в других системах цифрового вещания с множественными несущими, например, в системах T-DAB, T/S-DMB, ISDB-T, и ATSC, в проприетарных системах, к примеру, в системе MediaFLO / FLO фирмы QUALCOMM, или в нетрадиционных системах, например, в системе 3 GPP MBMS (Multimedia Broadcast/Multicast Services, мультимедийные широковещательные/многоадресные услуги) и 3GPP2 BCMCS (Broadcast/Multicast Service, услуга широковещательной/многоадресной передачи).

[23] Цифровой контент может быть создан и/или передан источниками 104 цифрового контента, при этом он может включать видеосигналы, аудиосигналы, данные, метаданные и т.д. Источники 104 цифрового контента могут передавать контент в цифровой передатчик 103 в форме цифровых пакетов, к примеру, пакетов протокола Интернета (Internet Protocol, IP). Группа связанных пакетов данных, имеющих общий определенный уникальный адрес данных (например, IP-адрес), может быть названа потоком информации. В различных вариантах осуществления настоящего изобретения потоки информации могут представлять собой потоки данных, например, IP-потоки.

[24] Цифровой передатчик 103 может принимать транспортный поток, обрабатывать и осуществлять его ретрансляцию, при этом упомянутый транспортный поток может включать несколько потоков данных от нескольких источников 104 цифрового контента. Передатчик 103 может включать по меньшей мере один процессор 120 и по меньшей мере одно запоминающее устройство 122, или иные машиночитаемые носители, сконфигурированные для хранения инструкций, которые при исполнении упомянутым процессором сконфигурированы для выполнения описанных в настоящем документе операций. Затем транспортный поток может быть передан на вышку 105 цифрового вещания (или в другой физический передающий компонент) с целью его беспроводной передачи. Наконец, мобильные терминалы или устройства 12, или приемники другого типа, могут, с возможностью выбора, принимать и потреблять цифровой контент, поступающий от источников 104 цифрового контента.

[25] Транспортные потоки способны доставлять сжатые аудиосигналы, видеосигналы и данные в мобильное устройство 112 через сторонние сети доставки. Стандарт Экспертной группы по движущемуся изображению (Moving Picture Expert Group, MPEG) представляет собой технологию, при помощи которой в транспортный поток вместе с остальными программами мультиплексируются кодированные видеосигналы, аудиосигналы и данные. Упомянутый транспортный поток может представлять собой транспортный поток пакетов фиксированной длины, включающих заголовки. Отдельные элементы программ: аудио- и видеосигналы, передаются в собственных отдельных пакетах с уникальным идентификатором пакета (packet identification, PID). Чтобы мобильное устройство 112 было способно находить различные элементы какой-либо программы в транспортном потоке, обеспечивают введение в транспортный поток специальной информации о программах (PSI). В дополнение, в транспортный поток может быть встроена дополнительная информация об услугах (SI) - набор таблиц, придерживающихся синтаксиса секции "private" стандарта MPEG. Это позволяет мобильному устройству 112 корректно обрабатывать содержащиеся в транспортном потоке данные.

[26] Транспортный поток может включать электронный указатель услуг (Electronic Service Guide, ESG) для предоставления мобильному устройству 112 информации о программах или услугах. Как правило, электронный указатель услуг (ESG) позволяет передатчику передавать информацию об услугах, доступных конечному пользователю, и о способах доступа к ним. ESG включает независимо существующие части - фрагменты ESG. Традиционно, фрагменты ESG содержали XML-документы и/или двоичные документы, однако в последнее время в них стали включать широкий спектр различных элементов, например, описание протокола SDP (протокол описания сеанса, Session Description Protocol), текстовые файлы или изображения. ESG-фрагменты описывают один или несколько аспектов услуги или программы, доступной в настоящий (или будущий) момент времени вещания. Упомянутые аспекты могут, например, включать: свободное текстовое описание, расписание программ, географическую доступность, стоимость, способ приобретения, жанр и вспомогательную информацию, к примеру, фотографии или видеофрагменты. Аудио-, видеоданные и другие типы данных, включающие ESG-фрагменты могут передаваться через сети различных типов и в соответствии с множеством различных протоколов. Например, данные могут передаваться через набор сетей, называемых обычно «Интернет», с использованием стека Интернет-протоколов, например, протокола Интернета (IP) и протокола пользовательских датаграмм (User Datagram Protocol, UDP). Передаваемые через Интернет данные часто адресованы одному пользователю. Тем не менее, они могут адресоваться группе пользователей, что обычно называют многоадресной передачей. В случае передачи данных всем пользователям говорят о широковещательной передаче или вещании.

[27] Одним из способов широковещательной или многоадресной передачи данных является применение сети рассылки данных по протоколу IP (IP datacasting, IPDC). IPDC представляет собой комбинацию протокола Интернета и цифрового вещания. При помощи такой сети вещания на базе протокола IP один или более поставщиков услуг могут обеспечивать различные типы IP-услуг, включая Интернет-газеты, Интернет-радио и Интернет-телевидение. Такие IP-услуги организованы в один или более потоков данных в форме аудио-, видеоданных и/или данных других типов. Чтобы определить, где и когда присутствуют эти потоки данных, пользователи могут обращаться к электронному указателю услуг (ESG).

[28] Стандарт портативного цифрового видеовещания (DVB-H) представляет собой один из типов стандарта DVB. Стандарт DVB-H предназначен для доставки данных на оконечные устройства, питающиеся от аккумуляторов, со скоростью до 10 Мб/с.Фрагменты ESG могут передаваться на целевые устройства при помощи IPDC через сеть, например, через сеть DVB-H. Стандарт DVB-H может включать, например, отдельные потоки видеосигнала, аудиосигнала и данных. Мобильное устройство 112 может, с целью получения полезной информации после приема, определять порядок расположения фрагментов ESG и обеспечивать их сборку.

[29] В DVB-системах услуги передачи данных (например, IP-услуги) могут передаваться в транспортном потоке при помощи секций многопротокольной инкапсуляции (Multi-Protocol Encapsulation, МРЕ) или по протоколу инкапсуляции общего потока (Generic Stream Encapsulation, GSE). Протокол МРЕ может формировать МРЕ-секцию с помощью инкапсуляции блоков данных протоколов (protocol data units, PDU) (например, пакетов данных протокола IP). Каждая МРЕ-секция может быть передана как серия пакетов транспортного потока в одном транспортном потоке. Протокол МРЕ может поддерживать услуги широковещательной передачи, требующие передачи датаграмм или протоколов связи через сети вещания, совместимые с DVB.

[30] Протокол GSE может обеспечивать функции инкапсуляции и фрагментации пакетов сетевого уровня для передачи в стандартных потоках. Протокол GSE может обеспечивать эффективную инкапсуляцию IP-датаграмм в пакеты второго уровня переменной длины, передача которых вслед за этим может непосредственно планироваться на физическом уровне (например, кадры основной полосы частоты в стандарте DVB-T2). Протокол GSE может поддерживать инкапсуляцию нескольких протоколов (протокол Интернета версии 4 (IPv4), протокол Интернета версии 6 (IPv6), протокол экспертной группы по движущемуся изображению (MPEG), режим асинхронной передачи (asynchronous transfer mode, ATM), Ethernet и т.п.) и допускает включение новых типов протоколов. При этом протокол GSE поддерживает несколько режимов адресации.

[31] IP-датаграммы могут инкапсулироваться в один или более пакетов протокола GSE. Процедура инкапсуляции может помечать начало и конец каждого PDU сетевого уровня, добавлять информацию управления, например, тип сетевого протокола и адресную метку, а также при необходимости осуществлять общую проверку целостности. Пример синтаксиса протокола GSE представлен ниже в таблице 1.

Таблица 1
Пакет инкапсуляции стандартного потока
Поле	Размер
GSE_Packet() {
Start-Indicator	1 бит
End_Indicator	1 бит
Label_Type_lndicator	2 бита
If (Start_Indicato=="0") and (End_Indicator=="0") and (Label_Type_lndicator="00" {
Padding_bits	4 бита
For (i=0;i<N1;i++){
Padding_bytes	8 бит
}
} else {
GSE_Length	12 бит
If (Start_Indicator=="0") or (End_Indicator=="0") {
Frag_ID	8 бит
}
If (Start_Indicator=="1") or (End_Indicator=="0") {
Total_Length	16 бит
}
If (Start_Indicator=="1"){
Protocol_Type	16 бит
If (Label_Type_lndicator=="00") {
6_Byte_Label	48 бит
} else if (Label_Type_lndicator=="01") {
3_Byte_Label	24 бита
}
If (Protocol_Type<1536) {
For(i=0;i<N2;i++) {
Extension_Header_Byte	8 бит
}
}
for(i=0;i<N3;i++){
PDU_data_byte	8 бит
}
If (Start_Indicator=="0") or (End_Indicator=="1") {
CRC_32	32 бита
}
}
}

[32] В приведенной выше таблице N1 может представлять собой количество байтов до конца кадра основной полосы частот и может быть установлено равным «О». Если параметры Startjndicator («индикатор начала»), End_Indicator («индикатор конца») и Label_Type_Indicator («индикатор типа метки») используют для заполнения, то их значение может быть задано равным «0»/«00». Значение N2 может представлять собой длину в байтах заголовков расширения в соответствии с описанием в запросе комментариев (Request for Comments) №4326 Рабочей группы инженеров Интернет, опубликованном в декабре 2005 года и озаглавленном «Однонаправленная легкая инкапсуляция (Unidirectional Lightweight Encapsulation, ULE) для передачи IP-датаграмм в транспортном потоке MPEG-2» ("Unidirectional Lightweight Encapsulation, ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream"), содержимое которого полностью включено в настоящий документ путем ссылки. Значение N3 может представлять собой длину в байтах инкапсулируемых PDU или фрагментов PDU.

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

[34] В соответствии с изображением на фиг.2, устройство или мобильное устройство 112 может включать по меньшей мере один процессор 128, имеющий соединение с пользовательским интерфейсом 130, по меньшей мере одно запоминающее устройство 134 и/или другое устройство хранения, а также дисплей 136, который может использоваться для отображения пользователю мобильного устройства видеоконтента, информации указателя услуг и т.п.Мобильное устройство 112 может также включать аккумулятор 150, громкоговоритель 152 и антенны 154. Пользовательский интерфейс 130 может дополнительно включать клавиатуру, сенсорный экран, голосовой интерфейс, одну или более клавиш-стрелок, джойстик, перчатку виртуальной реальности, мышь, трекбол и т.п. В некоторых вариантах осуществления настоящего изобретения в мобильном устройстве 12 могут присутствовать несколько процессоров и/или запоминающих устройств.

[35] Машиноисполняемые инструкции и данные, используемые процессором 128 и другими компонентами из состава мобильного устройства 112, могут храниться в машиночитаемом запоминающем устройстве 134. Запоминающее устройство может быть реализовано при помощи любой комбинации модулей памяти в режиме «только для чтения» или модулей памяти с произвольным доступом, опционально включающих как энергозависимую, так и энергонезависимую память. Программное обеспечение 140 может храниться в запоминающем устройстве 134 и/или устройстве хранения с целью обеспечения инструкциями процессора 128, чтобы мобильное устройство 112 было способно выполнять различные функции в соответствии с настоящим описанием. Альтернативно, все машиноисполняемые инструкции мобильного устройства 112, или их часть, могут быть реализованы в виде аппаратного или микропрограммного обеспечения (не показано на чертеже).

[36] Мобильное устройство 112 может быть сконфигурировано для приема, декодирования и обработки передач цифрового широкополосного вещания при помощи специального DVB-приемника 141, при этом упомянутые передачи могут быть основаны, к примеру, на стандарте цифрового видеовещания (DVB), например, на стандарте DVB-H (документ ETSI EN 302 304, V1.1.1 (2004-11)) или DVB-T (документ ETSI EN 300 744, V1.6.1 (2009-01)), или DVB-T2 (документ ETSI EN 302 755, V1.1.1 (2009-09)), содержимое которых полностью включено в настоящий документ путем ссылки. Мобильное устройство 121 может быть оснащено также и другими типами приемников цифрового широкополосного вещания и/или многоадресных передач. Дополнительно, мобильное устройство 112 может быть сконфигурировано для приема, декодирования и обработки передач при помощи радиоприемника 142 частотной модуляции (frequency modulated, FM) / амплитудной модуляции (amplitude modulated, AM), приемопередатчика 143 беспроводной локальной вычислительной сети (wireless local area network, WLAN), и телекоммуникационного приемопередатчика 144. В одном из аспектов, мобильное устройство 112 способно принимать сообщения потока данных радиовещания (radio data stream, RDS).

[37] Дополнительно, упомянутая цифровая передача может быть квантована по времени, как, например, в технологии DVB-H. Квантование по времени позволяет снизить среднее энергопотребление мобильного устройства 112, а также позволяет обеспечить плавный и беспроблемный хэндовер. Квантование по времени подразумевает передачу данных пачками импульсов с более высокой битовой скоростью, по сравнению с битовой скоростью передачи данных при использовании традиционного механизма потоковой передачи. В таком случае мобильное устройство 112 может иметь одно или более буферных запоминающих устройств для хранения декодированных передач, квантованных по времени, перед их презентацией.

[38] Фиг.3 иллюстрирует пример расположения сот, каждая из которых может обслуживаться собственным передатчиком. В обычной системе связи сота может задавать географическую область, покрываемую передатчиком. Сота может иметь любой размер, при этом рядом с ней могут быть расположены смежные соты. В настоящем примере сота №1 представляет собой географическую область, покрываемую передатчиком сети связи. Сота №2 расположена рядом с сотой №1 и представляет собой географическую область, покрываемую другим передатчиком. Сота №2 может, например, быть другой сотой в той же сети, что и сота №1. Альтернативно, сота №2 может находиться в сети, отличающейся от сети соты №1. Соты 1, 3, 4 и 5 в настоящем примере являются для соты №2 соседними сотами.

[39] Пропускная способность канала данных является ограниченным ресурсом, поэтому ее следует использовать максимально эффективно. Служебная информация (overhead) пакетов многих применяемых в настоящее время протоколов (например, протокола IP, протокола пользовательских датаграмм (UDP) и/или транспортного протокола реального времени (Real-time Transport Protocol, RTP) может иметь значительный объем, следовательно, ее передача может приводить к нерациональному расходованию ресурсов. Часто заголовки пакетов этих протоколов могут включать информацию, являющуюся статической (например, не изменяющейся) от пакета к пакету в потоке данных. Также упомянутые заголовки могут включать информацию, которую мобильное устройство 112 может вывести из других данных пакета, без необходимости их фактического приема. Остальные данные в этих пакетах можно назвать динамическими данными, они могут включать информацию, изменяющуюся от пакета к пакету в потоке данных.

[40] Передача статических данных и выводимых данных (данных, которые могут быть выведены из других данных), в заголовках пакета является нерациональной растратой пропускной способности. Для более эффективного использования пропускной способности передатчик 103 может применять протокол сокращения служебной информации в соответствии с описанием в настоящем документе с целью удаления, перед передачей в мобильное устройство 112, статических и выводимых данных из пакетов, принятых от источников 104 контента (которые называют «исходными пакетами»). Передатчик 103 может инкапсулировать динамические данные в заголовки протокола с формированием пакетов протокола. Например, упомянутые пакеты протокола могут представлять собой пакеты данных второго уровня. За счет отбрасывания статических и выводимых данных заголовок протокола может включать меньшее количество данных, по сравнению с исходным заголовком пакетов, что обеспечивает экономию пропускной способности. Примеры осуществления настоящего изобретения, описанные в настоящем документе, улучшают пропускную способность сети путем минимизации служебной информации протокола без снижения надежности доставки данных.

[41] Чтобы мобильное устройство 112 имело возможность восстановить исходные пакеты, передатчик 103 может формировать данные сигнализации на основе статических данных, удаленных из исходных пакетов. Эти данные сигнализации могут включать статические данные и информацию, указывающую на способ восстановления заголовков исходных пакетов на основе пакетов протокола. Данные сигнализации при этом могут передаваться в мобильное устройство 112 менее часто, чем исходные пакеты. Передатчик 103 может передавать данные сигнализации в мобильное устройство 112 вне полосы. Например, «вне полосы» может означать передачу по ранее установленному каналу связи или при помощи другого способа связи. Передача вне полосы может представлять собой передачу по логическому каналу, отличному от канала передачи пакетов протокола в мобильное устройство (например, сигнализация второго уровня (PSI/SI)). Передатчик 103 может затем формировать транспортный поток, включающий упомянутые данные сигнализации и пакеты протокола, для передачи в мобильное устройство 112. В процессе обнаружения услуг мобильное устройство 112 может выполнять анализ данных сигнализации из принимаемого транспортного потока и использовать их, вместе с заголовком протокола, для восстановления исходных пакетов из пакетов протокола.

[42] Фиг.4А-В иллюстрируют примеры осуществления заголовков протокола. В одном из примеров заголовок 400 протокола сжатия может иметь четыре заранее заданных поля: Compression Туре («тип сжатия») 402, Label Length («длина метки») 404, O-Flags («опциональные флаги») 406 и Protocol Label («метка протокола») 408. Заголовок 400 протокола, в зависимости от типа сжатия, применяемого к заголовку исходного пакета, может включать также дополнительные поля. Таблица 2, приведенная ниже, иллюстрирует примеры значений поля 402 Compression Туре («тип сжатия»), которое определяет тип применяемого сжатия; тем не менее, могут использоваться и другие значения, при этом может обеспечиваться сжатие заголовков и других протоколов.

Таблица 2
Поле Compression Туре («тип сжатия»)
Значение	Тип
000	Сжатие заголовка IPv4
001	Сжатие заголовка IPv6
010	Сжатие заголовка IPv4 и UDP
011	Сжатие заголовка IPv6 и UDP
100	Сжатие заголовка IPv4/UDP/RTP
101	Сжатие заголовка IPv6/UDP/RTP
110	Зарезервировано для будущего использования
111

[43] В одном из примеров осуществления настоящего изобретения протокол сжатия может сокращать служебную информацию протокола исходных пакетов, заголовки которых сформированы с использованием нескольких (одного или более) протоколов. Например, описанные в настоящем документе способы могут быть использованы для сокращения служебной информации протокола в случае исходного пакета с заголовком протокола Интернета версии 4 (IPv4), исходного пакета, одновременно включающего заголовки IPv4 и UDP, исходного пакета с заголовками IPv4, UDP и RTP и т.д.

[44] Поле Label Length («длина метки») может иметь фиксированный размер (к примеру, 1 бит) и может указывать на длину (например, в битах) поля Protocol Label («метка протокола») в заголовке 400 протокола. Фиг.4 А иллюстрирует пример осуществления заголовка 400 протокола с 8-битным полем 408 Protocol Label («метка протокола»), а фиг.4 В иллюстрирует пример осуществления заголовка 400 протокола с 16-битным полем 408 Protocol Label («метка протокола»). Таблица 3, приведенная ниже, иллюстрирует пример соответствия значений поля Label Length («длина метки») количеству бит поля Protocol Label («метка протокола»).

Таблица 3
Поле Label Length («длина метки»)
Значение	Тип
0	8-битное поле Protocol Label («метка протокола»)
1	16-битное поле Protocol Label («метка протокола»)

[45] Поле Protocol Label («метка протокола») может иметь фиксированную длину (например, 8 или 16 бит) и может содержать метку 408 протокола. Метка 408 протокола способна уникально идентифицировать один поток данных из заранее заданного количества потоков данных, передаваемых в канале. Например, 8-битная метка протокола может идентифицировать 256 уникальных потоков данных, а 16-битная метка протокола может идентифицировать до 65536 уникальных потоков данных. Канал может быть задан при помощи параметров PLP ID и TS PID, или при помощи PLP ID и GSE Label («метка GSE»). Передатчик 103 может назначать отношения взаимно однозначного соответствия между меткой 408 протокола и параметром TS PID - при использовании MPEG-2, или между меткой 408 протокола и меткой GSE - при использовании GSE. В одном из примеров метка 408 протокола может зависеть от значения в поле Compression Туре (СТ) («тип сжатия»). Поле Compression Туре может быть поставлено в соответствие адресам источника и назначения (к примеру, СТ: 000, 001) или адресу источника, адресу назначения, порту UDP источника и порту UDP назначения (например, СТ: 010, 011, 100, 101).

[46] При выполнении процедуры сокращения служебной информации протокола над исходным пакетом передатчик 103 может определять тип применяемого сжатия, назначать или получать метку 408 протокола и собирать пакет протокола путем удаления статических полей и включения метки 408 протокола. После приема такого пакета протокола мобильное устройство может использовать метку 408 протокола для определения и извлечения динамических данных из пакета протокола в соответствии с типом сжатия. Мобильное устройство 112 может после этого восстанавливать поля исходного пакета с использованием статических данных, полученных из данных сигнализации вне полосы, и извлеченных динамических данных. Мобильное устройство 112 может также определять выводимые данные, формируя их при помощи заранее заданных механизмов.

[47] Поле O-Flags («Опциональные флаги») может иметь фиксированный размер (например, 4 бита), при этом оно определяет наличие опциональных полей в заголовке 400 протокола. Опциональные поля могут присутствовать в случае их использования в исходном пакете. При формировании пакетов протокола передатчик 103 может добавлять любые опциональные поля из заголовка исходного пакета (например, опции протокола IP). Передатчик 103 может определять присутствие опциональных полей путем обработки флагов в заголовке исходного пакета (например, заголовке пакета IPv4 или IPv6). Эти флаги можно считать динамической информацией, и, следовательно, их необходимо включать в заголовок 400 протокола. Передатчик 103 может также определять, что опциональные поля исходного пакета не являются релевантными, и удалять их (например, если протокол IP является промежуточным протоколом передачи между маршрутизаторами), поскольку их используют редко из-за потенциально негативного влияния на соответствующие операции маршрутизации.

[48] Назначение битов поля O-Flags («опциональные флаги») может зависеть от используемого типа сжатия. Пример назначения битов для типов сжатия, равных 000, 010 и 100 может быть следующим. Первый бит флагов 406 опций может указывать, присутствуют (1) или нет (0) поля Identification («идентификатор») и Fragment offset («смещение фрагмента») в заголовке 400 протокола, второй бит может указывать, присутствует (1) или нет (0) поле Flag («флаг»), третий бит - присутствует (1) или нет (0) поле Header Length («длина заголовка»), и четвертый бит может быть установлен равным «0» и зарезервирован для будущего использования. Для типов сжатия, равных 001, 011 и 101 первый бит флагов 406 опций может применяться для указания, присутствует (1) или нет (0) поле Next Header («следующий заголовок») в заголовке 400 протокола, а оставшиеся три бита могут быть установлены равными «0» и зарезервированы для будущего использования. После удаления статических и выводимых данных передатчик 103 может инкапсулировать динамические данных в заголовок 400 протокола.

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

[50] К примеру, в DVB-системах для нахождения целевого потока данных мобильное устройство 112 может выполнять обнаружение услуг с целью определения одного или более потоков данных, имеющихся в транспортном потоке. Во время обнаружения услуг, выполняемого для нахождения целевого потока данных, мобильное устройство может обрабатывать определенный набор таблиц, передаваемых в транспортном потоке. Примеры таких таблиц могут включать таблицу PSI/SI, сетевую информационную таблицу (network information table, NIT), таблицу уведомления протокола IP (IP Notofication Table, INT), таблицу ассоциации программ (Program Association Table, PAT) и таблицу структуры программ (Program Map Table, PMT), каждая из которых описана, например, в документе ETSI EN 301 192 V.1.5.1 (2009-11), озаглавленном «Цифровое видеовещание (DVB); спецификация DVB для широковещательной передачи данных» ("Digital Video Broadcasting (DVB); DVB specification for data broadcasting"), содержимое которого полностью включено в настоящий документ путем ссылки. Эти таблицы могут предоставлять мобильному устройству 112 информацию о местоположении интересующего его потока данных в транспортном потоке, а также инструктировать устройство о способе обработки этого потока данных.

[51] Фиг.14 иллюстрирует пример блок-схемы алгоритма для способа обнаружения услуг мобильным устройством. В DVB-системах для нахождения IP-потока в транспортном потоке мобильное устройство 112 может выполнять анализ таблицы PSI/SI. Несмотря на то, что способ на фиг.14 описывает обнаружение именно IP-потока, этот способ может быть применен и к другим типам потоков данных.

[52] В блоке 1402 способ может включать прием транспортного потока мобильным устройством 112 от передатчика 103. В блоке 1404 способ может включать анализ транспортного потока мобильным устройством 112 с целью получения сетевой информационной таблицы (NIT), а также для определения идентификатора транспортного потока, идентификатора исходной сети, идентификатора услуги, а также идентификатора платформы, содержащей IP-потоки. В системах DVB-T2 транспортный поток может передаваться при помощи одного или более каналов физического уровня (Physical Layer Pipe, PLP). Транспортный поток может включать, в таблице NIT, дескриптор T2_delivery_system_descriptor (T2dsd) («дескриптор системы доставки Т2»), который устанавливает соответствие между транспортным потоком и PLP, передающим этот транспортный поток.

[53] В блоке 1406 способ может включать нахождение таблицы ассоциаций программ на основе идентификатора транспортного потока и идентификатора исходной сети, а также анализ этой таблицы ассоциаций программ с целью определения идентификатора пакета структуры программ, указывающего, в какой из таблиц структуры программ передается идентификатор услуги. В блоке 1408 способ может включать анализ таблицы структуры программ с целью нахождения идентификатора пакета элементарного потока, соответствующего дескриптору идентификатора широковещательной передачи данных, который содержит идентификатор платформы. В блоке 1410 способ может включать анализ мобильным устройством 112 таблицы уведомления протокола IP (INT), содержащей идентификатор пакета элементарного потока, с целью определения идентификатора транспортного потока, идентификатора исходной сети и тега компонента. В блоке 1412 способ может включать нахождение таблицы ассоциаций программ (PAT) на основе упомянутых идентификатора транспортного потока и идентификатора исходной сети, а также анализ упомянутой таблицы PAT с целью нахождения идентификатора структуры программ и таблицы структуры программ (РМТ), соответствующего искомому идентификатору услуги. В блоке 1414 способ может включать анализ таблицы РМТ с целью нахождения идентификатора элементарного пакета, связанного с дескриптором идентификатора потока, который соответствует упомянутому тегу компонента, при этом упомянутый идентификатор элементарного пакета указывает на пакеты транспортного потока, в которых передается секция многопротокольной инкапсуляции, содержащая искомую инкапсулированную IP-услугу. После этого выполнение способа может завершаться.

[54] Обрабатываемые таблицы, проиллюстрированные на фиг.14, могут информировать мобильное устройство 112 о факте нахождения интересующего его потока данных в транспортном потоке, а также инструктировать мобильное устройство 112 о способе обработки этого потока данных. В одн