Спосіб скорочення часу затримки збору даних управління шляхом передачі даних управління пакетами, що розшифровуються індивідуально

1. Спосіб скорочення часу затримки збору даних в мережі зв'язку, що включає: ідентифікацію даних управління, що приєднуються до переданої інформації; фрагментацію даних управління; та прив'язку кожного фрагмента даних управління до відповідної одиниці передачі переданої інформації. 2. Спосіб за пунктом 1, відповідно до якого одиниця передачі є пакетом фізичного рівня (PLP) суперкадру. 3. Спосіб за пунктом 1, відповідно до якого дані управління пов'язані із логічним каналом зв'язку MediaFLO (MLC). 4. Спосіб за пунктом 3, відповідно до якого дані управління включають дані схеми передачі Flo до каналу MLC. 5. Спосіб за пунктом 1, відповідно до якого бездротова передача інформації здійснюється через мережу у відповідності з принципами ортогонального частотного поділу сигналів. 6. Спосіб скорочення часу затримки збору даних в мережі зв'язку, що включає: отримання переданої інформації та пов'язаних даних управління, причому дані управління включають певну кількість фрагментів; та відновлення кожної одиниці отриманої переданої інформації, на основі відповідного фрагмента даних управління. 7. Спосіб за пунктом 6, відповідно до якого передана інформація та пов'язані дані управління отримуються за допомогою бездротового зв'язку. 8. Прилад для скорочення часу затримки збору даних в мережі зв'язку, що включає: 2 (19) 1 3 88685 4 логіку ідентифікації для ідентифікації даних управління, що приєднуються до переданої інформації; логіку фрагментації для фрагментації даних управління; та логіку прив'язки для приєднання кожного фрагмента даних управління до відповідної одиниці передачі переданої інформації. Передумови винаходу Вимога щодо визначення пріоритету відповідно до параграфу 119 Кодексу Законів США Дана Патентна заявка пред'являє свої вимоги щодо пріоритету по Заявці на патент США з тимчасовим номером 60/660.866, зареєстрованої 10 березня 2005 року, право на яку присвоєне правонаступнику даної заявки, а отже вона у повному обсязі включена до цієї заявки шляхом даного посилання. Сфера винаходу Даний винахід стосується ефективності передачі даних у мережі зв'язку. Зокрема, даний винахід стосується скорочення часу збору даних у бездротовій мережі зв’язку. Опис відповідної галузі Технологія односторонньої передачі даних FLO (Forward Link Only) розроблена перш за все для ефективного та економного розповсюдження однакового мультимедійного контенту мільйонам бездротових абонентів одночасно. Ціль технології FLO - скоротити витрати, пов’язані з доставкою такого контенту, а також дозволити користувачам переключати канали контенту на мобільних телефонах, що зазвичай використовуються для традиційних стільникових послуг з передачі голосу та даних. Цей мультимедійний контент також є відомим як послуги. Послуга є сполученням одного або більшої кількості незалежних компонентів даних. Кожен незалежний компонент даних послуги зветься потоком даних (flow). Послуги класифікуються у два типи, що грунтуються на їхньому покритті: Дальні зональні послуги та Локальні зональні послуги. Локальна зональна послуга представляє собою групову передачу для прийому в межах великого міста з передмістями. Дальні зональні послуги, навпаки, представляють собою групову передачу в межах одного або більшої кількості великих міст. Послуги FLO здійснюються по одному або кіTM льком логічним каналам, що відомі як MediaFLO Logical Channels (Логічні канали медіа зв'язку) або MLC. Канали MLC можуть поділятися максимум на три логічних підканали. Ці логічні підканали звуться інформаційними потоками (stream). Кожен потік даних переноситься по одному інформаційному потоку. Обробка каналів MLC в мережі FLO контролюється на основі даних Протоколу управління. Дані протоколу управління передаються в ефір по мережі в одиницях, що називаються пакетами фізичного рівня (PLP). В разі отримання помилкового пакету фізичного рівня, що несе фрагмент цих даних протоколу управління, прилад FLO зробить запит на іншу спробу отримати цілісні дані протоколу управління. Це призводить до збільшення часу очікування, поки прилад почне отримувати послугу. Таким чином, існує потреба у способі та системі, які б дозволили приладу FLO автономно розшифрувати та обробляти дані управління, що вкладені у індивідуальні пакети фізичного рівня (PLP). Короткий опис винаходу Відповідно до принципів даного винаходу, що втілені та докладно описані у цьому документі, даний винахід включає спосіб скорочення часу затримки збору даних у мережі зв’язку. Спосіб включає ідентифікацію даних управління, що приєднуються до переданої інформації, та фрагментацію ідентифікованих даних управління. Кожен фрагмент даних управління потім пов'язується з відповідною одиницею передачі переданої інформації. В одному з варіантів, передбачається використання апарату для скорочення часу затримки збору даних у мережі зв'язку. Апарат включає засоби ідентифікації даних управління, що приєднуються до переданої інформації, та засоби фрагментації даних управління. Передбачено засоби прив'язки для приєднання кожного фрагмента даних управління до відповідної одиниці передачі переданої інформації. В іншому варіанті, комп'ютерний програмний носій, що несе одну або більше послідовностей однієї або кількох команд для виконання одним або кількома процесорами, забезпечує спосіб скорочення часу затримки збору даних у мережі зв'язку. Команди, що виконуються одним або кількома процесорами, спонукають один або кілька процесорів виконувати етапи ідентифікації даних управління, що приєднуються до переданої інформації. Також виконуються етапи фрагментації даних управління та приєднання кожного фрагмента даних управління до відповідної одиниці передачі переданої інформації. У ще одному варіанті, процесор конфігурується з метою скорочення часу затримки збору даних в мережі зв'язку. Процесор включає логіку ідентифікації для ідентифікації даних, що приєднуються до переданої інформації. Процесор також включає логіку фрагментації для фрагментації даних управління та логіку прив'язки для приєднання кожного фрагмента даних управління до відповідної одиниці передачі переданої інформації. Одиниця передачі даних протоколу управління називається пакетом протоколу управління (СРР). Під час передачі даних в ефір, пакет СРР має. по суті, такий ж розмір, що й пакет PLP. Повідомлення протоколу управління, що несуть дані управління, фрагментуються таким чином, щоб кожен фрагмент містився всередині пакету протоколу 5 управління СРР. Дані заголовку додаються до кожного пакету СРР з метою донесення до одержувача усієї кількості пакетів, на які поділяються дані управління. Передбачено ідентифікатор пакетів СРР з метою інформування приладу про отримані пакети СРР. Відповідно до даного винаходу, повідомлення протоколу управління розроблені таким чином, щоб дозволити індивідуальному пакету СРР містити значущий логічний фрагмент повідомлення протоколу управління. Нижче докладно описуються інші особливості та переваги даного винаходу, а також структура та принципи роботи різних варіантів реалізації даного винаходу, з посиланням на супровідні Фігури. Короткий опис фігур Супровідні фігури, що включені у документ та є частиною даної специфікації, ілюструють варіанти втілення даного винаходу та, разом із вищезазначеним загальним описом і нижчезазначеним детальним описом різних варіантів, мають на меті пояснити принципи даного винаходу. Фігури включають: Фігура 1 представляє ілюстрацію мережі, що включає один з варіантів системи доставки контенту відповідно до даного винаходу; Фігура 2 представляє ілюстрацію одного варіанту провайдера контенту, що є придатним для використання у варіанті, зображеному на Фігурі 1; Фігура 3 представляє ілюстрацію одного варіанту сервера контенту, що є придатним для використання в одному з варіантів системи доставки контенту; Фігура 4 представляє ілюстрацію репрезентативного суперкадру переданого сигналу всередині мережі; Фігура 5 представляє ілюстрацію взаємозв'язку між потоком даних, інформаційним потоком, та логічним каналом зв'язку MLC відповідно до принципів варіанту реалізації винаходу; Фігура 6 представляє ілюстрацію зразка повідомлення сервісу ідентифікації (ID), структурованого відповідно до даного варіанту винаходу: Фігура 7 представляє ілюстрацію зразка повідомлення з описом потоку даних, структурованого відповідно до даного варіанту винаходу; Фігура 8 представляє ілюстрацію блок-схеми зразка способу вирішення проблеми затримки збору даних відповідно до одного з варіантів винаходу: Фігура 9 представляє більш детальну ілюстрацію структури пакету протоколу управління (СРР), зображеного на Фігурі 8; Фігура 10 представляє блок-схему зразка способу практичної реалізації варіанту винаходу; та Фігура 11 представляє блок-схему зразка системи відповідно до варіанту реалізації винаходу. Детальний опис винаходу Подальший детальний опис даного винаходу посилається па супровідні Фігури, які ілюструють зразки варіантів, що є сумісними з даним винаходом. Можливі інші варіанти, а також модифікації варіантів реалізації винаходу в дусі та в межах винаходу. Таким чином, наступний детальний опис не має на меті обмежити винахід. Радше обсяг 88685 6 винаходу визначається формулою винаходу, що додається. Дана специфікація розкриває один або кілька варіантів, що включають особливості даного винаходу. Розкритий варіант (-и) має на меті лише проілюструвати приклад даного винаходу. Обсяг винаходу не обмежується розкритим варіантом (ами). Винахід визначається формулою винаходу, що додається до нього. Варіант (-и), що описується, та посилання у специфікації на "один варіант", "варіант", "зразок варіанту", тощо, вказують на те, що варіант (-и), що описується, може включати специфічну особливість, структуру чи характеристику, проте кожен варіант не обов’язково має включати специфічну особливість, структуру чи характеристику. Крім того, такі фрази не обов'язково стосуються одного й того ж варіанту. Надалі, коли специфічна особливість, структура чи характеристика описані в зв’язку з варіантом, розуміється, що в межах знань будь-якого фахівця даної галузі реалізувати таку особливість, структуру чи характеристику в зв'язку з іншими варіантами, що були чи не були чітко описані. Для будь-якого кваліфікованого фахівця даної галузі буде очевидним, що даний винахід, як описано нижче, може бути реалізований у багатьох різних варіантах апаратного забезпечення, програмного забезпечення, вбудованих зашитих програмах та/або об'єктах, проілюстрованих на фігурах. Будь-яке існуюче системне програмне забезпечення із спеціалізованим контрольованим апаратним забезпеченням для реалізації винаходу не обмежує даного винаходу. Таким чином, робота та поведінка даного винаходу буде описана з розумінням того, що модифікації та зміни варіантів є можливими, з урахуванням рівня деталізації, представленого у цьому документі. На Фігурі 1 зображено мережу зв'язку 100, що включає систему транспортування, що функціонує з метою створення та транспортування потоків мультимедійного контенту через мережі даних. Наприклад, система транспортування є сумісною з принципами вищезазначеної системи FLO, та є придатною для використання з метою передачі фрагментів контенту із мережі провайдера контенту до мережі бездротового доступу для розповсюдження через зв'язок широкомовлення. Мережа 100 включає провайдера контенту (СР) 102, мережу провайдера контенту 104, оптимізовану мережу широкомовлення 106 та мережу бездротового доступу 108. Мережа 100 також включає прилади 110, які включають мобільний телефон 112, персональний кишеньковий комп'ютер (PDA) 114 та портативний комп'ютер 116. Прилади 110 ілюструють тільки деякі прилади, що є придатними для використання у системі транспортування. Слід зазначити, що хоча на Фігурі 1 зображено три прилади, фактично будь-яка кількість подібних приладів або типів приладів є придатною для використання у системі транспортування, що буде очевидним для кваліфікованих фахівців відповідної галузі. Провайдер контенту 102 надає контент для розповсюдження серед споживачів у мережі 100. 7 Контент охоплює відео, аудіо, мультимедійний контент, кліпи, контент у реальному та нереальному масштабі часу, скрипти, програми, дані або будь-який інший тип придатного контенту. Провайдер контенту 102 подає контент до мережі провайдера контенту 104 для розповсюдження. Наприклад, провайдер контенту 102 обмінюється даними з мережею провайдера контенту 104 через канал зв'язку 118, який охоплює будь-який придатний тип дротового та/або бездротового каналу зв'язку. Мережа провайдера контенту 104 включає будь-яку комбінацію дротових та бездротових мереж, які працюють на розповсюдження контенту з метою його доставки користувачам. Мережа провайдера контенту 104 обмінюється даними з оптимізованою мережею широкомовлення 106 через зв'язок 120. Зв’язок 120 включає будь-який придатний тип дротового та/або бездротового каналу зв'язку. Оптимізована мережа широкомовлення 106 включає будь-яку комбінацію дротових та бездротових мереж, розрахованих на передачу контенту високої якості. Наприклад, оптимізована мережа широкомовлення 106 може бути спеціалізованою приватною мережею, що була оптимізована для доставки контенту високої якості до обраних приладів через численні оптимізовані канали зв'язку. Система транспортування функціонує таким чином, щоб доставляти контент від провайдера контенту 102 для розповсюдження на сервер контенту (CS) 122 у мережі провайдера контенту 104, яка обмінюється даними з базового станцією широкомовлення (BBS) 124 у мережі бездротового доступу. Сервер контенту CS 122 та станція BBS 124 обмінюються даними з використанням одного або кількох варіантів інтерфейсу передачі даних 126, який дозволяє мережі провайдера контенту 104 доставляти контент у формі потоків контенту до мережі бездротового доступу 108 для широкомовлення/групової передачі до приладів 110. Інтерфейс передачі даних 126 включає інтерфейс управління 128 та канал носія 130. Інтерфейс управління 128 функціонує з метою забезпечення можливості для сервера контенту CS 122 додавати, змінювати, відміняти або іншим чином змінювати потоки контенту, що проходять від мережі провайдера контенту 104 до мережі бездротового доступу 108. Канал носія 130 функціонує з метою забезпечення транспортування потоків контенту від мережі провайдера контенту 104 до мережі бездротового доступу 108. Сервер контенту CS 122 використовує інтерфейс передачі даних 126 з метою планування потоку контенту, що передається до станції BBS 124 для широкомовлення/групової передачі через мережу бездротового доступу 108. Наприклад, потік контенту може включати кліп контенту у масштабі нереального часу, що був наданий провайдером контенту 102 для розповсюдження з використанням мережі провайдера контенту 104. Сервер контенту CS 122 узгоджує із станцією BBS 124 один або кілька параметрів, що приєднуються до кліпу контенту. Після отримання кліпу контенту станція BBS 124 здійснює передачу /групову передачу 88685 8 кліпу контенту через мережу бездротового доступу 108 для прийому одним або більшою кількістю приладів 110. Будь-який з числа приладів 110 може бути авторизованим для отримання кліпу контенту та поміщати його у кеш-пам’ять для подальшого перегляду користувачем приладу. У попередньому прикладі, прилад 110 включає програму клієнта 132, яка функціонує з метою забезпечення програмного довідника, що показує список контенту, запланованого для передачі через мережу бездротового доступу 108. Таким чином, користувач приладу може вибрати для отримання будь-який конкретний контент для виконання в реальному масштабі часу або для збереження у кеш-пам’яті 134 для наступного перегляду. Наприклад кліп контенту може бути запланований у розкладі для передачі протягом вечірніх годин, а прилад 112 функціонує з метою отримання передачі та кешування кліпу контенту в кеш-пам'ять 134 таким чином, щоб користувач приладу міг переглянути кліп наступного дня. Зазвичай, контент передається як частина абонементної послуги, а прилад, що отримує контент, має надати ключ або іншим чином підтвердити свою аутентифікацію, щоб отримати передачу. Система транспортування дозволяє серверу контенту CS 122 отримувати дані програмного довідника, програмний контент та іншу пов'язану інформацію від провайдера контенту 102. Сервер контенту 122 оновлює та/або створює контент для доставки до приладів 110. На Фігурі 2 зображено сервер провайдера контенту 200, що є придатним для використання в системі доставки контенту. Наприклад, сервер 200 може використовуватися, як сервер 102 на Фігурі 1. Сервер 200 включає логіку обробки даних 202, ресурси та інтерфейси 204, та логіку приймачапередавача 210, що усі приєднані до внутрішньої шини даних 212. Сервер 200 також включає логіку активації 214, програмний довідник (PG) 206 та логіку даних PG 208, що також приєднуються до шини даних 212. Логіка обробки даних 202 включає центральний процесор (CPU), процесор, матрицю логічних вентилів, логіку апаратного забезпечення, елементи пам'яті, віртуальну обчислювальну машину, програмне забезпечення та/або будь-яку комбінацію апаратного забезпечення та програмного забезпечення. Таким чином, логіка обробки даних 202 загалом включає логіку виконання машиночитаних команд та контролю одного або більшої кількості інших функціональних елементів сервера 200 через внутрішню шину даних 212. Ресурси та інтерфейси 204 включають апаратне забезпечення та/або програмне забезпечення, що дозволяє серверу 200 обмінюватися даними з внутрішніми та зовнішніми системами. Наприклад, внутрішні системи можуть включати системи масової пам’яті, пам'ять, драйвер відображення, модем або інші внутрішні апаратні ресурси. Зовнішні системи можуть включати прилади інтерфейсу користувача, принтери, дисководи або інші локальні прилади чи системи. Логіка приймач-передавача 210 включає логіку апаратного забезпечення та/або програмне забез 9 печення, що функціонує таким чином, щоб дозволити серверу 200 передавати та отримувати дані та/або іншу інформацію від дистанційних приладів або систем з використанням каналу зв'язку 216. Наприклад, канал зв'язку 216 включає будь-який придатний тип каналу зв'язку, що дозволяє серверу 200 обмінюватися даними з мережею даних. Логіка активації 214 включає центральний процесорний блок CPU, процесор, матрицю логічних вентилів, логіку апаратного забезпечення, елементи пам'яті, віртуальну обчислювальну машину, програмне забезпечення та/або будь-яку комбінацію апаратного забезпечення та програмного забезпечення. Логіка активації 214 функціонує таким чином, щоб активувати сервер контенту CS та/або прилад, щоб дозволити серверу CS та/або приладу вибирати та отримувати контент та/або послуги, що описуються в програмному довідникові PG 206. Логіка активації 214 передає програму клієнта 220 до сервера CS та/або приладу під час процесу активації. Програма клієнта 220 використовується на сервері CS та/або приладі з метою отримання PG 206 та відображення інформації про доступний контент або послуги для користувача приладу. Таким чином, логіка активації 214 забезпечує аутентифікацію сервера CS та/або приладу, а також завантажує клієнта 220 та завантажує PG 206 для виконання на приладі клієнтом 220. Програмний довідник PG 206 включає інформацію в будь-якому придатному форматі, що описує контент та/або послуги, які доступні для отримання приладами. Наприклад, PG 206 може, зберігатися у локальній пам’яті сервера 200 та може включати інформацію, таку як ідентифікатори контенту або послуг, інформацію планування, ціноутворення, та/або будь-який інший тип відповідної інформації. Довідник PG 206 включає одну або більше ідентифікованих секції, які оновлюються логікою обробки даних 202 відповідно до внесення змін у доступний контенту або послуги. Запис 208 довідника PG включає апаратне забезпечення та/або програмне забезпечення, що функціонує з метою генерування інформаційних повідомлень, які ідентифікують та/або описують зміни у довіднику PG 206. Наприклад, коли логіка обробки даних 202 оновлює PG 206, логіка даних PG 208 сповіщається про зміни. Після цього логіка даних PG 208 генерує одне або кілька інформаційних повідомлень, що передаються до серверів контенту CS, які, можливо, були активовані сервером 200, таким чином, щоб ці сервери CS швидко сповіщаються про зміни, внесені у довідник PG 206. В рамках інформаційного повідомлення про доставку контенту, передбачається індикатор передачі, що вказує на час, коли буде передана секція PG, ідентифікована в повідомленні. Наприклад, індикатор передачі може включати один біт, щоб вказати, що секція буде передаватися, та індикатор часу, який вказує, коли відбудеться передача. Таким чином, сервери CS та/або прилади, що мають намір поновити свою локальну копію даних довідника PG, можуть очікувати передачу у 88685 10 визначений час, щоб отримати оновлену секцію даних PG. В одному з варіантів, система повідомлення про доставку контенту включає програмні команди, що зберігаються на машино-читаному носієві, який, в разі виконання процесором, наприклад, логікою обробки даних 202, забезпечує описані тут функції сервера 200. Наприклад, програмні команди можуть завантажуватися на сервер 200 із машино-читаних носіїв, таких як дискета, CD-ROM, плата пам'яті, прилад пам'яті "FLASH", оперативна пам'ять (RAM), постійна пам'ять (ROM), або будьякий інший тип приладу пам'яті чи комп'ютерного носія, що має інтерфейс із сервером 200 через ресурси 204. В іншому варіанті, команди можуть завантажуватися на сервер 200 із зовнішнього приладу або мережевого ресурсу, що має інтерфейс із сервером 200 через логіку приймачапередавача 210. Програмні команди, під час виконання логікою обробки даних 202, забезпечують систему повідомлення щодо стану довідника, як описано тут. На Фігурі 3 зображено сервер контенту (CS) або прилад 300, придатні для використання в системі доставки контенту. Наприклад, сервер CS 300 може бути сервером контенту CS 122 або приладом 110, зображеним на Фігурі 1. Сервер CS 300 включає логіку обробки даних 302, ресурси та інтерфейси 304, та логіку приймача-передавача 306, усі приєднані до шини даних 308. Сервер CS 300 також включає клієнта 310, програмну логіку 314 та логіку програмного довідника PG 312, які також приєднуються до шини даних 308. Логіка обробки даних 302 включає центральний процесор (CPU), процесор, матрицю логічних вентилів, логіку апаратного забезпечення, елементи пам'яті, віртуальну обчислювальну машину, програмне забезпечення та/або будь-яку комбінацію апаратного забезпечення та програмного забезпечення. Таким чином, логіка обробки даних 302 загалом включає логіку виконання машиночитаних команд та контролю одного або більшої кількості інших функціональних елементів сервера CS 300 через внутрішню шину даних 308. Ресурси та інтерфейси 304 включають апаратне забезпечення та/або програмне забезпечення, що дозволяє серверу CS 300 обмінюватися даними з внутрішніми та зовнішніми системами. Наприклад, внутрішні системи можуть включати системи масової пам'яті, пам'ять, драйвер відображення, модем або інші внутрішні апаратні ресурси. Зовнішні системи можуть включати прилади інтерфейсу користувача, принтери, дисководи або інші локальні прилади чи системи. Логіка приймач-передавача 306 включає логіку апаратного забезпечення та/або програмне забезпечення, що функціонує таким чином, щоб дозволити серверу CS 300 передавати та отримувати дані та/або іншу інформацію від дистанційних приладів або систем через канал зв'язку 314. Наприклад, канал зв'язку 314 може включати мережевий канал зв'язку, бездротовий канал зв'язку або будьякий інший тип каналу зв'язку. Під час функціонування, сервер CS 300 активується таким чином, щоб він міг отримати досту 11 пний контент або послуги через мережу даних. Наприклад, сервер CS 300 ідентифікує себе для сервера провайдера контенту під час процесу активації. В рамках процесу активації, сервер CS 300 отримує та зберігає дані довідника PG за допомогою логіки PG 312. Програмний довідник PG 312 містить інформацію, яка ідентифікує контент або послуги, доступні для отримання сервером CS 300. Клієнт 310 функціонує з метою надання інформації відповідно до логіки PG 312 на сервер CS та/або прилад 300, використовуючи ресурси та інтерфейси 304. Наприклад, клієнт 310 видає інформацію відповідно до логіки PG 312 на екрані дисплею, який є частиною приладу. Клієнт 310 також отримує вхідні дані користувача через ресурси та інтерфейси таким чином, щоб користувач приладу міг вибрати контент або послуги. Сервер CS 300 отримує інформаційне повідомлення через логіку приймача-передавача 306. Наприклад, повідомлення можуть передаватися шляхом групової або одноадресної передачі до CS 300 та отримуватися логікою приймачапередавача 306. Інформаційні повідомлення PG ідентифікують оновлення даних PG в логіці PG 312. В одному з варіантів, клієнт 310 обробляє інформаційні повідомлення PG, щоб визначити, чи потребує оновлення локальна копія на логіці PG 312. Наприклад, в одному з варіантів, інформаційне повідомлення включає ідентифікатор секції, час випуску, термін дії та номер версії. Сервер CS 300 функціонує з метою порівняння інформації в повідомленнях PG з локально збереженою інформацією в існуючій логіці PG 312. Якщо сервер CS 300 визначає на основі повідомлень PG, що одна або кілька секції локальної копії в логіці PG 312 потребують оновлення, CS 300 виконує відповідну операцію для отримання оновлених секцій PG по одному з кількох шляхів. Наприклад, оновлені секції PG можуть передаватися у час, що вказано в повідомленнях PG, таким чином, щоб логіка приймача-передавача 306 могла отримати передачі та передати оновлені секції до сервера CS 300, який у свою чергу оновлює локальну копію в логіці PG 312. Сервер CS 300 визначає, які секції PG потребують оновлення на основі отриманих повідомлень щодо оновлення PG, та передає запит на сервер СР з метою отримання бажаних оновлених секції PG. Наприклад, запит може бути відформатованим з використанням будь-якого придатного формату та включати таку інформацію, як наприклад ідентифікатор запиту CS, ідентифікатор секції, номер версії та/або будь-яку іншу відповідну інформацію. Сервер CS 300 виконує одну або кілька наступних функцій в одному або кількох варіантах системи повідомлення PG. Слід зазначити, що наступні функції можуть змінюватися, перегруповуватися, модифікуватися, доповнюватися, вилучатися або іншим чином настроюватися в межах обсягу винаходу. 1. Сервер CS активується для роботи з системою провайдера контенту з метою отримання контенту або послуг. В рамках процесу активації, клієнт та довідник PG передаються до серверу CS. 88685 12 2. Одне або більше повідомлень PG отримується сервером CS та використовується для визначення, чи потребує оновлення одна або більше секції локально збереженого довідника PG. 3. В одному варіанті, якщо сервер CS визначає, що одна або кілька секції локально збереженого довідника PG потребують оновлення, сервер CS очікує передачу від системи розповсюдження з метою отримання оновлених секції PG, які йому потрібні для оновлення локальної копії. 4. В іншому варіанті, сервер CS передає одне або кілька повідомлень із запитом до провайдера контенту СР з метою отримання оновлених секції PG, які йому потрібні. 5. У відповідь на запит, СР передає оновлені секції довідника PG на сервер контенту CS. 6. Сервер CS використовує отримані оновлені секції PG для оновлення локальної копії довідника PG. Система доставки контенту включає програмні команди, що можуть зберігатися на машиночитаному носієві, який, в разі виконання процесором, наприклад, логікою обробки даних 302, забезпечує описані тут функції системи повідомлення про доставку контенту. Наприклад, команди можуть завантажуватися на сервер CS 300 із машино-читаних носіїв, таких як дискета, CD-ROM, плата пам'яті, прилад пам'яті "FLASH", оперативна пам’ять (RAM), постійна пам'ять (ROM), або будьякий інший тип приладу пам'яті чи комп'ютерного носія, що має інтерфейс із сервером CS 300 через ресурси та інтерфейси 304. В іншому варіанті, команди можуть завантажуватися на сервер CS 300 із мережевого ресурсу, що має інтерфейс із сервером CS 300 через логіку приймача-передавача 306. Програмні команди, під час виконання логікою обробки даних 302, забезпечують систему доставки контенту, як описано в цьому документі. Слід зазначити, що сервер CS 300 представляє лише один варіант реалізації і в межах обсягу винаходу можливі інші варіанти. На Фігурі 4 зображено репрезентативний суперкадр 400 переданого сигналу всередині мережі 100. З метою ілюстрації, передача сигналу через мережу 100 може відбуватися у відповідності з принципами мультиплексування з ортогональним частотним поділом сигналів (OFDM). Передані сигнали в мережі 100 організовуються у суперкадри, що є одиницями передачі даних на фізичному рівні мережі 100. Фахівцям даної галузі добре відомо, що фізичний рівень мережі забезпечує структуру каналу, частоту, вихідну потужність, модуляцію та специфікацію кодування для одностороннього зв'язку (Forward Link) мережі. Як зазначалося вище, мережа на основі зв'язку FLO 100 здійснює групову передачу кількох послуг в якості сукупності одного або кількох незалежних компонентів даних. Кожен незалежний компонент даних називається потоком і може включати відео компонент, аудіо компонент, текст чи сигнальний компонент послуги. Послуги FLO надаються через один або більшу кількість логічних каналів MLC. На прикладі, проілюстрованому на Фігурі 4, зображено репрезентативний суперкадр 400, що 13 включає заголовну частку 402 та частку даних 404. Частка даних 404 далі поділяється на кадри даних F1-F4. На фізичному рівні мережі 100, канали MLC передаються в рамках частки даних 404. На практиці, один MLC буде поділятися між кадрами даних F1-F4. У прикладі частки даних 404, зображеної на Фігурі 4, два MLC (10 та 20) поділяються між кадрами даних F1-F4. Тобто, одна четверта контенту кожного MLC 10 та 20 передається у кожному з кадрів F1-F4, відповідно. Наприклад, MLC, що має ідентифікацію (ID) 10 поділяється на частки 406а -406d, кожна з яких відповідає одному з кадрів F1-F4. Кадр F1 також включає частку MLC 408, яка відповідає MLC 20, в доповнення до частки 406а, яка відповідає MLC 10. Також, в межах частки даних 404, кожний із кадрів F1-F4 суперкадру 400 включає відповідні канали управління 410а- 410d, які несуть важливу інформацію щодо характеристик передачі відповідної частки каналів MLC (наприклад, MLC 10 та 20), включених до відповідного кадру. Заголовна частка 402 суперкадру 400 включає канал 412 символів заголовної інформації (OIS). Канал OIS 412, між іншим, інформує прилад 112 про місцезнаходження MLC 10 в рамках суперкадру 400. Таким чином, коли прилад 112 ініціює запит послуги, він має спершу розшифрувати канал OIS 412 в рамках суперкадру 400, щоб знати точне місцезнаходження та інші характеристики, що стосуються MLC 10, перш ніж дані в рамках MLC 10 можуть бути розпаковані та використовуватися. З іншої перспективи, MLC є логічним згрупуванням на фізичному рівні, що конфігурується для переносу унікальних даних. На прикладному рівні, дані, що також відомі як потоки, переносяться в одиницях, відомих як інформаційні потоки. Прикладний рівень надає послуги з метою забезпечення ефективного зв’язку між різними прикладними програмами в мережі. Інформаційні потоки у свою чергу переносяться каналами MLC. Наприклад, один MLC може переносити до трьох інформаційних потоків (тобто, до трьох різних потоків даних різного прикладного рівня). На Фігурі 5 проілюстровано взаємозв'язок між потоком даних (flow), інформаційним потоком (stream) та логічним каналом зв’язку MLC відповідно до принципів даного винаходу. На Фігурі 5 зразок схеми потоку 500 може включати інформацію, що завантажується на прилад 112 із мобільного відео сервісу 501, що надається, наприклад, Кабельною мережею новин (CNN). Дана передача CNN може включати дані прикладного рівня у формі відео потоку 502, аудіо потоку 504 та текстового потоку 506. Таким чином, кожен з потоків 502, 504 та 506, що переносить унікальні дані, буде передаватися у фізичному рівні мережі 100 в межах унікально ідентифікованого каналу MLC 10. На Фігурі 5, відео потік 502 пов'язаний з унікальною ідентифікацією (ID) потоку 100.0 та переноситься по каналу MLC 10. Аудіо потік 504 пов'язаний з ID потоку 100.1 та переноситься по MLC 20. Відповідно, текстовий потік 506 пов'язаний з ID потоку 100.2, але не зображений з прив'язкою до 88685 14 певного MLC. Подібним чином, мобільний відео сервіс 501, що надає CNN, пов'язаний з унікальним ID сервісу 100. Також на Фігурі 5 зображено зразок другої схеми потоку 510, що може включати сервіс 512, який надасться, наприклад, каналом кабельного телебачення ESPN. З метою ілюстрації,·сервіс ESPN 512 пов'язаний із сервісним ID 200. Сервіс ESPN 512 включає відео потік 514, що має ID потоку 200.0 та аудіо потік 516, що має ID потоку 200.1. На практиці, прилад 112 спершу робить запит на завантаження інформації, наприклад, від мобільної служби CNN 501. Перш ніж прилад 112 почне отримувати або відео потік 502 або аудіо потік 504, приладу 112 спершу має визначити схему передачі запитаних потоків (502 та 504) відповідно до пов'язаних з ними каналів MLC (MLC 10 та 20, відповідно), а потім отримати MLC 10 та 20 у фізичному рівні мережі 100. Інформація для здійснення цієї операції міститься в рамках каналу управління 410а. Шляхом перегляду, канал OIS 412 включає інформацію, пов'язану з місцезнаходженням MLC 10 та 20, до суперкадру 400. Крім того, канал OIS 412 включає інформацію, необхідну для надання підтримки приладу 112, з метою правильного розшифрування та отримання каналу управління 410а (що знаходиться в межах кожного із кадрів F1-F4). Канал управління 410а включає важливу інформацію щодо відображення потоку до MLC. Канал управління 410а також включає інформацію щодо характеристик передачі конкретного каналу MLC, як наприклад MLC 10 та 20, таким чином, щоб після визначення схеми потоку приладом 112, прилад 112 міг фізично настроїти та отримати канали MLC. Наприклад, частина цієї фізичної настройки може включати команди від приладу до фізичного рівня мережі 100 щодо того, як надсилати та отримувати пов'язані інформаційні біти, що пов’язані з одним з обраних потоків (наприклад відео потік 502 та/або аудіо потік 504), що передаються в ефір. Канал OIS 412, з іншого боку, має власний фіксований режим передачі. В якості прикладу, фіксований режим передачі, пов'язаний із суперкадром 400, включає квадратурну фазову модуляцію (QPSK) на рівні однієї п'ятої. Відразу після активації приладу 112, він миттєво знає режим передачі каналу OIS 412 та миттєво може настроїтися на нього. Після настройки на канал OIS 412, прилад 112 зчитує канал OIS 412 з метою отримання подальших команд відносно того, як отримати та розшифрувати канал управління 410а. Канал OIS 412 структурований таким чином, щоб вказати приладу 112, наприклад, що для того, щоб побачити канал управління 410а, прилад 112 має здійснювати передачу у відповідності із специфічними параметрами передачі. Здійснюючи передачу відповідно до цих специфічних параметрів, прилад 112 здатен отримувати дані від каналу управління 410а та дані його протоколу управління, а також читати схему передачі потоку до MLC. Канал управління 410а, зображений на Фігурі 4, 15 наприклад, включатиме повідомлення з описом потоку, що описує яким чином конкретні потоки, як наприклад відео потік 502 (ID потоку 100.0) та аудіо потік 504 (ID потоку 100.1), розподіляються па конкретні канали MLC. У прикладі суперкадру 400 на Фігурі 4, відео потік 502 (ID потоку 100.0) та аудіо потік 504 (ID потоку 100.1) розподіляються на MLC 10 та MLC 20, відповідно. Як тільки прилад 112 отримує дані протоколу управління у повному об'єму, включаючи повідомлення з описом потоку, він може розшифрувати та розпакувати канали MLC 10 та MLC 20 і забезпечити послугу для користувача. Фігура 6 представляє ілюстрацію зразка повідомлення сервісу ідентифікації (ID) 600, структурованого відповідно до даного варіанту винаходу. В мережі 100, ID сервісу та ID потоку, зображені на Фігурі 5, обоє пакуються в єдине 20 бітне повідомлення, що має частку ID сервісу 602 та частку ID потоку 604. Таким чином, у цьому прикладі повідомлення з описом потоку 600, єдиний ID сервісу, наприклад ID сервісу 100, що представляє CNN, може забезпечувати до 16 унікальних потоків даних. Повідомлення сервісу ID 600 приєднується до повідомлення з описом потоку даних, яке буде направлене приладам 110. Фігура 7 являє собою ілюстрацію зразка повідомлення з описом потоку даних 700 відповідно до даного винаходу. Як зображено на Фігурі 7, повідомлення з описом потоку даних 700 може бути пов'язане із ID 100 сервісу CNN, що показано на Фігурі 5. Таким чином, коли один з приладів 110, як наприклад прилад 112, отримує повідомлення з описом потоку даних 700, він спершу отримує ID потоку 100.0. ID потоку 100.0 (наприклад, відео) відображає схему передачі доMLC 10. Тепер, коли прилад 112 знає, що запитаний ним сервіс включено до MLC 10, він також знає, що для того, щоб отримати сервіс, йому необхідно конфігуруватися на режим передачі включаючи, наприклад, модуляцію QPSK на рівні однієї третьої. Інформація, що стосується режиму передачі, також включає інші параметри передачі, як наприклад схему кодування. Потім прилад 112 отримає ID потоку 100.1 (тобто, аудіо) та його схему передачі до MLC 20. Отже, прилад 112 отримує дані передачі, що вказують, наприклад, на те, щоб отримати MLC 20, прилад 112 повинен функціонувати з використанням квадратурної амплітудної модуляції (QAM) на рівні однієї половини. Після того, як прилад 112 починає здійснювати операції у відповідності з цією інформацією, він може почати завантажувати запитану інформацію сервісу. Перш ніж будь-які прилади 110 зможуть почати отримувати та розшифрувати будь-який специфічний канал MLC, необхідно у повному обсязі отримати дані протоколу управління з каналом управління 410а. У традиційних системах, дані управління можуть накопичуватися, внаслідок затримок збору даних, та можуть мати інтервал, що займає кілька суперкадрів. Таким чином, приладу може знадобитися кілька секунд, щоб завантажити усі дані управління та почати передавати послугу. Цей інтервал у кілька секунд збільшує ймовірність 88685 16 пошкодження або втрати цілісності даних управління. Якщо дані управління є пошкодженими або неповними у будь-який спосіб, прилад не може їх використовувати. Замість цього, прилад має чекати наступного суперкадру, щоб знову почати процес отримання OIS та каналів управління, що призводить до затримок надання послуги користувачеві. Повідомлення з описом потоку 700 передасться на фізичному рівні мережі 100. Фахівцям даної галузі добре відомо, що фізичний рівень мережі забезпечує структуру каналу, частоту, вихідну потужність, модуляцію та специфікацію кодування для одностороннього зв'язку. Всередині мережі 100, цей фізичний рівень відповідає за отримання MLC та передачу MLC в ефір. У традиційній мережі, MLC передається в ефір пакетами фізичного рівня (PLP). Дані від MLC для відповідного суперкадру можуть розбиватися, наприклад, на три пакети. Таким чином, кожен з трьох пакетів може передаватися в ефір індивідуально. На стороні одержувача, після отримання кожного з трьох пакетів, вони будуть об'єднані та прив'язані до певного MLC. Проте, існує проблема, якщо будь-який з пакетів був перерваний під час передачі (наприклад, внаслідок втрат передачі), увесь MLC буде непридатним. Таким чином, протягом перебігу повного періоду однієї секунди (обгрунтований інтервал часу для типового суперкадру), MLC має високу ймовірність пошкодження або переривання. Припустимо, наприклад, що один MLC може мати інтервал 12 пакетів PLP для передачі в ефір. Тоді, якщо будь-який з 12 пакетів PLP пошкоджується, ланцюг інформації MLC буде втрачено та прилад отримає буде змушений чекати наступного суперкадру, щоб повторити цей процес. Тобто, жоден з індивідуальних пакетів PLP традиційної мережі не має значущої інформації, незалежної від пакетів PLP, що не отримані, в межах послідовності. Даний винахід, як показано на приклади ілюстрації, зображеної на Фігурі 8, забезпечує засіб для вирішення цієї дилеми. Фігура 8 представляє ілюстрацію блок-схеми зразка способу 800, що дозволяє вирішити проблеми, пов'язані із затримкою збору даних, що мають місце у традиційних мережах. На Фігурі 8, канал MLC 802 включає сервісну інформацію, що запитувалася приладом, наприклад, приладом 112. Дані в межах каналу MLC 802 фрагментуються на 12 пакетів PLP 804 з метою підготовки для передачі в ефір. Кожен з 12 пакетів PLP позначається специфічною інформацією послідовності (фрагментації) 805 таким чином, що, якщо будьякий з пакетів PLP 804 втрачається під час передачі, пропущений пакет з числа PLP 804 може бути легко ідентифікований на стороні одержувача. Будь-який відсутній пакет PLP може згодом бути отриманий протягом повторної спроби передачі. Також, одержувач, в межах приладу 112, знає загальну кількість пакетів PLP, що необхідні для формування завершеного сегменту. На прикладі варіанту, зображеному на Фігурі 8, канал MLC 802 фрагментується на індивідуальні логічні одиниці, відомі як пакети протоколу управ 17 ління (СРР), наприклад СРР 806. Оскільки СРР 806 є власним логічним об'єктом, він включає придатну для використання інформацію, відокремлену від будь-якого іншого пакету СРР. Так само, наступна частка MLC 802 фрагментується з метою формування СРР 810, що є також окремо придатним для використання. Пакети протоколу управління (СРР) 808 та СРР 810 можуть передаватися окремо та отримуватися незалежно одне від одного. Тобто, частка MLC 802, що була фрагментована з метою формування СРР 808, може бути втрачена під час послідовності передачі. Якщо, однак, пакет СРР 810 не був втрачений та отриманий на стороні одержувача, частка MLC, що представлена СРР 808, буде придатна для використання. Оскільки кожен з пакетів СРР 806 та 810, та будь-які інші пакети в межах послідовності, є окремими логічними одиницями та придатні до незалежного використання, затримка збору даних може бути скорочена. Час затримки збору даних скорочується, оскільки, попри можливу втрату деяких пакетів фізичного рівня PLP під час передачі, ті пакети PLP, що дійсно були отримані, можуть використовуватися. Наприклад, якщо пакети PLP 3/12 та 4/12 PLP 804 були пошкоджені під час передачі, але інші пакети PLP 804 були отримані, прилад 112 все ще може отримати запитану послугу. У цьому прикладі, під час передачі наступного суперкадру, прилад 112 має запитати тільки відсутні пакети PLP 3/12 та 4/12. У варіанті, зображеному на Фігурі 8, пакети СРР 806 та 810 є по суті однаковими за довжиною з кожним PLP. Всередині мережі 100, пакети СРР переносяться на фізичному рівні мережі та конфігуруються таким чином, щоб бути сумісними з межами PLP. Фігура 9 представляє більш детальну ілюстрацію структури пакету протоколу управління (СРР) 806. Як зображено на Фігурі 9, СРР 806 включає заголовок пакету протоколу управління 900 та повідомлення протоколу управління 902. Заголовок 900 несе інформацію про фрагмент, який несе в собі пакет СРР 806 (наприклад, 1/12, 2/12, 5/12 т.д.), а також про специфічні дані або інформацію, яку він включає. Пакет СРР 806 також включає частку заповнення (тобто додавання бітів до блоку даних з метою його заповнення до потрібного розміру) каналу зв'язку 904. Наявність частки заповнення 904 передбачає, що під час спроби конфігурувати СРР 806 в якості логічної одиниці, остання частка заповнення 904 може не використовуватися для пакування фактичних даних. Фігура 10 представляє блок-схему зразка способу 1000 практичної реалізації варіанту даного винаходу. На Фігурі 8, з метою скорочення часу затримки збору даних у мережі зв'язку, одержувач бажано ідентифікує дані управління, що приєднуються до переданої інформації, як вказано на етапі 1002. Потім, дані управління фрагментуються, як зображено на етапі 1004, та кожен фрагмент буде пов'язаний із відповідною одиницею передачі переданої інформації, як вказано на етапі 1006. Фігура 11 представляє блок-схему зразка системи 1100 відповідно до варіанту реалізації вина 88685 18 ходу. На Фігурі 11 засоби ідентифікації 1102 ідентифікують дані управління, що приєднуються до переданої інформації. Засоби фрагментації 1104 фрагментують ідентифіковані дані управління. Засоби прив'язки 1106 потім приєднують кожен фрагмент до відповідної одиниці передачі переданої інформації. Даний винахід дає можливість приладу FLO незалежно обробляти дані управління, що приєднуються до індивідуальних пакетів PLP. Пакети PLP також можуть використовуватися та розшифровуватися індивідуально. Ця можливість незалежної обробки та розшифровки сприяє скороченню часу збору даних приладом FLO в мережі зв'язку на базі технології FLO. Даний винахід було описано вище за допомогою функціональних структурних блоків, що ілюструють виконання зазначених функцій та їх взаємозв'язок. Межі цих функціональних структурних блоків були довільно визначені для зручності опису. Альтернативні межі можуть визначатися за умови належного виконання зазначених функції та їх взаємозв'язків. Будь-які такі альтернативні межі не виходять за рамки обсягу та духу заявленого винаходу. Будь-хто з кваліфікованих фахівців даної галузі підтвердить, що ці функціональні структурні блоки можуть бути реалізовані за допомогою аналогових та/або цифрових схем, дискретних компонентів, спеціалізованих інтегральних схем, вбудованих мікропрограм, відповідного програмного забезпечення, що виконується процесором, тощо, або з використанням будь-якої комбінації цих засобів. Таким чином, об'єм та межі даного винаходу не повинні обмежуватися будь-якими вищеописаними зразковими варіантами, але повинні визначатися тільки у відповідності з наступною формулою винаходу та її еквівалентами. Попередній опис специфічних варіантів реалізації з такою повнотою виявляє загальну природу винаходу, що інші можуть, шляхом застосування знання даної галузі (включення зміст посилань, що цитуються в даному описі), легко змінити та/або пристосувати для різного прикладного використання ці специфічні варіанти, без потреби у недоречному експериментуванні та не відхиляючись від загальної концепції даного винаходу. Таким чином, мається на увазі, що ці пристосування та модифікації не виходять за межі значення та обсягу еквівалентів розкритих варіантів, що ґрунтуються на представлених тут настановах та принципах. Слід зазначити, що фразеологія або термінологія у даному документі вживається з метою опису, а не обмеження, таким чином, що термінологія або фразеологія даної специфікації має інтерпретуватися кваліфікованим фахівцем у світлі представлених тут настанов та принципів, у поєднанні зі знанням спеціаліста, що має звичайні навички у даній галузі. Розділ, що містить Детальний опис, має використовуватися в першу чергу для інтерпретації формули винаходу. Розділи, що містять Короткий опис та Реферат, можуть визначати один або кілька, але не всі приклади варіантів даного винаходу, що передбачені винахідником (винахідниками), а 19 отже, вони не мають на увазі обмежити формулу винаходу. Слід зазначити, що розділ, який містить Детальний опис, а не Короткий опис та Реферат, має розглядатися для інтерпретації формули винаходу. Розділи, що містять Короткий опис та Реферат, 88685 20 можуть визначати один або кілька, але не всі приклади варіантів даного винаходу, що передбачені винахідником (винахідниками), а отже, вони не мають на увазі жодним чином обмежити даний винахід та формулу винаходу, що додається. 21 88685 22 23 Комп’ютерна верстка Л.Литвиненко 88685 Підписне 24 Тираж 28 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601