Сокращение служебной информации протокола
Изобретение относится к области мобильной связи. Технический результат изобретения заключается в улучшении пропускной способности сети путем минимизации служебной информации протокола без снижения надежности доставки данных. Устройства и способы могут включать прием потока данных, включающего множество пакетов, определение статических данных и динамических данных в заголовках пакетов упомянутого множества пакетов, формирование множества пакетов протокола путем удаления упомянутых статических данных из заголовков пакетов с сохранением упомянутых динамических данных, формирование данных сигнализации на основе упомянутых статических данных и формирование транспортного потока, включающего упомянутые данные сигнализации и упомянутое множество пакетов протокола. 7 н. и 16 з.п. ф-лы, 4 табл., 22 ил.
Предпосылки создания изобретения
[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 о способе обработки этого потока данных. В одном из примеров передатчик 103 может включать данные сигнализации (например, дескриптор назначения, связанный с параметром IP/MAC_stream_location_descriptor («дескриптор местоположения потока IP/MAC)) в таблицу INT, информируя мобильное устройство 112 о статических данных и о том, как необходимо восстанавливать исходный пакет из переданного в транспортном потоке пакета протокола. Таблица INT может использоваться как набор указателей на активные и передаваемые потоки данных в транспортном потоке. Мобильное устройство 112 может находить дескриптор назначения, соответствующий интересующему его потоку данных. Этот дескриптор назначения может связывать адрес назначения из заголовка исходного пакета со значением в поле Protocol Label («метка протокола») в заголовке протокола на основе типа сжатия, использованного для сжатия исходного пакета. Мобильное устройство 112 с целью извлечения и восстановления исходных пакетов может использовать тип сжатия и метку 408 протокола для нахождения пакетов протокола, в которых передается интересующий его поток данных.
[55] Один из примеров дескриптора назначения представлен ниже в Таблице 4. В таблице 4 сначала перечислены поля (например, descriptor_tag («тег дескриптора»), descriptor_length («длина дескриптора»), compression_type («тип сжатия») и label_length («длина метки»), являющиеся общими для различных типов заголовков 400, а затем - поля с информацией, зависящей от конкретного применяемого типа сжатия.
| Таблица 4 | |
| Имя | Количество битов |
| taget_descriptor () { | |
| descriptor_tag | 8 |
| descriptor_length | 8 |
| compression_type | 3 |
| label_length | 1 |
| if(compression_type=000){ | |
| IPv4_destination_address | 32 |
| for(i=0;i<N;i++){ | |
| lPv4_source_address | 32 |
| Time_to_Live | 8 |
| Protocol | 8 |
| if(label_length==0) { | |
| Protocol Label | 8 |
| } else | |
| Protocol Label | 16 |
| } | |
| } | |
| } | |
| if(compression_type==001) { | |
| IPv6_destination_address | 128 |
| for(i=0;i<N;i++){ | |
| I Pv6_source_address | 128 |
| Flow_Label | 20 |
| Hop_Limit | 8 |
| if(label_length==0) { | |
| Protocol Label | 8 |
| } else | |
| Protocol Label | 16 |
| } | |
| } | |
| } | |
| if(compression_type==010) { | |
| IPv4_destination_address | 32 |
| for(i=0;i<N;i++){ | |
| I Pv4_source_address | 32 |
| Time_to_Live | 8 |
| Protocol | 8 |
| Ports_length | 8 |
| for(j=0;j<Ports_length;j++){ | |
| Udp_source_port | 16 |
| Udp_destination_port | 16 |
| if(label_length==0) { | |
| Protocol Label | 8 |
| } else | |
| Protocol Label | 16 |
| } | |
| } | |
| } | |
| if(compression_type==011) { | |
| IPv6_destination_address | 128 |
| for(i=0;i<N;i++){ | |
| I Pv6_source_address | 128 |
| Flow_Label | 20 |
| Hop_Limit | 8 |
| Ports Length | 8 |
| for(j=0;j<Ports_length;j++){ | |
| Udp_source_port | 16 |
| Udp_destination_port | 16 |
| if(label_length==0) { | |
| Protocol Label | 8 |
| } else | |
| Protocol Label | 16 |
| } | |
| } | |
| } | |
| if(compression_type==100) { | |
| IPv4_destination_address | 32 |
| for(i=0;i<N;i++){ | |
| IPv4_source_address | 32 |
| Time_to_Live | 8 |
| Protocol | 8 |
| Ports_length | 8 |
| for(j=0;j<Ports_length;j++){ | |
| Udp_source_port | 16 |
| Udp_destination_port | 16 |
| SSRC | 32 |
| Timestamp_offset | 32 |
| Sequence_Number_offset | 32 |
| if(label_length==0) { | |
| Protocol Label | 8 |
| } else { | |
| Protocol Label | 16 |
| } | |
| } | |
| } | |
| if(compression_type==101) { | |
| IPv6_destination_address | 128 |
| for(i=0;i<N;i++){ | |
| IPv6_source_address | 128 |
| Time_to_Live | 8 |
| Protocol | 8 |
| Ports_length | 8 |
| for(j=0;j<Ports_length;j++){ | |
| Udp_source_port | 16 |
| Udp_destination_port | 16 |
| SSRC | 32 |
| Timestamp_offset | 32 |
| Sequence_Number_offset | 32 |
| if(label_length==0) { | |
| Protocol Label | 8 |
| } else { | |
| Protocol Label | 16 |
| } | |
| } | |
| } | |
| } |
[56] Тег дескриптора (descriptor_tag) может представлять собой 8-битное поле, идентифицирующее целевой дескриптор в таблице INT. Таблица INT может включать несколько дескрипторов, различать которые помогает тег дескриптора. Длина дескриптора (descriptor_length) может представлять собой 8-битное поле, задающее общее количество байтов фрагмента данных целевого дескриптора, следующих за полем длины дескриптора. Тип сжатия (compression_type) может представлять собой 3-битное значение, задающее используемый тип сжатия в соответствии с предшествующим описанием в таблице 2. Длина метки (label_length), как описывалось ранее в таблице 3, может быть 1-битным значением, задающим длину в битах метки 408 протокола.
[57] За общими полями в дескрипторе назначения следуют поля, зависящие от конкретного используемого типа сжатия. Мобильное устройство 112 может определять используемый тип сжатия на основе поля 408 типа сжатия в заголовке 400 протокола и затем находить соответствующую информацию в дескрипторе назначения. В приведенной выше таблице 4 сначала перечислена информация для восстановления пакета IPv4 из пакета протокола, затем следует информация для восстановления пакета IPv6 из пакета протокола и т.д.
[58] Для пакета протокола, соответствующего исходному 1Ру4-пакету, адрес назначения IPv4 (IPv4_destination_address) может представлять собой 32-битное поле, содержащее адрес назначения, скопированный из заголовка IPv4, при этом адрес источника IPv4 (IPv4_source_address) может представлять собой 32-битное поле, содержащее адрес источника, скопированный из заголовка IPv4. Поле Time_to_Live («время существования») может быть 8-битным полем, содержащим значение Time_to_Live («время существования»), скопированное из заголовка IPv4. Поле Protocol («протокол») может быть 8-битным полем, содержащим значение Protocol («протокол»), скопированное из заголовка IPv4. Поле Protocol Label («метка протокола») может быть 8- или 16-битным полем, содержащим метку 408 протокола, сформированную или определенную передатчиком 103 при применении протокола сжатия к IPv4-пакету.
[59] Для пакета протокола, соответствующего исходному 1Ру6-пакету, адрес назначения IPv6 (IPv6_destination_address) может представлять собой 128-битное поле, содержащее адрес назначения, скопированный из заголовка IPv6. Адрес источника IPv6 (IPv6_source_address) может представлять собой 128-битное поле, содержащее адрес источника, скопированный из заголовка IPv6. Поле Flow_Label («метка потока») может быть 8-битным полем, содержащим значение поля Flow_Label («метка потока»), скопированное из заголовка IPv6. Поле Hop_Limit («предельное число шагов») может быть 8-битным полем, содержащим значение Hop_Limit («предельное число шагов»), скопированное из заголовка IPv6.
[60] Для пакета протокола, соответствующего исходному пакету с заголовками IPv4 и UDP или с заголовками IPv6 и UDP - в дополнение к описанной выше информации для IPv4 и IPv6 - поле Ports_length («длина портов») может быть 8-битным полем, задающим общее количество портов источника, портов назначения и полей меток, следующих за полем Ports_length («длина портов»). Поле Udp_source_port («UDP-порт источника») может быть 16-битным полем, содержащим значение Udp_source_port («UDP-порт источника»), скопированное из заголовка UDP. Поле Udp_destination_port («UDP-порт назначения») может быть 16-битным полем, содержащим значение Udp_destination_port («UDP-порт назначения»), скопированное из заголовка UDP.
[61] Для пакета протокола, соответствующего исходному пакету с заголовками IPv4, UDP и RTP или с заголовками IPv6, UDP и RTP, в дополнение к описанной выше информации для IPv4, IPv6 и UDP поле источника синхронизации (Synchronization source, SSRC) может быть 32-битным полем, содержащим значение SSRC из заголовка RTP-пакета.
[62] В дополнение к формированию данных сигнализации (например, рассмотренного выше дескриптора назначения) передатчик 103 может формировать транспортный поток, включающий эти данные сигнализации и пакеты протокола. В одном из примеров передатчик 103, с целью формирования транспортного потока, может мультиплексировать данные сигнализации и пакеты протокола. Передатчик 103 может инкапсулировать пакеты протокола в МРЕ-секции, которые затем передаются в пакетах транспортного потока. Транспортный поток может также передавать другие потоки данных. Передатчик 103 может обеспечивать передачу этого транспортного потока в мобильное устройство 112.
[63] Во время обнаружения услуг мобильное устройство 112 может принимать транспортный поток и анализировать данные сигнализации, соответствующие интересующему его потоку данных. Например, пользователь может применять мобильное устройство 112 для доступа к электронному указателю услуг (ESG) с целью нахождения множества доступных потоков данных. Мобильное устройство 112 может принимать пользовательский ввод для выбора целевого потока данных (например, видеопрограммы) из ESG. Например, мобильное устройство 112 может получать файл протокола описания сеанса (SDP), содержащий адрес назначения, который может быть использован для фильтрации доступных потоков данных. После этого мобильное устройство 112 может конфигурировать фильтрацию услуг для приема упомянутого интересующего его потока данных, например, настраиваться на прием пакетов, связанных с упомянутым адресом назначения. Затем мобильное устройство 112 может определять, используется ли транспортный поток MPEG-2. Если используется транспортный поток MPEG-2, то мобильное устройство 112 может ставить в соответствие IP-адрес назначения, IP-адрес источника и UDP-порты, с одной стороны, идентификатору канала физического уровня (PLP ID), идентификатору пакета транспортного потока (PID) и заголовку протокола, с другой стороны. Например, канал, в котором передается транспортный поток, может идентифицироваться идентификатором PLP и идентификатором пакетов транспортного потока (PLP ID и TS PID). Если вместо транспортного потока MPEG-2 была применена сигнализация, связанная с GSE, то мобильное устройство 112 может ставить в соответствие IP-адрес назначения, IP-адрес источника и UDP-порты идентификатору канала физического уровня (PLP ID), метке GSE и заголовку протокола сжатия. Например, канал, в котором передается транспортный поток, может идентифицироваться идентификатором PLP (PLP ID) и меткой GSE.
[64] Мобильное устройство 112 может настраиваться на канал, в котором передается транспортный поток, при этом оно может путем анализа выделять из этого транспортного потока данные сигнализации, содержащие пакеты протокола с интересующим его потоком данных. Мобильное устройство 112 может извлекать динамические данные путем удаления заголовка протокола из каждого пакета протокола. Затем мобильное устройство 112 может определять статические данных на основе упомянутых данных сигнализации и заголовка протокола, а также восстанавливать исходные пакеты на основе этих статических данных и динамических данных. Например, мобильное устройство 112 может быть проинформировано о структуре исходного пакета (например, ему может быть известно о структуре 1Ру4-пакета) и может применять информацию о структуре исходного пакета, данные сигнализации и заголовок 400 протокола с целью восстановления исходных пакетов на основе упомянутых статических данных и динамических данных.
[65] Также передатчик 103 может сжимать служебную информацию протокола путем сжатия динамических полей в исходных пакетах, включающих данные, которые изменяются от пакета к пакету предсказуемым образом. Например, некоторое значение в динамическом поле может изменяться от пакету к пакету на фиксированную величину. Значение динамического поля может включать относительно большое количество битов, тогда как изменение значение от пакета к пакету, в сравнении с абсолютной величиной значения, может быть малым. Передатчик 103 может сжимать значение динамического поля путем задания значения смещения, которое является статическим, и значения изменения, которое изменяется от пакета к пакету. Упомянутое значение смещения может представлять собой статические данные, которые удаляются из исходных пакетов и включаются в данные сигнализации. Упомянутое значение изменения может включаться в заголовок протокола для указания на величину изменения по отношению к предыдущему пакету. Значения смещения также могут изменяться время от времени, например, в циклически повторяющиеся моменты времени (например, когда счетчик достигает наибольшего значения и затем снова запускается с нуля). Передатчик 103 может обновлять значения смещения, представленные в данных сигнализации, поэтому мобильное устройство 112 может узнавать о новом значении смещения путем анализа новых данных сигнализации. После приема пакетов протокола мобильное устройство 112 может восстанавливать исходный заголовок путем комбинирования упомянутых значений смещения и значений изменения.
[66] Поле временной метки представляет собой один из примеров поля, данные которого изменяются от пакета пакету предсказуемым образом. Передатчик 103 может сжимать значение поля временной метки, присутствующего в последовательности исходных пакетов. Передатчик 103 может определять значение смещения для поля временной метки (например, TS_offset («смещение временной метки»), включаемое в данные сигнализации. Передатчик 103 может при этом определять включаемое в пакет протокола значение изменения (например, TS_delta («изменение временной метки»), изменяющееся от пакету к пакету. Например, заголовок пакета протокола может включать 32-битное поле timestamp_offset («смещение временной метки»). Для восстановления значения поля временной метки в каждом исходном пакете мобильное устройство 112 может принимать упомянутое значение смещения в данных сигнализации и комбинировать его со значением изменения в каждом пакете протокола (например, значение поля временной метки =TS_offset («смещение временной метки»)+TS_delta («изменение временной метки»)).
[67] Еще одним примером поля, данные которого изменяются от пакета к пакету предсказуемым образом, является поле порядкового номера. Передатчик 103 может определять смещение порядкового номера (SN_offset), которое включает статическую часть порядкового номера для включения в данные сигнализации. Например, порядковый номер может иметь 16 бит, из которых первые 6 бит будут SN_offset («смещение порядкового номера»), а последние 10 бит - динамической частью SN_delta («изменение порядкового номера»). Путем конкатенации значений SN_offset («смещение порядкового номера») и SN_delta («изменение порядкового номера») мобильное устройство 112 может определять порядковый номер при восстановлении исходных пакетов.
[68] Итак, передатчик 103 может выполнять сокращение служебной информации исходных пакетов путем удаления статических и выводимых данных с целью формирования пакетов протокола, при этом он может формировать данные сигнализации, включающие статические данные. Во время обнаружения услуг мобильное устройство 112 может определять интересующий его поток данных, который включает упомянутые пакеты протокола, получать данные сигнализации и восстанавливать исходные пакеты на основе этих данных сигнализации и пакетов протокола.
[69] Далее приведены подробные примеры применения описанной выше концепции способов сокращения служебной информации протокола для исходных пакетов, включающих различные типы заголовков. Фиг.5А-В иллюстрируют пакет IPv4 и пример пакета протокола, сформированного на основе этого пакета IPv4, фиг.6А-В иллюстрируют пакет IPv6 и пример пакета протокола, сформированного на основе этого пакета IPv6, фиг.7А-С иллюстрируют UDP-пакет и пример пакета протокола, сформированного на основе исходного пакета с заголовками UDP и IPv4, или UDP и IPv6, фиг.8А-С иллюстрируют примеры заголовков расширения для пакета IPv6, фиг.9А-В иллюстрируют пример пакета протокола, сформированного на основе исходного пакета, имеющего заголовки IPv4, UDP и RTP, или IPv6, UDP и RTP. При этом длина поля Protocol Label («метка протокола») на каждой из фиг.5В, 6В, 7В-С и 9А-В составляет 16 битов. Аналогичным образом может быть использовано 8-битное поле Protocol Label («метка протокола») - путем сдвига полей, следующих за полем Protocol Label («метка протокола») на 8 битов, это различие можно увидеть на фиг.4А-В. Ниже описано сжатие заголовков, используемых в протоколах UDP, IPv4, IPv6 и RTP, однако описанные в настоящем документе идеи могут применяться для заголовков, сформированных при помощи и других протоколов.
[70] Фиг.5А иллюстрирует структуру пакета и заголовка IPv4, а фиг.5В иллюстрирует пример пакета протокола с заголовком, сформированного путем применения к пакету IPv4 протокола сжатия, описанного выше. Первым полем в заголовке IP-пакета может быть четырехбитное поле Version («версия»). В случае IPv4 поле Version («версия») может иметь значение, равное 4. Поле Header Length («длина заголовка») может представлять собой длину в 32-битных словах заголовка IPv4 до точки начала поля Data («данные»). Поле Length («длина») может иметь минимальное значение (например, пять 32-битных слов), основанное на минимальном размере заголовка IPv4. Поле Type of Service («тип услуги») может обеспечивать указание на абстрактные параметры требуемого качества обслуживания. Поле Total Length («общая длина») может представлять собой общую длину пакета IPv4, измеренную в октетах, включая заголовок IPv4 и поле Data («данные»). Поле Identification («идентификатор») может представлять собой идентификационное значение, назначаемое источником 1Ру4-пакета для упрощения сборки фрагментов датаграммы. Поле Flags («флаги») может включать различные управляющие флаги. Поле Fragment Offset («смещение фрагмента») может указывать, где в датаграмме должен располагаться этот фрагмент. Поле Time to Live («время существования») может указывать на максимальное время, которое датаграмме разрешено оставаться в системе Интернет. Если значение поля Time to Live («время существования») равно нулю, то датаграмма может быть уничтожена. Поле Protocol («протокол») может указывать на протокол следующего уровня, использованный в предназначенной для данных части Интернет-датаграммы. Поле Header Checksum («контрольная сумма заголовка») может включать контрольную сумму заголовка IPv4. Поскольку некоторые из полей заголовка изменяются при передаче (например, поле Time to Live («время существования»)), поле Header Checksum («контрольная сумма заголовка») может вычисляться заново и проверяться в каждой точке, где выполняется обработка заголовка IPv4. Адресные поля источника и назначения могут составлять по 32 бита каждое и могут, соответственно, задавать адреса источника и назначения пакета IPv4. Поле Data («данные») может включать данные, передаваемые в этом IPv4-пакете.
[71] Фиг.5 В иллюстрирует пример пакета протокола со структурой заголовка, формируемой путем применения описанного выше протокола сокращения служебной информации к пакету IPv4. Для указания на то, что сжат был заголовок IPv4, поле Compression Туре («тип сжатия») (3 бита) может быть установлено равным определенному значению (например, 000). Поле Label Length («длина метки») (1 бит) может указывать длину метки 408 протокола. В настоящем примере поле Label Length («длина метки») может указывать на то, что метка 408 протокола составляет 16 битов. Поле O-Flags («опциональные флаги») (4 бита) может определять, присутствуют ли опциональные поля в структуре заголовка протокола. Например, если первый бит поля O-Flags («опциональные флаги») установлен равным 1, то в заголовке протокола могут присутствовать поля Identification («идентификатор») и Fragment Offset («смещение фрагмента»). Если этот бит установлен равным 0, то поля Identification («идентификатор») и Fragment Offset («смещение фрагмента») не включают в пакет протокола, поскольку пакет IPv4 не был фрагментирован. Другими словами упомянутые поля Identification («идентификатор») и Fragment Offset («смещение фрагмента») могут содержать значимые данные, только если пакет IPv4 был фрагментирован. В остальных случаях значения полей Identification («идентификатор») и Fragment Offset («смещение фрагмента») являются заранее заданными, и следовательно, содержат статические данные, которые могут быть удалены из заголовка протокола. Если второй бит поля O-Flags («опциональные флаги») установлен равным 1, то в заголовке протокола присутствует поле Flags («флаги»). Если третий бит установлен равным 1, то присутствует поле Header Length («длина заголовка») (например, если длина заголовка превышает пять 32-битных слов).
[72] Поле Label («метка») (8 или 16 бит) может содержать метку 408 протокола для пакета протокола. При использовании типа сжатия 000 метка 408 протокола может быть уникальной для любой заданной пары адреса источника IPv4 и адреса назначения IPv4. Метка 408 протокола позволяет осуществлять мультиплексирование 256 (в случае 8 бит) или 65536 (в случае 16 бит) различных потоков данных в один транспортный поток. Поскольку между адрес источника IPv4 и адрес назначения IPv4 уникально соответствуют метке 408 протокола, мобильное устройство 112 может извлекать из транспортного потока интересующий его поток данных. В поле Header Length («длина заголовка») первые 4 бита могут быть зарезервированы для будущего использования, а оставшиеся 4 бита могут содержать значение Header Length («длина заголовка»), скопированное из заголовка IPv4. Каждое из полей Type of Service («тип услуги») (8 бит), Identification («идентификатор») (16 бит), Flags («флаги») (8 бит) и Fragment Offset («смещение фрагмента») (8 бит) может быть скопировано из заголовка IPv4. Поле Flags («флаги») может включать информацию из поля Flags («флаги») в заголовке IPv4, при этом оно может быть расширено за счет зарезервированных битов и занимать 8 бит в структуре заголовка протокола.
[73] Если длина заголовка превышает пять 32-битных слов, может присутствовать поле Options («опции»). Размер поля Options («опции») может быть равен: (значение поля Header Field («длина заголовка») - 5) * 32 бита. Таким образом, для IPv4, поля Type of Service («тип услуги»), Identification («идентификатор»), Flags («флаги»), Fragment Offset («смещение фрагмента»), Header Length («длина заголовка») и Data («данные») могут включать динамические данные, в то время как остальные поля могут включать статические или выводимые данные, которые могут быть включены в данные сигнализации, задаваемые, вместо пакета протокола, проиллюстрированного на фиг.5 В, упомянутым дескриптором назначения. Каждое из полей, отмеченных как опциональные, может как использоваться, так и не использоваться в заголовке протокола. Если поле не используется, то структура заголовка может быть сжата (например, включать меньшее количество служебной информации), при этом поле Data («данные») в пакете протокола может начинаться раньше.
[74] Фиг.6А иллюстрирует структуру пакета и заголовка IPv6, а фиг.6 иллюстрирует пример пакета протокола, вместе со структурой его заголовка, формируемые путем применения к пакету IPv6 протокола сжатия служебной информации, описанного выше. Фиг.6А иллюстрирует заголовок IPv6, имеющий следующие поля. Поле Version («версия») может указывать версию Интернет-протокола, использованного для формирования Интернет-датаграммы. В данном примере поле Version («версия») может включать битовую последовательность «0110», представляющую собой закодированное число «6». Поле Traffic Class («класс трафика») может обозначать приоритет транспортируемых в пакете данных и может представлять собой 8-битное поле. Значения приоритета в поле Traffic Class («класс трафика») могут подразделяться на диапазоны: трафик, источник которого обеспечивает отслеживание перегрузок, и трафик без отслеживания перегрузок. Поле Flow Label («метка потока») может хранить 20 бит и обеспечивать управление качеством обслуживания (quality of service, QoS). Поле Flow Label («метка потока») может обеспечивать специальное обслуживание приложений реального времени. Поле Payload Length («длина полезной нагрузки») может указывать размер полезной информации в октетах (16 бит). Если данная опция обнулена, этот факт может указывать на опцию "Jumbo Payload" («джамбограмма») (например, hop-by-hop). Поле Next Header («следующий заголовок») может определять следующий протокол, инкапсулированный в исходном пакете. Значения поля Next Header («следующий заголовок») могут быть совместимы со значениями, используемыми для поля Protocol («протокол») (8 бит) IPv4. Заголовки расширения, если они присутствуют, можно рассматривать как часть полезной нагрузки, при этом их длина учтена в значении длины полезной нагрузки. Поле Hop Limit («предельное число шагов») может являться заменой полю Time to Live («время существования») (8 бит) IPv4. Каждое из полей Source address («адрес источника») и Destination address («адрес назначения») может составлять 128 бит и, соответственно, обозначать адреса источника и назначения для пакета IPv6. Поле Data («данные») может включать данные, передаваемые IPv6-пакетом.
[75] Фиг.6В иллюстрирует пример пакета протокола, сформированного путем применения к пакету IPv6 протокола сжатия служебной информации, описанного выше. Поле Compression Туре («тип сжатия») (3 бита») может быть установлено равным значению 001 для указания на то, что был сжат пакет IPv6. Поле Label Length («длина метки») (1 бит) может указывать длину в битах метки 408 протокола. В данном примере поле Label Length («длина метки») может указывать, что метка 408 протокола составляет 16 бит.Первый бит поля O-Flags («опциональные флаги») (4 бита) может указывать, присутствует (1) ли поле Next Header («следующий заголовок») или нет (0). Если оно задано равным 0, то мобильное устройство 112 может считать, что после поля Traffic Class («класс трафика») расположен UDP-пакет. Оставшиеся три бита поля O-Flags («опциональные флаги») могут быть установлены в ноль и могут быть зарезервированы для будущего использования. Поле Label («метка») (8 или 16 бит) может включать метку 408 протокола. Поле Traffic Class («класс трафика») (8 бит) может быть скопировано из заголовка IPv6. Поле Next Header («следующий заголовок») (8 бит) может быть опциональным, что задается полем O-Flags («опциональные флаги») и, если оно присутствует, может представлять собой значение, скопированное из заголовка IPv6. Если его нет, то длину заголовка пакета протокола уменьшают (например, он включает меньше служебной информации), при этом данные пакета начинаются раньше в пакете протокола. Поле Data («данные») может быть скопировано из поля Data («данные») пакета IPv6. В случае IPv6 поле Traffic Class («класс трафика»), поле Next Header («следующий заголовок») и поле Data («данные») могут включать динамические данные, при этом остальные данные могут считаться статическими или выводимыми и, следовательно, могут быть опущены. Поля, помеченные опциональными на фиг.6В, могут как использоваться, так и не использоваться. Если их не используют, то структура заголовка протокола может быть сжата (например, иметь меньше служебной информации) при поле Data («данные») в пакете протокола может начинаться раньше.
[76] Фиг.7А иллюстрирует UDP-пакет и структуру его заголовка, фиг.7В иллюстрирует пример структуры пакета протокола и его заголовка, сформированных путем применения к пакету, имеющему заголовки UDP и IPv4, протокола сжатия служебной информации, описанного выше, а фиг.7С иллюстрирует пример структуры пакета протокола и его заголовка, сформированных путем применения к пакету, имеющему заголовки UDP и IPv6, протокола сжатия служебной информации, описанного выше.
[77] Фиг.7А иллюстрирует пример структуры UDP-пакета. Поле Source Port («порт источника») может обозначать передающий порт и может являться портом для ответа, если он требуется. Если он не используется, значение поля Source Port («порт источника») может быть равным нулю. Поле Destination Port («порт назначения») может обозначать порт назначения UDP-пакета. Поле Length («длина») может представлять собой 16-битное поле, которое задает длину в байтах всего UDP-пакета (например, длину заголовка вместе с данными). Минимальная длина может быть длиной UDP-заголовка (например, 8 бит в примере фиг.7А). Размер этого поля для UDP-пакета может иметь теоретический предел в 65535 байт (например, 8 байт заголовка+65527 байт данных). Например, практический предел длины данных, которым ограничен протокол IPv4, равен 65607 байт. Поле Checksum («контрольная сума») может представлять собой 16-битное поле, используемое для контроля заголовка и данных на предмет наличия ошибок. Алгоритм вычисления контрольной суммы может быть различным при передаче по IPv4 или по IPv6. Если в IPv4 контрольная сумма опущена, то поле Checksum («контрольная сума») может быть заполнено нулями.
[78] Фиг.7 В иллюстрирует пример пакета протокола и структуры заголовка, сформированных путем применения описанного выше протокола сжатия служебной информации к пакету с заголовками IPv4 и UDP. Поле Compression Туре («тип сжатия») (3 бита») может быть установлено равным значению «010» для указания на то, что были сжаты заголовки IPv4 и UDP. Поле Label Length («длина метки») (1 бит) может указывать длину в битах метки 408 протокола. В данном примере поле Label Length («длина метки») может указывать, что метка 408 протокола составляет 16 битов. Поле 0-Flags («опциональные флаги») (4 бита) может задавать, присутствуют ли опциональные поля в заголовке протокола. Например, если первый бит поля O-Flags («опциональные флаги») установлен равным «1», то в пакете протокола присутствуют поля Identification («идентификатор») и Fragment Offset («смещение протокола»). Если второй бит поля O-Flags («опциональные флаги») установлен равным «1», то в пакете протокола присутствует поле Flags («флаги»). Если третий бит поля O-Flags («опциональные флаги») установлен равным «1», то в пакете протокола присутствует поле Header Length («длина заголовка»), и при этом его длина превышает пять 32-битных слов. Четвертый бит может быть установлен равным нулю и зарезервирован для будущего использования. Поле Label («метка») (8 или 16 бит) может определять метку 408 протокола.
[79] В поле Header Length («длина заголовка») первые 4 бита могут быть зарезервированы для будущего использования, а оставшиеся 4 бита могут содержать значение Header Length («длина заголовка»), скопированное из заголовка IPv4. Значения каждого из полей Type of Service («тип услуги») (8 бит), Identification («идентификатор») (16 бит), Flags («флаги») (8 бит) и Fragment Offset («смещение фрагмента») (8 бит) могут быть скопированы из заголовка IPv4. Поле Flags («флаги») может включать информацию из поля Flags («флаги») в заголовке IPv4, при этом оно может быть расширено за счет нескольких зарезервированных бит и занимать 8 бит в структуре заголовка протокола. Если длина заголовка превышает пять 32-битных слов, может присутствовать поле Options («опции»), при этом размер поля Options («опции») равен: (значение поля Header Field («длина заголовка») - 5) * 32 бита. Поле UDP Checksum («контрольная сумма UDP») (16 бит) может быть скопировано из заголовка UDP. Поле Data («данные») может включать данные, передаваемые в UDP-пакете. Таким образом, поле Type of Service («тип услуги»), поле UDP Checksum («контрольная сумма UDP»), поле Identification («идентификатор»), поле Flags («флаги»), поле Fragment Offset («смещение фрагмента»), поле Header Length («длина заголовка») и поле Data («данные») могут включать динамические данные для пакета, включающего заголовки IPv4 и UDP, а остальные поля можно считать статическими или выводимыми, и следовательно, можно опустить. Все поля, помеченные опциональными на фиг.7 В, могут как использоваться, так и не использоваться. Если их не используют, то структура заголовка протокола может быть сжата (например, иметь меньше служебной информации), при этом поле Data («данные») в пакете протокола могут начинаться раньше.
[80] Фиг.7С иллюстрирует пример пакета протокола и структуры заголовка, сформированных путем применения описанного выше протокола сжатия служебной информации к пакету с заголовками IPv6 и UDP. Поле Compression Туре («тип сжатия») (3 бита») может быть установлено равным значению «011» для указания на то, что были сжаты заголовки IPv6 и UDP. Поле Label Length («длина метки») (1 бит) может указывать длину в битах метки 408 протокола. В данном примере поле Label Length («длина метки») может указывать на то, что метка 408 протокола составляет 16 битов. Первый бит поля O-Flags («опциональные флаги») (4 бита) может указывать, присутствует (1) ли поле Next Header («следующий заголовок») или нет (0). Если оно задано равным 0, то мобильное устройство 112 может считать, что данные, принадлежащие UDP-пакету, начинаются поле поля UDP Checksum («контрольная сумма UDP»). Оставшиеся три бита поля O-Flags («опциональные флаги») могут быть установлены в ноль и могут быть зарезервированы для будущего использования. Поле Protocol Label («метка протокола») (8 или 16 бит) может включать метку 408 протокола. Поле Traffic Class («класс трафика») (8 бит), поле Next Header («следующий заголовок») (8 бит) и поле UDP Checksum («контрольная сумма UDP») (16 бит) могут быть скопированы из заголовка UDP. Поле Data («данные») может представлять собой данные, передаваемые в пакете UDP. Таким образом, поля Traffic Class («класс трафика»), UDP Checksum («контрольная сумма UDP»), Next Header («следующий заголовок») и Data («данные») могут включать динамические данные, при этом остальные поля пакета с заголовками UDP и IPv6 могут считаться статическими или выводимыми, и следовательно, могут быть опущены. Все поля, помеченные опциональными на фиг.7С, могут как использоваться, так и не использоваться. Если их не используют, то структура заголовка протокола может быть сжата (например, иметь меньше служебной информации) при этом поле Data («данные») в пакете протокола может начинаться раньше.
[81] В случае IPv6 опциональная информация Интернет-уровня может быть закодирована в отдельных заголовках, которые могут размещаться между заголовком IPv6 и заголовком более высокого уровня в пакете IPv6. Есть несколько подобных заголовков расширения, каждый из которых обозначается различным значением поля Next Header («следующий заголовок»). В соответствии с иллюстрацией в примерах осуществления настоящего изобретения на фиг.8А-С, пакет IPv6 может нести ноль (см. фиг.8А), один (см. фиг.8 В) или более расширенных заголовков (см. фиг.8С), каждый из которых обозначен полем Next Header («следующий заголовок») в предыдущем заголовке. Если пакет IPv6 включает один или более расширенных заголовков, то поле Compression Туре («тип сжатия») (см. фиг.7С) в заголовке протокола сжатия может иметь значение «011», при этом заголовки расширения могут размещаться между полем UDP Checksum («контрольная сумма UDP») и полем Next Header («следующий заголовок»).
[82] Фиг.9А иллюстрирует пример пакета протокола и структуры заголовка, сформированных путем применения описанного выше протокола сжатия служебной информации к исходному пакету с заголовками RTP, UDP и IPv4, а фиг.9А иллюстрирует пример пакета протокола и структуры заголовка, сформированных путем применения описанного выше протокола сжатия служебной информации к исходному пакету с заголовками RTP, UDP и IPv6. Поле Compression Туре («тип сжатия») может иметь значение «100» для указания на то, что были сжаты заголовки RTP, UDP и IPv4, или может иметь значение «101» для указания на то, что были сжаты заголовки RTP, UDP и IPv6. Все поля, помеченные как опциональные на фиг.9А-В, могут как использоваться, так и не использоваться. Если их не используют, то структура заголовка протокола может быть сжата (например, иметь меньше служебной информации), при этом поле Data («данные») в пакете протокола может начинаться раньше.
[83] RTP-поток может идентифицироваться IP-адресом и портом источника, а также IP-адресом и портом назначения. Поля «версия» (V) и «источник синхронизации» (SSRC) заголовка RTP могут считаться статическими. Поле V («версия») может обозначать версию применяемого RTP-протокола. Поле SSRC («источник синхронизации») может включать уникальный идентификатор источника синхронизации RTP-потока. Чтобы сохранить выравнивание байтов, поле V («версия») может обрабатываться как динамическое поле, а поле SSRC («источник синхронизации») может быть опущено в заголовке протокола и сигнализироваться за пределами полосы - в данных сигнализации.
[84] Следующие поля RTP могут считаться динамическими, поскольку они могут изменяться от пакету к пакету в течение сеанса RTP. Поле Padding (Р) («заполнение») может представлять собой 1-битный флаг, указывающий на присутствие заполняющих данных. Поле Extenstion (X) («расширение») может представлять собой 1-битный флаг, указывающий на присутствие расширения RTP-заголовка. Если бит в поле X («расширение») установлен, то поле Extension Header («заголовок расширения») может включать набор заголовков расширения. Мобильное устройство 112 может игнорировать заголовки расширения, при этом битовое поле X («расширение») может быть принудительно обнулено передатчиком 103 с целью удаления всех заголовков расширения RTP.
[85] Поле Contributing Source (CSRC) Count (CC) («счетчик содействующих источников») может представлять сбой 4-битное поле, указывающее количество содействующих источников для RTP-сеанса. Если поле СС («счетчик содействующих источников») не является нулевым, то в поле CSRC («содействующие источники») могут быть перечислены идентификаторы всех содействующих источников для текущего RTP-сеанса. Поле Marker (М) («маркер») может представлять собой 1-битный маркерный флаг, указывающий на последний пакет в блоке доступа. Поле Payload Туре (РТ) («тип полезной нагрузки») может представлять собой 7-битное поле, обозначающее конфигурацию медиаданных, применяемую в настоящий момент времени в RTP-сеансе.
[86] Следующие поля пакета RTP могут изменяться в каждом, или через несколько пакетов, и соответственно, считаться включающими динамические данные. Поле Sequence Number («порядковый номер») может задавать порядковый номер текущего RTP-пакета, начинающегося со случайным смещением. Вместо задания полного значения может использоваться смещение (см. также Таблицу 4 выше, параметр Sequence_Number_offset («смещение порядкового номера»)) для значения, которое указывается в данных сигнализации, что позволяет использовать для сигнализации порядкового номера в пакете протокола поле меньшего размера (например, 8 или 16 бит).
[87] Поле Timestamp («временная отметка») может задавать время представления передаваемых медиаданных в заданных часах медиаданных. Значение поля Timestamp («временная отметка») может начинаться со случайного смещения. Вместо сигнализации поля целиком применяют сигнализацию только смещения - как части данных сигнализации (см. также таблицу 4 выше, параметр timestamp_offset («смещение временной ометки»). Упомянутое смещение может быть представлено полем меньшего размера (например 16 бит) и циклически обнуляться, при условии, что информация в упомянутых данных сигнализации обновляется одновременно с этим.
[88] Фиг.9 В иллюстрирует пример структуры пакета и заголовка протокола, сформированных путем применения описанного выше протокола сжатия служебной информации к пакету с заголовками RTP, UDP и IPv6. Поле V («версия») может представлять собой 2-битное поле, скопированное из RTP-заголовка. Поле Р («заполнение») может представлять собой 1-битное поле, скопированное из RTP-заголовка. Поле X («расширение») может представлять собой 1-битное поле, скопированное из RTP-заголовка. Поле СС («счетчик содействующих источников») может представлять собой 4-битное поле, скопированное из RTP-заголовка. Поле РТ («тип полезной нагрузки») может представлять собой 7-битное поле, скопированное из RTP-заголовка. Поле Sequence Number («порядковый номер») может представлять собой 16-битное поле, скопированное из RTP-заголовка. Поле Timestamp («временная отметка») может представлять собой 32-битное поле, скопированное из RTP-заголовка. На этом завершается рассмотрение различных примеров применения протокола сжатия служебной информации для формирования пакетов протокола с целью уменьшения объема служебной информации в исходных пакетах. Выбранные протоколы являются всего лишь примерами, при этом допускается также использование и других протоколов.
[89] Фиг.10 иллюстрирует пример способа формирования транспортного потока, включающего пакеты протокола.
[90] В блоке 1002 способ может включать прием одного или более потоков данных от одного или более источников 104 контента. Передатчик 103 может принимать один или более потоков данных от одного или более источников 104 контента, при этом каждый поток данных может представлять собой поток исходных пакетов.
[91] В блоке 1004 способ может включать определение статических и динамических данных в заголовках упомянутых исходных пакетов каждого из потоков данных. Перед передачей в мобильное устройство 112 передатчик 103 может анализировать заголовки исходных пакетов каждого из потоков данных с целью определения статических данных и динамических данных.
[92] В блоке 1006 способ может включать формирование пакетов протокола путем удаления статических данных из упомянутых исходных пакетов с сохранением динамических данных, и путем инкапсуляции этих динамических данных в заголовок протокола. Для формирования значений полей заголовка 400 протокола передатчик 103 может обрабатывать заголовки упомянутых исходных пакетов. С целью формирования пакетов протокола передатчик 103 может инкапсулировать динамические данные в упомянутый заголовок протокола.
[93] В блоке 1008 способ может включать формирование данных сигнализации на основе упомянутых статических данных. На основе статических данных передатчик 103 может формировать дескриптор назначения в соответствии с предшествующим описанием.
[94] В блоке 1010 способ может включать формирование транспортного потока, включающего упомянутые данные сигнализации и пакеты протокола. Передатчик 103 может мультиплексировать или иным образом комбинировать упомянутые данные сигнализации и пакеты протокола. Упомянутый транспортный поток может включать также и другие потоки данных. При формировании транспортного потока передатчик 103 может независимо выполнять описанный протокол сжатия для исходных пакетов из каждого потока данных.
[95] В блоке 1012 способ может включать обеспечение передачи упомянутого транспортного потока по меньшей мере в одно приемное устройство, например, в мобильное устройство или терминал, телевизионную приставку/блок и т.п.Выполнения способа фиг.10 может после этого завершаться.
[96] Фиг.11 иллюстрирует пример блок-схемы алгоритма для способа определения целевого потока данных. Описанный на фиг.11 способ может реализовываться приемным устройством, например, мобильным устройством 112. В блоке 1102 способ может включать прием электронного указателя услуг, задающего множество доступных потоков данных. В блоке 1104 способ может включать прием пользовательского ввода для выбора целевого потока данных из упомянутого указателя услуг. В блоке 1106 способ может включать извлечение информации доступа, связанной с упомянутым целевым потоком данных. В блоке 1108 способ может включать конфигурирование фильтрации услуг с целью приема целевого потока данных. В блоке 1110 способ может включать определение, используется ли транспортный поток MPEG-2. Если да, то способ может переходить к блоку 1112, а если нет, способ может переходить к блоку 1114. В блоке 1112 способ может включать использование таблиц PSI/SI и таблицы INT для отображения IP-адреса назначения, IP-адреса источника и UDP-портов на идентификатор канала физического уровня (PLP ID), идентификатор пакета транспортного потока (PID) и заголовок протокола сжатия, а также определение статических данных для целевого потока данных на основе данных сигнализации. В блоке 1114 способ может включать отображение IP-адреса назначения, IP-адреса источника и UDP-портов на идентификатор канала физического уровня (PLP ID), метку GSE и заголовок протокола сжатия, а также определение статических данных для целевого потока данных на основе данных сигнализации. После блоков 1112 и 1114 способ может переходить к блоку 1116.
[97] В блоке 1116 способ может включать обработку целевого потока данных в транспортном потоке. В блоке 1118 способ может включать извлечение динамических данных из пакетов протокола путем удаления заголовка протокола из каждого пакета протокола. Например, мобильное устройство 112 может обрабатывать данные сигнализации с целью определения метки 408 протокола, соответствующей целевому потоку данных, а также может находить пакеты протокола, имеющие эту метку 408 протокола, в транспортном потоке. Мобильное устройство 112 может удалять заголовок протокола для извлечения динамических данных из пакетов протокола.
[98] В блоке 1120 способ может включать восстановление исходных пакетов на основе упомянутых статических данных и динамических данных. Например, мобильное устройство 112 может определять статические данные на основе данных сигнализации и может восстанавливать исходные пакеты (например, пакеты IPv4) на основе информации о структуре исходного пакета (например, о расположении полей пакета IPv4), упомянутых статических данных и упомянутых динамических данных. После этого выполнение способа фиг.11 может завершаться.
[99] Фиг.12 иллюстрирует пример блок-схемы алгоритма для способа обработки транспортного потока, сформированного при помощи способа фиг.10. Способ может начинаться в блоке 1202.
[100] В блоке 1202 может способ может включать прием транспортного потока, содержащего данные сигнализации и множество пакетов протокола. В одном из примеров мобильное устройство 112 может запускать обнаружение услуг путем настройки на канал, в котором передается транспортный поток. Этот транспортный поток может включать данные сигнализации, мультиплексированные вместе с множеством пакетов протокола
[101] В блоке 1204 способ может включать анализ данных сигнализации из транспортного потока с целью определения статических данных для целевого потока данных. Для нахождения целевого потока данных мобильное устройство 112 может анализировать данные сигнализации из упомянутого транспортного потока. Например, мобильное устройство 112 может сначала отображать ESG, в котором перечислены доступные потоки данных и, в ответ на пользовательский выбор, может находить дескриптор назначения для целевого потока данных. При помощи упомянутого дескриптора назначения мобильное устройство 112 может определять статические данные для этого целевого потока данных, включая метку 408 протокола. Затем мобильное устройство 112 может отфильтровывать целевой поток данных из транспортного потока с целью нахождения пакетов протокола, имеющих нужную метку 408 протокола.
[102] В блоке 1206 способ может включать извлечение динамических данных из пакетов протокола путем удаления заголовка протокола из каждого пакета протокола. Мобильное устройство 112 может удалять заголовок протокола с целью извлечения динамических данных из пакетов протокола, имеющих нужную метку 408 протокола.
[103] В блоке 1208 способ может включать восстановление исходных пакетов на основе упомянутых статических данных и динамических данных. Например, мобильное устройство может восстанавливать пакеты IPv4 на основе информации о структуре заголовка IPv4, статических данных и динамических данных. После этого выполнение способа фиг.12 может завершиться.
[104] Фиг.13 иллюстрирует один из примеров блок-схемы алгоритма для способа формирования пакетов протокола на основе сжатия поля порядкового номера в исходном RTP-пакете. Способ фиг.13 может реализовываться передатчиком 103. В блоке 1302 способ может включать извлечение порядкового номера (SN) из заголовка RTP-пакета. В блоке 1304 способ может включать извлечение статической части и динамической части из этого порядкового номера. Например, передатчик 103 может определять результат следующего уравнения:
[105] SN_delta=(SN - SN_offset)mod2ASN_bits,
[106] где SN - порядковый номер, SN_offset - смещение порядкового номера, mod2 - по модулю 2, a SN_bits - количество битов в поле SN («порядковый номер») (см. также фиг.9А).
[107] В блоке 1306 способ может включать определение, является ли значение SN_delta («изменение порядкового номера») нулевым. Нулевое значение SN_delta указывает на то, что изменений относительно предыдущего пакета нет. При нулевом значении способ может переходить к блоку 1308, в ином случае способ может переходить к блоку 1312.
[108] В блоке 1308 способ может включать обновление значения SN_offset («смещение порядкового номера»). Например, передатчик 103 может определять результат следующего уравнения.
[109] SN_offseti=SN_offset(i-10D+2∧SN_bits.
[110] Таким образом передатчик 103 может обновлять текущее значение SN_offseti в зависимости от предыдущего значения смещения SN_offset(M).
[111] В блоке 1310 способ может включать обновление значения метки 408 протокола.
[112] В блоке 1312 способ может включать вставку значения SN_delta («изменение порядкового номера») в заголовок пакета протокола. После этого выполнение способа фиг.13 может завершаться.
[113] Сокращение служебной информации протокола позволяет повысить эффективность использования полосы пропускания, по меньшей мере для однонаправленных каналов. При этом сжатая в соответствии с описанием в настоящем документе служебная информация протокола может не включать каких-либо межпакетных зависимостей, поэтому ошибка в восстановлении одного из исходных пакетов может не вызывать ошибки при восстановлении других исходных пакетов.
[114] Один или более аспектов настоящего изобретения могут быть выполнены в виде машиноисполняемых инструкций, например, в виде одного или более программных модулей, исполняемых одним или более компьютерами или иными устройствами. В общем случае программные модули включают процедуры, программы, объекты, компоненты, структуры данных и т.п., выполняющие определенные задачи или реализующие какие-либо абстрактные типы данных при исполнении процессором в компьютере или в ином устройстве. Упомянутые машиноисполняемые инструкции могут храниться на машиночитаемом носителе, например, на жестком диске, оптическом диске, на съемных носителях для хранения данных, в твердотельном запоминающем устройстве, RAM и т.п.Специалистам в данной области техники понятно, что в различных вариантах осуществления настоящего изобретения функциональность упомянутых программных модулей может при необходимости комбинироваться или распределяться. Также, упомянутая функциональность может быть реализована, полностью или частично, в виде микропрограммных или аппаратных эквивалентов, например, в виде интегральных схем, электрически программируемых вентильных матриц (field programmable gate arrays, FPGA), заказных интегральных схем (application specific integrated circuits, ASIC) и т.п.
[115] Варианты осуществления настоящего изобретения включают любую из описанных в настоящем документе отличительных особенностей изобретения или их комбинацию либо явным образом, либо как их обобщение. Варианты осуществления настоящего изобретения были описаны на основе конкретных примеров, несмотря на это специалистам в данной области техники должно быть понятно, что в описанных выше системах и способах возможны различные изменения и модификации. Таким образом, рамки настоящего изобретения следует толковать широко, в соответствии с изложенным в пунктах приложенной формулы изобретения.
1. Способ связи, включающий:
обработку потока данных, включающего множество пакетов;
определение, при помощи процессора, статических данных и динамических данных в заголовках пакетов упомянутого множества пакетов, при этом статические данные включают адрес источника или адрес назначения потока данных;
формирование множества пакетов протокола путем удаления упомянутых статических данных из заголовков пакетов и сохранения упомянутых динамических данных;
формирование данных сигнализации, включающих отображение адреса источника или адреса назначения на идентификатор логического канала, на основе упомянутых статических данных; и
передачу данных сигнализации с помощью логического канала, отличного от канала, используемого для передачи упомянутого множества пакетов протокола.
2. Способ по п.1, в котором заголовок каждого пакета из множества пакетов протокола включает метку протокола, которая связывает заголовок с упомянутыми данными сигнализации.
3. Способ по п.1, в котором формирование упомянутого множества пакетов протокола включает удаление выводимых данных из упомянутых заголовков пакетов.
4. Способ по п.1, в котором упомянутые статические данные являются одинаковыми в каждом пакете из множества пакетов в упомянутом потоке данных.
5. Способ по п.1, также включающий:
определение того, что каждый из упомянутых заголовков пакетов включает поле с динамической информацией; и
определение значения смещения и значение изменения на основе упомянутой динамической информации; при этом упомянутые данные сигнализации включают упомянутое значение смещения, а упомянутые динамические данные включают упомянутое значение изменения.
6. Способ по п.1, в котором упомянутые данные сигнализации являются частью информации об услугах или информации о программах, включенной в транспортный поток.
7. Передатчик, включающий:
по меньшей мере один процессор; и
по меньшей мере одно запоминающее устройство, хранящее исполняемые инструкции, которые при исполнении по меньшей мере одним процессором обеспечивают выполнение упомянутым передатчиком по меньшей мере следующего:
обработка потока данных, включающего множество пакетов;
определение статических данных и динамических данных в заголовках пакетов упомянутого множества пакетов, при этом статические данные включают адрес источника или адрес назначения потока данных;
формирование множества пакетов протокола путем удаления упомянутых статических данных из заголовков пакетов и сохранения упомянутых динамических данных;
формирование данных сигнализации, включающих отображение адреса источника или адреса назначения на идентификатор логического канала, на основе упомянутых статических данных; и
передача данных сигнализации с помощью логического канала, отличного от канала, используемого для передачи упомянутого множества пакетов протокола.
8. Передатчик по п.7, в котором заголовок каждого пакета из множества пакетов протокола включает метку протокола, которая связывает заголовок с упомянутыми данными сигнализации.
9. Передатчик по п.7, в котором формирование упомянутого множества пакетов протокола включает удаление выводимых данных из упомянутых заголовков пакетов.
10. Передатчик по п.7, в котором упомянутые статические данные являются одинаковыми в каждом пакете из множества пакетов в упомянутом потоке данных.
11. Передатчик по п.7, в котором упомянутые исполняемые инструкции, при их исполнении упомянутым по меньшей мере одним процессором, обеспечивают выполнение передатчиком следующего:
определение того, что каждый из упомянутых заголовков пакетов включает поле с динамической информацией; и
определение значения смещения и значения изменения на основе упомянутой динамической информации; при этом упомянутые данные сигнализации включают упомянутое значение смещения, а упомянутые динамические данные включают упомянутое значение изменения.
12. Машиночитаемый носитель, хранящий исполняемые инструкции, которые, при их исполнении, обеспечивают выполнение устройством по меньшей мере следующего:
обработка потока данных, включающего множество пакетов;
определение статических данных и динамических данных в заголовках пакетов упомянутого множества пакетов, при этом статические данные включают адрес источника или адрес назначения потока данных;
формирование множества пакетов протокола путем удаления упомянутых статических данных из заголовков пакетов и сохранения упомянутых динамических данных;
формирование данных сигнализации, включающих отображение адреса источника или адреса назначения на идентификатор логического канала, на основе упомянутых статических данных; и
передача данных сигнализации с помощью логического канала, отличного от канала, используемого для передачи упомянутого множества пакетов протокола.
13. Способ связи, включающий:
обработку транспортного потока, который включает данные сигнализации и множество пакетов протокола, при этом данные сигнализации связаны с логическим каналом, отличным от канала, связанного с упомянутым множеством пакетов протокола;
выделение, при помощи анализа процессором, упомянутых данных сигнализации из упомянутого транспортного потока, при этом данные сигнализации включают отображение адреса источника или адреса назначения на логический канал;
удаление заголовка протокола из каждого из множества пакетов протокола для извлечения динамических данных;
определение статических данных, включающих адрес источника или адрес назначения, на основе упомянутого отображения; и
восстановление множества пакетов на основе упомянутых статических данных и динамических данных.
14. Способ по п.13, в котором упомянутое восстановление множества пакетов основано на заранее заданной информации, указывающей на структуру упомянутого множества пакетов.
15. Способ по п.13, также включающий:
обеспечение представления указателя услуг;
прием выбора программы, связанной с упомянутым множеством пакетов протокола.
16. Способ по п.13, в котором упомянутое восстановление упомянутого множества пакетов основано также на выводимых данных.
17. Способ по п.13, в котором упомянутые данные сигнализации являются частью информации об услугах или информации о программах, включенной в упомянутый транспортный поток.
18. Мобильное устройство, включающее
по меньшей мере один процессор; и
по меньшей мере одно запоминающее устройство, хранящее исполняемые инструкции, которые при исполнении по меньшей мере одним процессором обеспечивают выполнение упомянутым устройством по меньшей мере следующего:
обработка транспортного потока, который включает данные сигнализации и множество пакетов протокола, при этом данные сигнализации связаны с логическим каналом, отличным от канала, связанного с упомянутым множеством пакетов протокола;
выделение, при помощи анализа процессором, упомянутых данных сигнализации из упомянутого транспортного потока, при этом данные сигнализации включают отображение адреса источника или адреса назначения на логический канал;
удаление заголовка протокола из каждого из множества пакетов протокола для извлечения динамических данных;
определение статических данных, включающих адрес источника или адрес назначения, на основе упомянутого отображения; и
восстановление множества пакетов на основе упомянутых статических данных и динамических данных.
19. Мобильное устройство по п.18, в котором обеспечение выполнения упомянутым устройством восстановления упомянутого множества пакетов включает обеспечение выполнения упомянутым устройством восстановления, основанного на заранее заданной информации, указывающей структуру упомянутого множества пакетов.
20. Мобильное устройство по п.18, в котором упомянутые исполняемые инструкции, при их исполнении упомянутым по меньшей мере одним процессором, обеспечивают выполнение устройством следующего:
обеспечение представления указателя услуг; и
прием выбора программы, связанной с упомянутым множеством пакетов протокола.
21. Мобильное устройство по п.18, в котором обеспечение выполнения упомянутым устройством восстановления множества пакетов включает обеспечение выполнения упомянутым устройством восстановления множества пакетов, основанного на выводимых данных.
22. Машиночитаемый носитель, хранящий исполняемые инструкции, которые, при их исполнении, обеспечивают выполнение устройством по меньшей мере следующего:
обработка транспортного потока, который включает данные сигнализации и множество пакетов протокола, при этом данные сигнализации связаны с логическим каналом, отличным от канала, связанного с упомянутым множеством пакетов протокола;
выделение, при помощи анализа процессором, упомянутых данных сигнализации из упомянутого транспортного потока, при этом данные сигнализации включают отображение адреса источника или адреса назначения на логический канал;
удаление заголовка протокола из каждого из множества пакетов протокола для извлечения динамических данных;
определение статических данных, включающих адрес источника или адрес назначения, на основе упомянутого отображения; и
восстановление множества пакетов на основе упомянутых статических данных и динамических данных.
23. Система связи, включающая:
передатчик, включающий:
процессор; и
запоминающее устройство, хранящее исполняемые инструкции, которые при исполнении упомянутым процессором обеспечивают выполнение передатчиком по меньшей мере следующего:
обработка потока данных, включающего множество пакетов;
определение статических данных и динамических данных в заголовках пакетов упомянутого множества пакетов, при этом статические данные включают адрес источника или адрес назначения потока данных;
формирование множества пакетов протокола путем удаления упомянутых статических данных из заголовков пакетов и сохранения упомянутых динамических данных;
формирование данных сигнализации, включающих отображение адреса источника или адреса назначения на логический канал, на основе упомянутых статических данных;
передача данных сигнализации с помощью логического канала;
передача упомянутого множества пакетов протокола с помощью канала, отличного от логического канала; и
приемник, включающий:
процессор; и
запоминающее устройство, хранящее исполняемые инструкции, которые при исполнении упомянутым процессором обеспечивают выполнение упомянутым приемником по меньшей мере следующего:
обработка транспортного потока, который включает данные сигнализации и множество пакетов протокола;
выделение, путем анализа, упомянутых данных сигнализации из упомянутого транспортного потока;
удаление заголовка протокола из каждого из множества пакетов протокола для извлечения динамических данных;
определение статических данных на основе упомянутого отображения; и
восстановление множества пакетов на основе упомянутых статических данных и динамических данных.
