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

1. Спосіб децентралізованого керування доступом до середовища передавання даних у персональній бездротовій мережі зв'язку (300), що об'єднує множину пристроїв (301), який включає такі операції: розділення часу на не менш ніж один суперкадр (100); причому всі пристрої (301) періодично передають пакети-маячки (400); і передавання першим пристроєм (301), що належить до згаданої множини пристроїв, у суперкадрі (100) в очікуваний момент часу передавання пакета-маячка (ТВТТ) (201) пакета-маячка (400), що містить інформацію про резервування часу для запланованого на даний суперкадр передавання даних певним пристроєм-відправником (301); враховування даного резервування всіма пристроями (301), що приймають пакет-маячок (400), який містить інформацію про дане резервування; групування пакетів-маячків (400), переданих кожним зі згаданої множини пристроїв (301) у суперкадрі (100), у щонайменше один період (101) пакетів-маячків; причому згаданий перший пристрій (301) і є відправником (301) у запланованому передаванні даних, а спосіб додатково включає такі операції: а) включення відправником (301) інформації про резервування в пакет-маячок (400) кожного суперкадру (100), впродовж якого дане резервування є дійсним; і 2 (19) 1 3 одержувачем у згадану DRP-відповідь (1100) або щонайменше однієї пропозиції щодо альтернативного вільного інтервалу часу для резервування, або інформації про щонайменше один альтернативний вільний інтервал часу у суперкадрі (1105). 6. Спосіб за п. 1, який додатково включає етап включення в пакет-маячок (400), що передається першим пристроєм (301), часу початку резервування, визначеного відносно опорного моменту часу (705) (711), вибраного з групи, до якої входять момент часу ТВТТ (201) першого пристрою (301), BPST (201) - момент часу початку періоду пакетів-маячків, в який перший пристрій (301) передає пакет-маячок (400), момент часу початку суперкадру (205), певний період часу у суперкадрі (100) і певний слот суперкадру (205). 7. Спосіб за п. 6, який відрізняється тим, що: час початку резервування визначають відносно згаданого опорного моменту часу (705) (711) наступного суперкадру (206), в якому згаданий перший пристрій (301) передаватиме свій наступний пакет-маячок (400); і згаданий щонайменше один альтернативний вільний інтервал часу для резервування, якщо він пропонується пристроєм-одержувачем, визначається відносно опорного моменту часу (705) (711) в наступному суперкадрі (206), в якому згаданий пристрій-одержувач передаватиме свій наступний пакет-маячок (400). 8. Спосіб за п. 1, який додатково включає ведення кожним пристроєм, що належить до згаданої множини пристроїв, таблиці всіх запланованих резервувань (306), інформацію про які одержав або відправив даний пристрій. 9. Спосіб за п. 1, який додатково включає такі етапи: передавання пристроєм (301), який є одержувачем у згаданому резервуванні, пакета-опитування пристрою-відправнику (301); передавання пристроєм-відправником (301) після отримання цього пакета-опитування щонайменше одного пакета даних у пристрій-одержувач (301); і підтвердження пристроєм-одержувачем (301) приймання щонайменше одного пакета даних шляхом передавання пакета-підтвердження (АСК). 10. Спосіб за п. 1, який додатково включає такі етапи: визначення згаданого суперкадру як такого, що складається з множини слотів доступу до середовища передавання даних; і визначення резервування через перший слот (705) (711), що належить до згаданої множини слотів доступу до середовища передавання даних, і тривалість (706) (712), виражену у кількості слотів доступу до середовища передавання даних. 11. Спосіб за п. 1, який додатково включає такі етапи: визначення згаданого суперкадру як такого, що складається з множини проміжків часу; і визначення резервування через початковий момент часу, виражений в таких проміжках часу (705) (711), і тривалість (706) (712), виражену у кількості таких проміжків часу. 12. Спосіб за п. 1, який додатково включає такі етапи: 93028 4 визначення згаданого суперкадру як такого, що складається з множини слотів доступу до середовища передавання даних; і визначення резервування за допомогою щонайменше одного біта у бітовому масиві (708) (712), що містить щонайменше один біт на кожний слот доступу до середовища передавання даних, що належить до згаданої множини слотів доступу до середовища передавання даних. 13. Спосіб за п. 1, який додатково включає такі етапи: визначення згаданого суперкадру як такого, що складається з множини слотів доступу до середовища передавання даних; і визначення резервування за допомогою щонайменше одного з переліченого: період (705) (710) резервування, зсув (705) (711) резервування, зсув (705) (710) (711) періоду резервування, тривалість резервування, бітовий масив (706) (712), що відображає щонайменше один слот доступу до середовища передавання даних і тип (709) резервування. 14. Спосіб за п. 1, який додатково включає визначення резервування як: декілька зарезервованих інтервалів часу на один суперкадр (100), дійсних для одного суперкадру (100); або декілька зарезервованих інтервалів часу на один суперкадр (100), дійсних для декількох суперкадрів (100); або один зарезервований інтервал часу на один суперкадр (100), дійсний для одного суперкадру (100); або один зарезервований інтервал часу на один суперкадр (100), дійсний для декількох суперкадрів (100). 15. Спосіб за п. 5, який відрізняється тим, що про згаданий щонайменше один альтернативний вільний інтервал часу повідомляють за допомогою бітового масиву (1105) зайнятості, в якому кожному слоту поставлено у відповідність щонайменше один біт для вказування зайнятості або незайнятості даного слота. 16. Спосіб за п. 5, який відрізняється тим, що про згаданий щонайменше один альтернативний вільний інтервал часу повідомляють за допомогою щонайменше одного з переліченого: період резервування, зсув резервування, зсув періоду резервування, тривалість резервування, бітовий масив (1105), в якому кожному слоту поставлено у відповідність щонайменше один біт для вказування зайнятості або незайнятості даного слота. 17. Спосіб за п. 1, який додатково включає етап неявного погодження резервування із використанням першого пакета-маячка (400) пристроювідправника (301) і першого пакета-маячка (400) пристрою-одержувача (301). 18. Спосіб за п. 1, який додатково включає етап включення у пакет-маячок (400) пристрою (301) інформації про зайнятість (1105). 19. Спосіб за п. 4, який додатково включає етап завершення пристроєм-ініціатором (301) погодження шляхом передавання повідомлення протоколу розподіленого резервування "погоджено". 5 20. Спосіб за п. 4, який додатково включає етап скасування резервування пристроєм-відправником (301). 21. Спосіб за п. 20, який додатково включає етап скасування пристроєм (301) явно погодженого резервування шляхом передавання команди скасування (1200). 22. Спосіб за п. 21, який додатково включає етап підтвердження пристроєм-одержувачем (301) одержання команди скасування (1200) щодо адресованого конкретному пристрою потоку шляхом передавання пакета негайного підтвердження (Imm ACK). 23. Спосіб за п. 21, який включає етап передавання команди скасування (1200) всіма пристроями (301), що раніше включали інформацію про це резервування в пакет-маячки. 24. Спосіб за п. 1, який відрізняється тим, що пакет-маячок (400) з етапів передавання і включення містить інформаційний елемент (700) протоколу розподіленого резервування (DRP ІЕ), який містить інформацію, що стосується положення щонайменше одного зарезервованого інтервалу часу (707) у суперкадрі (100). 25. Спосіб за п. 21, який додатково включає етап скасування резервування або шляхом видалення інформаційного елемента, що стосується даного резервування, з поточного пакета-маячка (400) і всіх наступних пакетів-маячків (400), або шляхом встановлення поля тривалості у інформаційному елементі (700), що стосується даного резервування, рівним нулю у поточному пакеті-маячку (400) і видалення інформаційного елемента (700), що стосується даного резервування, з наступних пакетів-маячків (400). 26. Спосіб за п. 1, який відрізняється тим, що: етап передавання включає передавання в пакетімаячку (400) інформації про резервування, що відображає або початковий момент часу (705) (711) і тривалість (706) (712), або бітовий масив (708) (712); і етап включення є необов'язковим. 27. Спосіб за п. 1, який додатково включає такі етапи: включення інформації про адресатів запланованого передавання в пакет-маячок (400); і враховування даного резервування, у випадку планування передавання даних одному конкретному пристрою, тільки пристроями (301), що знаходяться в зоні досяжності пристрою-одержувача (301). 28. Спосіб за п. 24, який відрізняється тим, що лише пристрій-одержувач (301) виконує етап включення для включення інформаційного елемента (700), що стосується відповідного резервування, у пакет-маячок (400). 29. Спосіб за п. 24, який відрізняється тим, що лише пристрій-одержувач (301) і всі його найближчі пристрої-сусіди (301) виконують етап включення для включення інформаційного елемента (700), 93028 6 що стосується відповідного резервування, у пакетмаячок (400). 30. Спосіб за п. 24, який відрізняється тим, що лише пристрій-відправник (301), пристроїодержувачі (301) і всі найближчі пристрої-сусіди (301) пристрою-відправника (301) і пристроїводержувачів (301) виконують етап включення для включення інформаційного елемента (700), що стосується відповідного резервування, у пакетмаячок (400). 31. Спосіб за п. 26, який відрізняється тим, що пристрій-одержувач (301) резервування: у випадку "м'якого" резервування - ініціює власне передавання, якщо пристрій-відправник (301) не використовує зарезервований час; у випадку "жорсткого" резервування - утримується від доступу до середовища, якщо пристрій (301), який є відправником у запланованому передаванні даних, не використовує зарезервований час; і у випадку резервування періоду пакетів-маячків резервує відповідний час лише для передавання пакетів-маячків. 32. Мережа зв'язку (300), яка є різновидом персональної бездротової мережі зв'язку, що об'єднує множину пристроїв (301), які включають інформацію про резервування часу для запланованого передавання даних у свої пакети-маячки (400) із використанням способу децентралізованого керування доступом до середовища передавання даних за п. 1. 33. Бездротовий пристрій (301), що підтримує розподілене резервування середовища передавання даних у персональній бездротовій мережі зв'язку, який включає в себе: антену (307) для передавання і приймання повідомлень бездротовим середовищем (310) передавання даних; приймач (302), підключений до антени (307) для приймання повідомлень про резервування середовища передавання даних, що передаються бездротовим середовищем (310) передавання даних; передавач (306), функціонально підключений до антени (307) для передавання бездротовим середовищем (310) передавання даних повідомлень про резервування середовища передавання даних; DRP-процесор для розподіленого резервування середовища передавання даних; і процесор (303), підключений до DRP-процесора, бітового масиву (305) протоколу розподіленого резервування (DRP) і запам'ятовувального пристрою, в якому міститься таблиця (308) резервувань, здійснених відповідно до протоколу розподіленого резервування, причому згаданий процесор виконаний з можливістю виконання способу децентралізованого керування доступом до середовища передавання даних за п. 1 із використанням DRP-процесора (304), бітового масиву (305) і таблиці (308) резервувань. 7 Цей винахід стосується протоколу МАС-рівня (тобто рівня керування доступом до середовища передавання даних) для надширокосмугового зв'язку (відомого фахівцям як "ultra wide-band" UWB). Більш конкретно, цей винахід стосується вдосконаленого протоколу МАС-рівня для UWB. Зокрема, цей винахід стосується вдосконаленого протоколу МАС-рівня для UWB, що включає в себе протокол розподіленого резервування (відомий фахівцям як "distributed reservation protocol" DRP). Винахід також стосується будь-якої бездротової системи, в якій використовується протокол МАС-рівня, що включає в себе протокол розподіленого резервування. Персональні бездротові мережі (відомі фахівцям як "wireless personal area networks", WPAN) не можуть забезпечити мережеву інфраструктуру типової бездротової локальної мережі (відомої фахівцям як "wireless local area network", WLAN). При цьому деякі існуючі WPAN, таких як Bluetooth або IEEE 802.15.3, будуються із використанням центрального вузла, такого як «координатор пікомережі» (відомого фахівцям як "Piconet Coordinator"). Це робить складнішою топологію мережі, і, зрештою, призводить до необхідності мати пристрої різних типів. Протокол розподіленого керування доступом до середовища передавання даних усуває необхідність мати окрему точку доступа, наділяючи відповідними функціями всі пристрої (вузли). У децентралізованій WPAN немає ані точки доступу, ані центрального керуючого пристрою (координатора). Іншими словами, всі пристрої в децентралізованій WPAN використовують один і той самий протокол і мають однакову апаратну/програмну функціональність. У більшості WPAN-мереж підтримується як асинхронне, так й ізохронне передавання даних. Тоді як в Bluetooth і IEEE 802.15.3 ізохронне передавання організовується координатором пікомережі, в даному винаході його організація повністю децентралізована (тобто розподілена). У даному винаході всі пристрої оголошують про час використання ними середовища передавання даних, передаючи пакети-маячки (відомі фахівцям як «beacon»), дізнаються про час використання середовища передавання даних сусідніми пристроями за одержаними від них пакетамимаячками і враховують використання середовища передавання даних іншими пристроями при передаванні/прийманні даних. Завдяки цьому такий протокол розподіленого керування доступом до середовища передавання даних може бути ефективно застосований у мережах, що працюють в режимі ad hoc (тобто децентралізованих мережах, мережах довільної структури без обов'язкової виділеної точки доступа), і однорангових мережах. Крім того, резервування середовища передавання даних пристроями, що є базовим принципом розподіленого керування доступом до середовища передавання даних, дозволяє уникати втрат часу на прослуховування середовища передавання даних та розв'язання колізій. Завдяки розподіленню можливостей з резервування середовища передавання даних може 93028 8 бути гарантована підтримка потокового передавання в реальному часі. Дуже ефективний протокол потокового передавання в реальному часі забезпечує контрольовану доставку даних реального часу, таких як аудіо і відео. Джерелами таких даних можуть бути як потоки даних реального часу, такі як аудіо або відео, що передаються наживо, так і заздалегідь збережений контент, наприклад записані фільми або передачі. Для такого розподіленого керування доступом до середовища може бути розроблений протокол потокового передавання в реальному часі (RTSP), що працюватиме зі стандартними транспортними протоколами, такими як RTP і HTTP. При цьому збільшується пропускна спроможність і значно поліпшується підтримка мереж із сітковою структурою. У цей час група МВОА стандартизує новий протокол МАС-рівня для UWB-передавання. Автори даного винаходу заклали основу цього нового стандарту, і більша частина тексту даної заявки включена в специфікацію цього протоколу. Відповідно до даного винаходу і побудованого на ньому стандарту МВОА всі пристрої періодично передають пакети-маячки 105 задля координації роботи пристроїв, що обмінюються даними. Пакетимаячки 105 забезпечують базову часову узгодженість у мережі і передають інформацію, що стосується ізохронних резервувань. Вибраними групою МВОА конкретними параметрами протоколу є довжина суперкадра 100, що становить 65536мкс і складається з 256 інтервалів (відомих фахівцям також як «слоти») доступу до середовища передавання даних (відомих фахівцям як «Media Access Slot» - «MAS»), причому довжина кожного MAS становить 256мкс. MAS мають номери від 0 до 255, і MAS 9 є першим. Визначено декілька типів таких MAS, що відрізняються способом, в який вони використовуються пристроєм або сусідніми пристроями. Перш ніж зможе бути започатковане передавання, пристрій має створити свою власну групу обміну даними (відому фахівцям як «beacon group») або приєднатися до існуючої групи обміну даними. У кожній фазі 101 передавання пакетівмаячків (відомій також як період пакетів-маячків, або Beacon Period — ВР) 8 послідовних MAS виділені для слотів для пакетів-маячків; впродовж них всі пристрої передають свої пакети-маячки 105. Час початку суперкадра 100 визначається початком періоду 101 пакетів-маячків і називається часом початку періоду пакетів-маячків (відомим фахівцям як "beacon period start time" - BPST), і MAS нумеруються відносно цього часу початку. Коли якійсь пристрій створює нову групу обміну даними, він визначає межу суперкадра в будь-якому слоті, що не конфліктує зі слотами, зарезервованими в інших групах обміну даними. Для кращої підтримки задач, для яких тривалість затримки є критичною, і забезпечення ефективного доступу до середовища передавання даних за умов розподіленого керування доступом до середовища потрібен досконалий протокол DRP. Запропоновані згідно з даним винаходом система і 9 спосіб забезпечують протокол DRP, що дозволяє досягти цілей, на досягнення яких спрямоване розподілення керуванням доступом до середовища. Важливою особливістю протоколу розподіленого керування доступом до середовища і даного винаходу є те, що інформація про резервування передається одержувачем пакету або групи пакетів. Це дозволяє уникнути проблеми невидимого вузла (відомої фахівцям як «hidden terminal problem»), що перешкоджає ефективній роботі у мережах із сітковою структурою. Відправник і, можливо, сусідні до одержувача і відправника вузли також передають інформацію про резервування. Протокол розподіленого керування доступом до середовища передбачає розділення часу на суперкадри 100 (див. Фіг.1). Кожен суперкадр 100 починається з інтервалу/фази передавання пакетів-маячків, відомої також як період пакетів-маячків або ВР 101, за яким йде інтервал/фаза 102 передавання даних. Пакети-маячки 105 періоду ВР 101 відокремлені один від одного так званим SIFS-проміжком та часом mBeaconGuardTime 104. Пристрої, що планують передавання даних, пропонують час початку передавання (у майбутньому), тривалість передавання, пріоритет даного сеанса передавання тощо пристроям-адресатам, що прийматимуть дані у запланованому сеансі передавання. Час початку і тривалість передавання можуть бути повідомлені або у вигляді першого слоту і кількості слотів, або у вигляді бітового масиву, в якому, наприклад, одиницями позначаються слоти, які пропонується зарезервувати. Передбачаються два варіанти погодження резервування канального часу: явне погодження DRPрезервування і неявне погодження DRPрезервування. У явному варіанті відправник започатковує процедуру погодження за допомогою спеціально визначеного службового пакета «запит на резервування» (відомого фахівцям як "ReservationRequest"). Одержувач визначає, чи буде вільним середовище передавання даних з його боку впродовж того проміжку часу (в майбутньому), що відповідає запланованому передаванню. Для того, щоб мати можливість здійснення такого визначення, кожний пристрій/вузол локально зберігає відомості про резервування, здійснені іншими пристроями (наприклад, в бітовому масиві). Якщо у одержувача не зберігаються відомості про якесь інше резервування на даний проміжок часу, то одержувач передає відправнику «запиту на резервування» позитивну відповідь. Для цього використовується спеціально визначений службовий пакет «відповідь на запит на резервування» (відомий фахівцям як "Reservation-Response"). У тому випадку, якщо одержувач не бажає приймати заплановані для передавання дані, або в тому випадку, якщо у одержувача зберігаються відомості про інше резервування на запланований час, одержувач передає відправнику негативну відповідь на «запит на резервування». У цій негативній відповіді одержувач може (але необов'язково!) пропонувати альтернативні інтервали часу для заплано 93028 10 ваного передавання. Ці альтернативні інтервали часу також можуть передаватися у вигляді першого слота і кількості слотів, або у вигляді бітового масиву, в якому, наприклад, одиниці відображають слоти, впродовж яких одержувач може приймати дані. Якщо відправник і одержувач успішно погодили резервування, обидва пристрої включають інформацію про резервування в свої відповідні пакети-маячки наступного суперкадру 100. Пакетимаячки 105 передаються в періоді пакетів-маячків ВР 101 на початку суперкадру 100, див. Фіг.1. Відправник і одержувач (одержувачі) включають інформацію про резервування в свої пакети-маячки 105 для того, щоб повідомити всім пристроям навколо відправника і одержувача (одержувачів) про заплановане передавання даних. Пристрої, що одержують таку інформацію про резервування в пакеті-маячку 105 іншого пристрою, записують (зберігають) цю інформацію про резервування локально, наприклад - в бітовому масиві, і утримуються від доступу до середовища передавання даних з оголошеного моменту часу впродовж запланованого сеанса передавання на відповідному каналі (наприклад, перемикаючись на інший канал). Іншими словами, інформація про резервування, що зберігається локально, використовується пристроєм для визначення часу, коли бездротове середовище передавання даних є вільним і може бути використане в сеансі передавання за участю даного пристрою, як у ролі відправника, так і у ролі одержувача. Пристрій вибирає такі проміжки часу для сенсів передавання, в яких він братиме участь, щодо яких відсутні (тобто не збережені локально) відомості про резервування, здійснені іншими пристроями. Процедура, що передбачає запит на резервування, відповідь на запит на резервування, повідомлення оголошень у пакетах-маячках задіяних пристроїв і, нарешті, передавання даних, в одному варіанті здійснення, якому віддається перевага, проілюстрована на Фіг.2. МАС-суперкадри 100 починаються у моменти часу, відомі як BPST або ТВТТ 201, що трапляються періодично, через однакові часові інтервали. У певному суперкадрі 100 відправник передає пакет «запит на резервування» 202 у фазі 102 передавання даних суперкадра 205, і один одержувач (у разі з'єднання з одним конкретним пристроєм, що відомо фахівцям як «unicast connection») або множина одержувачів (у разі групового з'єднання для передавання даних групі пристроїв, що відомо фахівцям як «multicast connection») відповідає в тому самому суперкадрі 205 пакетом «відповідь на запит на резервування» 203. Якщо резервування успішно погоджене, відправник і одержувач (одержувачі) включають інформацію про резервування в свої пакети-маячки 204 періоду ВР 101 наступного суперкадра 206. У випадку неявного погодження пакети «запит на резервування» і «відповідь на запит на резервування» не використовуються, і інформація про резервування відразу ж включається в пакетмаячок відправника. Якщо одержувач виявить, що його власний ідентифікатор або ідентифікатор групи пристроїв, до якої він належить, включений в 11 пакет-маячок щодо потоку, що раніше не існував, він відповідає неявно, також включаючи інформацію про резервування щодо цього потоку в свій пакет-маячок. Він може або включити ту саму інформацію про резервування і тим самим погодитись на пропозицію, або включити інформацію про альтернативні моменти часу або слоти, або відхилити запит. У тому випадку, якщо одержувач запропонував альтернативні моменти часу, відправник може або прийняти таку альтернативу і включити відповідну інформацію про резервування в свій пакет-маячок, або ініціювати нову пропозицію, що враховує зайнятість одержувача (можливо, в наступному суперкадрі). Протокол, що пропонується згідно з даним винаходом, уможливлює динамічне резервування щодо кожного суперкадра 100. Однак для скорочення витрат, пов'язаних з обміном повідомленнями «запит на резервування» і «відповідь на запит на резервування», у варіанті даного винаходу, якому віддається перевага, резервування автоматично вважається таким, що стосується не лише безпосередньо наступного суперкадра 206, але й всіх наступних суперкадрів. У тому випадку, якщо відправник захоче змінити резервування, відправник розповсюджує інформацію про нове резервування в своїх пакетах-маячках 105. У випадку явного погодження DRPрезервування відправник або одержувач може скасувати резервування, передавши пакет «скасування резервування». У неявному випадку резервування може бути скасоване або шляхом видалення DRP-інформації з пакета-маячка, або шляхом передавання відомостей про резервування з нульовою тривалістю щодо того самого потоку. Прийнявши кадр «скасування резервування», або виявивши відсутність в пакеті-маячку відповідного інформаційного елемента резервування, або виявивши резервування з нульовою тривалістю, пристрої видаляють інформацію про відповідне резервування, що зберігалась у них локально. Може трапитись випадок, в якому пристрій приймає інформацію про резервування, що стосується часу у майбутньому, на який цей пристрій у даний момент намагається зарезервувати середовище передавання даних для себе. Тоді цьому пристрою дозволяється поширювати інформацію про його власне резервування лише у випадку, якщо пріоритет запланованого ним передавання вищий від пріоритета передавання, що відповідає прийнятій інформації про резервування. У разі рівних пріоритетів середовище передавання даних резервується на основі вибраного випадковим чином числа (такого як, наприклад, ідентифікатор потоку), або за принципом «обслуговування в порядку надходження» (в порядку черги). Якщо пристрій виявить, що його резервування перекривається резервуванням іншого пристрою, він скасовує своє заплановане передавання і намагається здійснити нове резервування в наступному суперкадрі. Решта пристроїв записують резервування з більшим пріоритетом (або, наприклад, із меншим випадковим числом) в своїх таблицях резервувань, що зберігаються в локальних запам'ятовувальних пристроях 308. 93028 12 Підсумовуючи сказане, при спробі пристрою зарезервувати середовище передавання даних діють такі правила: (1) якщо середовище вже зарезервоване якимось пристроєм, інший пристрій не може перекрити це резервування; і (2) якщо два пристрої намагаються здійснити резервування в одному і тому самому суперкадрі, перевагу має резервування з більшим пріоритетом (або меншим випадковим ідентифікатором потоку у випадку рівних пріоритетів). Ці та інші особливості системи і способу, що пропонується згідно з даним винаходом, стануть ясними з наведених нижче фігур і докладного опису даного винаходу. Фіг.1 ілюструє загальний формат суперкадра; Фіг.2 ілюструє в загальних рисах роботу МАСпротоколу; Фіг.3А ілюструє бездротову мережу пристроїв відповідно до даного винаходу; Фіг.3В ілюструє пристрій, виконаний з можливістю здійснення децентралізованого керування доступом до середовища передавання даних відповідно до даного винаходу; Фіг.4 ілюструє структуру пакета-маячка одного пристрою; Фіг.5 ілюструє структуру інформаційного елемента, що повідомляє про можливості пристрою; Фіг.6 ілюструє структуру інформаційного елемента, що повідомляє про зайнятість слотів пакетами-маячками; Фіг.7 ілюструє структуру інформаційного елемента DRP-протоколу з демонстрацією варіантів формату інформації про резервування на Фіг.7А, Фіг.7В і Фіг.7С; Фіг.8 ілюструє структуру поля DRP-відомостей інформаційного елемента DRP-протоколу; Фіг.9 ілюструє структуру періоду пакетівмаячків; Фіг.10 ілюструє структуру DRP-команди «запит на DRP-резервування» і необов'язкової DRPкоманди «DRP-резервування погоджено»; Фіг.11 ілюструє структуру DRP-команди «відповідь на запит на DRP-резервування»; Фіг.12 ілюструє структуру DRP-команди «скасування DRP-резервування»; Фіг.13 ілюструє запобіжний інтервал; Фіг.14 ілюструє інтервал SIFS і запобіжний інтервал, що замикають DRP-резервування без підтвердження (nо-АСК); Фіг.15 ілюструє інтервал SIFS і запобіжний інтервал, що замикають DRP-резервування з негайним підтвердженням (Imm-ACK); Фіг.16 - діаграма послідовності повідомлень (що відомо фахівцям як «Message Sequence Chart», MSC), що ілюструє резервування часу для передавання даних одному конкретному пристрою, ініційоване відправником; Фіг.17 - MSC, що ілюструє резервування часу для передавання даних одному конкретному пристрою, ініційоване одержувачем; Фіг.18 - MSC, що ілюструє резервування часу для передавання даних групі пристроїв, ініційоване відправником; 13 Фіг.19 - MSC, що ілюструє передавання DRPкоманди «скасування DRP-резервування» у випадку резервування часу для передавання даних одному конкретному пристрою; Фіг.20 - MSC, що ілюструє передавання DRPкоманди «скасування DRP-резервування» у випадку резервування часу для передавання даних групі пристроїв. Пересічному фахівцю в цій галузі техніки буде зрозуміло, що наведений нижче опис надається для цілей ілюстрації, але не обмеження. Фахівцеві буде ясно, що без відступу від суті винаходу і в межах формули винаходу можливі численні варіанти реалізації. Несуттєві деталі стосовно відомих функцій і операцій можуть не наводитись в даному описі, щоб не ускладнювати сприйняття даного винаходу. На Фіг.3А зображена типова бездротова персональна мережа (WPAN) 300, в якій можуть використовуватися варіанти здійснення даного винаходу. Мережі об'єднує декілька персональних бездротових пристроїв 301. Як правило, кожний пристрій 301 може приєднатися до будь-якої мережі довільної структури (або «ad-hoc» мережі) в межах своєї зони досяжності і, отже, може брати участь в більш ніж одному періоді ВР. Кожний бездротовий пристрій 301 у мережі WPAN 300, показаній на Фіг.3А, може мати архітектуру, представлену на Фіг.3В. Кожний бездротовий пристрій 301 може мати антену 307, підключену до приймача 302, що здійснює зв'язок через бездротове середовище 310 передавання даних. Крім того, кожний з пристроїв 301 має процесор 303 і DRP-процесор 304. Наприклад, в одному варіанті процесор 303 виконаний з можливістю приймання з приймача 302 DRP-команди «запит на DRP-резервування» 1000, що містить один або декілька інформаційних елементів 700і протоколу розподіленого резервування (DRP IE), що мають відповідні положення пакетів-маячків, і обробки DRP-команди «запит на DRP-резервування» 1000 із застосуванням DRP-процесора 304 для погодження резервування і передавання даних відповідно до його результату. В одному варіанті процесор 303 додатково виконаний з можливістю використання DRP-процесора 304 для формування DRP-команди «відповідь на запит на DRPрезервування» 1100, яку процесор потім передає через передавач 306 в пристрій-одержувач, визначаючи у відповідь на запит на резервування параметри, показані на Фіг.11. Крім того, як інформація про погоджені резервування, так і прийнята бездротовим пристроєм 301 у пакетах-маячках інформація про резервування зберігається в DRPпам'яті або бітовому масиві 305 для подальшого використання процесором 303 і DRP-процесором 304 при формуванні відповідей на наступні запити на резервування і плануванні власних резервувань. Також в локальному запам'ятовувальному пристрої зберігається таблиця 308 резервувань, що використовується для зберігання інформації про резервування, прийняті і здійснені пристроєм 301. В одному варіанті здійснення, якому віддається перевага, в період ВР 101 всі пристрої, що пе 93028 14 ребувають або в активному стані, або в стандартному режимі енергозбереження, передають свої пакети-маячки 105. Інформаційна частина пакетамаячка 105 містить такі поля та інформаційні елементи (IE) (див. Фіг.4): - номер 401 слота; - ідентифікатор 402 пристрою; - МАС-адреса 403; і - певна кількість інформаційних елементів (IE) 404. Номер слота 401 визначає слот, впродовж якого передається пакет-маячок. Винахід може використовуватись і в системі, в якій в одному суперкадрі може бути декілька періодів пакетівмаячків, для підтримки більшої кількості пристроїв. Однак для простоти в подальшому описі розглядатиметься варіант з одним періодом пакетівмаячків. Ідентифікатор пристрою 402 - це відносно короткий ідентифікатор (наприклад, 16-розрядний), що походить, наприклад, від 48-розрядної (або 64розрядної) МАС-адреси пристрою (або вибирається випадковим чином); він використовується для скорочення витрат при адресуванні пристрою. МАС-адреса 403 - це 48-розрядна (або 64розрядна) повна МАС-адреса пристрою. Інформаційні елементи (IE) 404 можуть бути різних типів. Тип інформаційного елемента може визначатись ідентифікатором інформаційного елемента. Прикладами інформаційних елементів (IE), що розглядаються в цьому винаході детальніше, є такі: - інформаційний елемент, що повідомляє про можливості пристрою (відомий фахівцям як «DEVcap»); - інформаційний елемент, що повідомляє про зайнятість слотів пакетами-маячками (відомий фахівцям як «beacon position occupancy information element», ВРОІЕ); і - інформаційний елемент DRP-протоколу (відомий фахівцям як «DRP IE»). Інформаційний елемент DEV-cap містить інформацію, що стосується можливостей пристрою (див. фіг. 5). Поле «ідентифікатор елемента» 501 ідентифікує даний інформаційний елемент (IE), поле «довжина» 502 вказує довжину цього інформаційного елемента (IE), а поле «код визначення можливостей» 503 вказує, наприклад, у вигляді бітового масиву, які можливості підтримуються даним пристроєм. Відзначимо, що Фіг.4, Фіг.5, Фіг.6, Фіг.7, Фіг.8, Фіг.10, Фіг.11 і Фіг.12 необхідно читати справа наліво. Інформаційний елемент ВРОІЕ. зображений на Фіг.6, містить ідентифікатор елемента 601, інформацію стосовно довжини інформаційного елемента (поле 602), інформацію про довжину періоду ВР (в тому випадку, якщо період ВР має нефіксовану довжину) 603, додаткові поля 604, які тут не визначаються (а лише згадуються, для того щоб показати, що наявність додаткових полів не виводить за межі даного винаходу), і, нарешті, список полів 605 інформації про слоти. Поле 605 інформації про слот повідомляє про пакет-маячок 105 іншого пристрою, прийнятий у відповідному слоті. Відповідно, кожне поле інформації про слот 15 містить номер 607 слота (положення слота) і короткий ідентифікатор 606 пристрою, що передав пакет-маячок 105 впродовж цього слота. Інформаційний елемент ВРОІЕ використовується в кожному пакеті-маячку 105, тому що іншим пристроям необхідно повідомити, чи успішно був прийнятий їхній пакет-маячок, або при передаванні пакетів-маячків трапилась колізія. Останнє може бути наслідком того, що два пристрої випадково вибрали одне і те саме положення (один і той самий слот) для передавання пакета-маячка в межах періоду ВР, або наслідком проблеми невидимого вузла мережі із сітковою структурою. В останньому випадку пристрій міг би приймати два пакетимаячки 105 від різних пристроїв в одному і тому самому положенні (слоті) в межах ВР 101, якщо ці два пристрої не бачили один одного і не мали уявлення про положення пакета-маячка іншого пристрою (тобто про слот, в якому той передає свій пакет-маячок). Інформаційний елемент DRP-протоколу (DRP IE) вводиться у пакет-маячок, якщо пристрій є або відправником, або одержувачем в сеансі передавання даних у фазі 102 передавання даних поточного суперкадра 100. В альтернативному варіанті здійснення елемент DRP IE вводиться також у їхні пакети-маячки безпосередніми сусідами відправника і одержувача (одержувачів). В одному варіанті здійснення, якому віддається перевага, елемент DRP IE має формат, показаний на Фіг.7. Поле «ідентифікатор елемента» (Element ID) 701 ідентифікує інформаційний елемент як DRP IE. Поле «довжина» (Length) 702 вказує довжину інформаційного елемента DRP IE в октетах. Це поле використовується для визначення початку наступного інформаційного елемента. Поле «DRP-відомості» (DRP Details) 703 ілюструється окремо на Фіг.8 і включає такі поля: Біт Tx/Rx має значення 0, якщо даний пристрій є відправником у запланованому передаванні, або 1 - якщо даний пристрій є одержувачем. Біт Tx/Rx декодується тільки в тому випадку, якщо резервування є резервуванням «жорсткого» типу або «м'якого» типу. В альтернативному варіанті здійснення винаходу біт Tx/Rx використовується для того, щоб указати, чи є потік одностороннім (наприклад, без підтверджень) або двостороннім. Якщо потік односторонній, відправнику необов'язково включати в свій пакет-маячок інформацію про резервування. У ще одному варіанті здійснення біт Tx/Rx в елементі DRP IE відсутній через відсутність жорстких вимог до його наявності. Біт «політика підтвердження» (АСК Policy Bit) 802 має значення 0 у випадку резервувань, що стосуються одного конкретного пристрою і не передбачають підтвердження, а також для резервувань, що стосуються групи пристроїв, або резервувань для мовлення, і має значення 1 у випадку резервувань, що стосуються одного конкретного пристрою і передбачають негайне підтвердження (Imm-ACK) або групове/відкладене підтвердження (В-АСК). 93028 16 У полі «тип» (Туре) 803 вказується тип резервування, і воно кодується таким чином: Таблиця 1 Типи резервування 0000 0001 0010 0011-1111 період ВР жорстке м'яке зарезервовано Поле «пріоритет» (Priority) 804 визначає пріоритет передавання і може приймати значення від 0 до 7, причому пріоритет вибирається у відповідності до IEEE 802. Id Annex H.2. Поле «ідентифікатор потоку» (StreamID) 805 вибране випадковим чином значення, що ідентифікує потік даних і використовується для розрізнення між декількома потокам однієї множини «відправник-одержувач (одержувачі)». Поле «номер каналу» (Channel Number) 806 містить номер каналу для передавання даних. У тому випадку, коли передавання даних і передавання пакетів-маячків завжди здійснюються на одному і тому самому каналі, це поле зайве. Тут воно показане для повноти опису винаходу. Поле «ідентифікатор пристроюодержувача/пристрою-відправника» (Destination/Source DEVID) 704 містить ідентифікатор пристрою-одержувача, ідентифікатор групи пристроїв або ідентифікатор мовного передавання у випадку, якщо даний пристрій є відправником у відповідному сеансі передавання, або містить ідентифікатор пристрою-відправника в тому випадку, якщо даний пристрій є одержувачем у запланованому сеансі передавання. Поле «поле резервування» (Resevation Block) 707 містить інформацію про зарезервований час про відповідні слоти у суперкадрі. Можливими є різні, способи інформування про зарезервований час. Як приклади, на Фіг.7А, Фіг.7В і Фіг.7С показані три варіанти структури «поля резервування». Можуть використовуватись й інші варіанти - конкретний варіант не є суттєвим для даного винаходу. В один інформаційний елемент DRP IE можуть включатись декілька «полів резервування» - для інформування про більш ніж одне резервування в одному інформаційному елементі DRP IE. У першому варіанті здійснення, показаному на Фіг.7А, резервування задається полем «зсув відносно BPST». або полем «зсув відносно ТВТТ», або полем «період резервування» (які відомі фахівцям, відповідно, як «BPST Offset», «ТВТТ Offset» та «period of reservation») 705, і полем «тривалість» (Duration) 706. Поле «зсув відносно BPST» (або «зсув відносно ТВТТ», або «період резервування») визначає момент часу початку запланованого передавання. Це поле містить номер першого слота відповідного інтервалу часу, що резервується, який (номер слота) визначається відносно BPST. В альтернативному варіанті здійснення (наприклад, для систем, що не передбачають розділення часу на слоти) поле «зсув відносно BPST» задається як кількість символів (один символ від 17 повідає 312,5 не). В одному варіанті здійснення такий зсув визначається не відносно BPST, а відносно ТВТТ. У ще одному варіанті здійснення поле «зсув» визначає часовий інтервал між двома послідовними резервуваннями, тобто період резервування. Поле «тривалість» 706 визначає тривалість резервування, у кількості слотів. В альтернативному варіанті здійснення тривалість задається кількістю символів (кожен - 312,5нс). У ще одному варіанті здійснення винаходу (див. Фіг.7В) початок і тривалість інтервалу часу, що резервується, повідомляються за допомогою поля «бітовий масив» 708, в якому один або декілька бітів описують стан кожного MAS. Якщо на кожний MAS використовувати один розряд, початок інтервалу часу, що резервується, задається, наприклад, першим MAS, якому відповідає одиниця у бітовому масиві, а тривалість задається кількістю послідовних одиниць у бітовому масиві. Суто як приклад розглянемо (див. Фіг.7С) варіант, який поєднує обидва попередні варіанти здійснення; в цьому варіанті використовується універсальне «поле резервування», що поєднує і період резервування, і бітовий масив. У «полі резервування» в найбільш загальному вигляді поле «тип резервування» (Type of Reservation) 709 могло б вказувати, чи є резервування «періодичним», із декількома зарезервованими інтервалами часу в суперкадрі, чи в суперкадрі резервується одинєдиний інтервал часу. Зокрема, у випадку резервування одного інтервалу часу в суперкадрі, поле «тип резервування» могло б також вказувати, чи дане резервування дійсне лише у відповідному суперкадрі, або також дійсне і для всіх наступних суперкадрів, доки резервування не скасоване. Щоб поєднати період резервування і бітовий масив, наприклад, 256 слотів суперкадра можна було б розділити на Μ блоків, де Μ - це мінімально можливий період резервування. Тоді поле «період» 710 буде задавати період резервування як кількість таких мінімальних періодів резервування. Поле «зсув» 711 задає зсув блока, до якого потрапляє інтервал часу, що резервується (або перший такий інтервал - у випадку «періодичного» резервування, із декількома зарезервованими інтервалами часу), виражений як кількість блоків. Поле «бітовий масив» 712 вказує у вигляді бітового масива слоти, зарезервовані в полі резервування. Відповідно, така універсальна структура «поля резервування» використовує і зсув, і бітовий масив. Зазначимо, що інформаційний елемент DRP IE може містити додаткові елементи, або мати іншу структуру - для даного винаходу це не є суттєвим. Прикладом ще одного можливого поля може бути, наприклад, поле, що вказує, чи успішно завершилось погодження DRP-резервування. Пристрої, що мають намір брати участь в обміні інформацією з іншими пристроями, здійснюють передавання пакетів-маячків впродовж періоду ВР 101. Впродовж періоду ВР пристрій не передає інших пакетів, крім пакетів-маячків 105. Під час свого періоду ВР 101 пристрій прослуховує 93028 18 канал для приймання пакетів-маячків 105 інших пристроїв. Період ВР може мати нефіксовану тривалість (що не перевищує заданої максимальної тривалості) і складатися з певної кількості слотів MAS. Кожний MAS уміщує 3 слоти для пакетів-маячків, тривалістю mBeaconSlotLength. Довжина пакетамаячка не може перевищувати mMaxBeaconLength. mBeaconSlotLength=mMaxBeaconLength+SIFS +mBeaconGuardTime Це означає, що пакети-маячки 105 в ВР 101 розділені інтервалом SIFS 104 і проміжком часу mBeaconGuardTime. Змінний період В Ρ 101 має значну перевагу, оскільки витрати на передавання пакетів-маячків мінімальні в типових випадках, коли у зв'язку беруть участь один пристрій, що здійснює передавання, і один або декілька пристроїв, що здійснюють приймання. Якщо до мережі долучається новий пристрій, він прослуховує щонайменше один повний перший інтервал пакетів-маячків і аналізує інформацію, що міститься в пакетах-маячках 105. За прийнятими пакетами-маячками 105, а також інформаційними елементами ВРОІЕ, що містяться в них, новий пристрій визначає положення (слоти), зайняті пакетами-маячками. У тому самому або наступному суперкадрі 100 (в залежності від швидкодії пристрою) пристрій передає свій пакет-маячок в одному з вільних слотів для пакетів-маячків або додає його в кінець періоду ВР, збільшуючи тим самим тривалість періоду ВР. Якщо два пристрої вибрали одне і те саме додаткове положення або номер для пакета-маячка, наприклад, долучившись до мережі в одному і тому самому суперкадрі 100, пристрої виявляють колізію в наступному суперкадрі 100 за відсутністю елемента ВРОІЕ. У такому випадку пристрій заново передає свій пакет-маячок 105 в суперкадрі 100, що йде за його останньою спробою, в іншому вільному слоті для пакета-маячка. Подібним чином можна також скоротити тривалість періоду ВР, якщо пристрій залишив мережу і його слот для пакета-маячка звільнився. Для кожного періоду ВР пристрій веде бітовий масив, в якому зберігаються інформація про зайнятість слотів для пакетів-маячків і відповідні ідентифікатори пристроїв (DEVID). Слот для пакета-маячка позначається в бітовому масиві як зайнятий, якщо: a) впродовж цього слота для пакета-маячка приймається пакет-маячок; або b) слот для пакета-маячка включений в елемент ВРОІЕ, прийнятий від пристрою, що належить до тієї самої групи обміну даними. Статус слота для пакета-маячка змінюється із зайнятого на незайнятий, якщо: a) в послідовних суперкадрах кількістю mMaxLostBeacons у відповідному слоті не приймалися пакети-маячки, і b) інформація про цей слот не міститься в жодному з елементів ВРОІЕ, що приймалися в послідовних суперкадрах кількістю mMaxLostBeacons від пристроїв, що належать до тієї самої групи обміну даними. 19 Пристрої передають свої пакети-маячки 105 в одних й тих самих слотах для пакетів-маячків послідовних суперкадрів, якщо тільки не трапиться колізія. Для розв'язання колізій, що виникають при виборі слота для пакета-маячка, пристрої використовують протокол розв'язання колізій з пакетамимаячками (відомий фахівцям як «Beacon Collision Resolution Protocol», BCRP). Пристрої включають інформаційний елемент ВРОІЕ у всі пакети-маячки 105. Прийнявши пакетмаячок, пристрій зберігає ідентифікатор DEVID відправника і номер слота, в якому прийнято цей пакет-маячок. Ця інформація включається в інформаційний елемент ВРОІЕ, що передається пристроєм в наступному суперкадрі. В інформаційний елемент ВРОІЕ, що передається в наступному суперкадрі, включається лише інформація за пакетами-маячками, прийнятими у попередньому суперкадрі 101. Якщо в послідовних суперкадрах кількістю mMaxLostBeacons в елементі ВРОІЕ із сусідського пакета-маячка відсутній ідентифікатор DEVID пристрою, для наступного суперкадру пристрій переводить відповідний слот для пакета-маячка в розряд незайнятих слотів. При цьому DRPрезервування зберігаються, і їх не треба погоджувати наново при зміні статусу слота для пакетамаячка. Пристрої можуть передавати пакети-маячки в декількох періодах ВР. Пристрої ведуть окремий бітовий масив для кожної групи обміну даними. Елемент ВРОІЕ формується незалежно для кожної групи обміну даними, і пристрій передає елемент ВРОІЕ для кожної групи обміну даними у відповідний період ВР. Якщо виявлено сусідський період ВР 101, пристрій включає у власний пакет-маячок інформаційний елемент DRP IE 700, що має тип резервування «період ВР». Це DRP-резервування поширюється на слоти MAS, впродовж яких триває сусідський період ВР 101. Пристрої, що приймають пакет-маячок з DRPрезервування типу «період ВР», починають прослуховувати канал для виявлення сусідських періодів ВР. Якщо пристроєм в процесі сканування виявляється сусідський період ВР, DRPрезервування 700 типу «період ВР» включається ним у власний пакет-маячок. Це DRPрезервування поширюється на слоти MAS, впродовж яких триває сусідський ВР. Однорангові пристрої, що бажають обмінюватися даними, передають пакети-маячки в один і той самий період ВР 101. Якщо пристрійпередавач зв'язується з пристроями, що передають пакети-маячки в декількох (різних) періодах ВР 101, тому що вони є членами більш ніж однієї групи обміну даними, пристрій-передавач передає пакети-маячки в цих декількох ВР 101. Пристрої періодично прослуховують всі наявні періоди ВР 101 для приймання їхніх пакетівмаячків, щоб бути в курсі здійснених резервувань і мати можливість розв'язувати колізії. Пристрої «слухають» всі періоди пакетів-маячків і визначають наявні резервування перед тим, як здійснити 93028 20 нове резервування або змінити існуюче. В одному варіанті пристрої можуть (необов'язково) передавати пакети-маячки в сусідських ВР 101 для оголошення про зміни в резервуваннях. Інформація про резервування, прийнята із сусідських періодів ВР 101, враховується із застосуванням тих самих правил, що застосовуються щодо резервувань у групі обміну даними, до якої належать дані пристрої. Якщо наявні DRP-резервування конфліктують із періодом ВР 101, період ВР 101 має вищий пріоритет, і, відповідно, наявні DRP-резервування погоджуються заново. Якщо конфлікт виникає між двома або більше періодами ВР 101, пристрої з конфліктуючими пакетами-маячками відшукують незайняті слоти, що не конфліктують один з одним. Як варіант, пристрій може почати новий період ВР 101 в інших незайнятих слотах. Якщо в послідовних суперкадрах 101 кількістю принаймні mMaxLostBeacons в періоді ВР 101 не було прийнято жодного пакета-маячка 105, цей період ВР 101 скасовується і резервування періоду ВР може бути зняте. У варіанті здійснення, якому віддається перевага, у суперфреймі допускається лише один період пакетів-маячків. Якщо в зоні досяжності виявлені дві окремі групи пристроїв і їхні відповідні періоди ВР, то вони об'єднуються в один період ВР. Цей єдиний період ВР розташовується на початку суперкадра. Для цього варіанта здійснення не потрібні правила щодо «прослуховування» інших періодів ВР і їх захисту резервуваннями типу «період ВР», але ці правила можуть застосуватися у перехідний період під час об'єднання періодів ВР. Як згадується вище при розкритті суті винаходу, DRP-протокол, запропонований згідно з даним винаходом, допускає явне або неявне погодження резервувань. У разі явного погодження резервування здійснюються за допомогою DRP-команди «запит на DRP-резервування» і DRP-команди «відповідь на запит на DRP-резервування», або контрольного квитування. В альтернативному варіанті здійснення застосовується тришагове квитування, при якому після пакетів «запит на DRPрезервування» і «відповідь на запит на DRPрезервування» йде пакет «DRP-резервування погоджено», що передається тим самим пристроєм, який передав пакет «запит на DRP-резервування». У разі явного погодження резервування скасовується пакетом «скасування DRP-резервування». В іншому аспекті винаходу цей пакет «скасування DRP-резервування» повторюється всіма пристроями, які раніше також інформували про це резервування. У ще одному аспекті винаходу резервування скасовується шляхом включення інформаційного елемента DRP IE з нульовою тривалістю, або шляхом видалення відповідного DRPIE. У разі неявного погодження квитування здійснюється неявно шляхом включення інформаційного елемента DRP IE в пакети-маячки відправника і одержувача (одержувачів), і заздалегідь не передаються ніякі командні або керуючі пакети. 21 Для запитування або зміни DRP-резервування може використовуватися DRP-команда «запит на DRP-резервування» (DRP Request Command) 1000. Формат команди «запит на DRPрезервування» 1000 показаний на Фіг.10. Кожне поле 700.n елемента DRP IE, включене в команду «запит на DRP-резервування» 1000, відповідає окремому запиту на DRP-резервування. Кожне поле 700.n має формат, описаний вище з посиланням на Фіг.7. Поле StreamID містить одне і те саме значення в кожному полі 700.n інформаційного елемента DRP IE. Команда «відповідь на запит на DRPрезервування» (DPR Response Command) 1100 має формат, показаний на Фіг.11. Значення StreamID 1103 копіюється з поля 700.n команди «запит на DRP-резервування». Поле «код відповіді» (Reason Code) 1104 вказує, чи був запит на DRP-резервування успішним або неуспішним. Це поле може містити такі коди: 0 - «успішно»; 1 - «канальний час зайнятий»; 2 - «запитана надвисока швидкість не підтримується»; 3 - «запит відхилено»; 4-255 = зарезервовані. При погодженні DRP-резервування для обміну даними з одним конкретним пристроєм, якщо «код відповіді» - 1, пристрій включає в команду «відповідь на запит на DRP-резервування» поле «бітовий масив зайнятості» (Availability Bitmap) 1105. Поле «бітовий масив зайнятості» 1105 може також включатися і для всіх інших кодів відповіді, хоч це і не є необхідним. При погодженні DRP-резервування для одночасного передавання групі пристроїв пристрій включає поле «бітовий масив зайнятості» 1105 в команду «відповідь на запит на DRPрезервування» у випадку «коду відповіді», що дорівнює 0, 1 і 2. Знову таки, поле «бітовий масив зайнятості» 1105 може також включатися і для всіх інших кодів відповіді, хоч це і не є необхідним. Поле «бітовий масив зайнятості» 1105 містить 256 бітів. Кожний біт відповідає одному MAS. Значення «1» є індикатором того, що відповідний MAS не може бути виділений для DRP-резервування (не є вільним). Значення «0» є індикатором того, що відповідний MAS є вільним і може бути виділений для DRP-резервування. Призначення бітів, само собою, може бути і протилежним. В альтернативному варіанті здійснення бітовий масив містить декілька бітів для кожного MAS. В альтернативних варіантах здійснення, в яких початок і тривалість інтервалу часу, що резервується, в інформаційному елементі DRP IE повідомляються за допомогою бітового масива або поєднання зсуву і бітового масиву, замість поля «бітовий масив зайнятості» пристрій, що відповідає, міг би включити в пакет «відповідь на запит на DRP-резервування» інформаційний елемент DRP IE або його частину. Необов'язкова команда «DRP-резервування погоджено», що в одному альтернативному варіанті здійснення винаходу передається після приймання «відповіді на запит на DRP-резервування» 93028 22 тим самим пристроєм, який ініціював погодження за допомогою пакету «запит на DRPрезервування», має такий самий формат, як і команда «запит на DRP-резервування» (див. Фіг.10). Команда «скасування DRP-резервування» (DPR Termination) має формат, показаний на Фіг.12. Поле StreamID вказує, що ідентифікація доставки за DRP-протоколом припинена. У варіанті здійснення, якому віддається перевага, крім доступу за DRP-протоколом підтримується і другий механізм доступу до середовища передавання даних, що базується на конкурентному доступі. Конкурентний доступ може використовуватися щодо всіх MAS, які не були до того зарезервовані відповідно до DRP-протоколу. Конкурентний доступ може також використовуватися як аварійний механізм доступу, з трафіком, що використовує DRP-протокол, але в тому випадку, якщо зарезервований канальний час не може бути використаний, наприклад, через завади від інших пристроїв, і необхідно зробити нове резервування. У разі доступу за DRP-протоколом погодження резервування запускається настройками потоку, що залежать від конкретної прикладної програми, і виконується під час або після здійснення настройки потоку вищого рівня. Однак DRP-погодження потрібно розглядати не як встановлення з'єднання, але лише як процедуру погодження використання канального часу. Погодження може повторюватися, тобто виділений канальний час може бути змінений в будь-який момент часу, доки даний потік існує. DRP-протокол, запропонований згідно з даним винаходом, дозволяє пристроям здійснювати резервування на один або декілька інтервалів часу фази 102 передавання даних суперкадра 100. Резервування гарантує виділення для передавання інтервалів часу, що визначаються першим MAS і тривалістю - кількістю слотів MAS, бітовим масивом або комбінацією цих параметрів. Механізм резервування може використовуватися, наприклад, задля економнішого витрачання енергії і/або забезпечення гарантування якості послуг (що відомо фахівцям як «QoS») при ізохронному передаванні. Всі пристрої, що є відправниками або одержувачами у сеансах передавання, запланованих за DRP-протоколом, інформують про свої резервування в своїх пакетах-маячках 105. Ще одним типом резервування є окремий різновид «жорсткого» резервування для інших періодів ВР. Завдяки йому інші пристрої можуть визначити наявність чужих періодів пакетів-маячків. У варіанті здійснення, якому віддається перевага, визначаються різні типи резервування: «жорстке» резервування, «м'яке» резервування і резервування періоду ВР 101. «Жорстке» резервування еквівалентне TDMA-слоту. «М'яке» резервування може використовуватися для того, щоб зробити можливим «інакше» використання невикористаного зарезервованого часу. Тип резервування повідомляється в інформаційному елементі 700 DRP IE, що уміщується у пакет-маячок 105, а також у пакеті-команді «запит на DRPрезервування» 1000 у разі явного погодження 23 DRP-резервування. Всі пристрої декодують пакети-маячки 105 і елемент DRP IE 700, і здійснюють доступ за правилами, визначеними для кожного типу резервування. При «жорсткому» резервуванні тільки «власник» резервування може одержати доступ до середовища передавання даних, навіть якщо це середовище вільне. Іншим пристроям доступ до середовища дозволяється лише після того, як відправник і одержувач (одержувачі) відмовляться від резервування, що не використовується. При «жорсткому» резервуванні відправник і одержувач (одержувачі) відповідного сеансу передавання можуть не обмінюватися RTS-/CTSпакетами перед передаванням даних, оскільки середовище передавання даних як з боку відправника, так і з боку одержувача вже звільнене за допомогою інформаційних елементів DRP IE 700, включених до пакетів-маячків 105. В інтервал часу, що є предметом «м'якого» резервування, інші пристрої можуть одержувати доступ до середовища передавання даних за правилами конкурентного доступу. «Власник» резервування може одержувати доступ до середовища передавання даних із найвищим пріоритетом і не витримуючи паузу у випадку конфлікту. Незважаючи на те, що механізм резервування повинен був би виключати конфлікти, все ж може трапитись так, що якійсь пристрій не одержить інформації про резервування; у такому випадку можливого конфлікту можна було б запобігти прослуховуванням каналу. В альтернативному варіанті здійснення винаходу навіть «власник» резервування має прослуховувати середовище передавання даних впродовж певного часу. «М'який» тип резервування виявляється корисним, якщо відправник не використовує раніше зарезервовані ним слоти. У цьому випадку ці слоти все ж доступні для інших пристроїв у конкурентному режимі. Резервування періоду ВΡ можна вважати окремим випадком «жорсткого» резервування. Вони використовуються для захисту чужих періодів пакетів-маячків (під час перехідної фази перед об'єднанням періодів ВР, або в тому випадку, коли допускається декілька періодів пакетів-маячків в одному суперкадрі), і вказування на наявність чужого періоду пакетів-маячків сусіднім пристроям. Можливі й інші типи резервувань, і це не виводитиме за межі даного винаходу. «Запобіжні інтервали» потрібні для запобігання колізіям між сеансами передавання, зарезервованими сусідніми. Крім того, для коректної роботи системи між окремими передаваннями запроваджено інтервал SIFS. Резервування визначається першим MAS і тривалістю, вираженій у кількості слотів MAS, вказаними в інформаційному елементі DRP IE 700. Запобіжний інтервал - це проміжок часу між кінцем одного зарезервованого інтервалу часу і початком наступного зарезервованого інтервалу часу. Включення інтервалу SIFS як частини зарезервованого інтервалу часу і запровадження запобіжного інтервалу між зарезервованими інтервалами часу забезпечує рознесення сеансів передавання у часі принаймні на інтервал SIFS. На 93028 24 Фіг.13 показано запровадження запобіжного інтервалу у такий спосіб, що забезпечує рознесення сеансів передавання принаймні на інтервал SIFS 1301, якщо годинники «власників» сусідніх зарезервованих інтервалів часу «дрейфують» назустріч один одному. Необхідна тривалість запобіжного інтервалу залежить від максимального дрейфу власних годинників пристроїв. Дрейф залежить від часу, що минув після синхронізуючої опорної події. Кожний пристрій відстежує номінальний час початку періоду пакетів-маячків (BPST), який використовується як опорний момент часу. Пристрій підстроює свій BPST, щоб підтримувати синхронізацію суперкадрів із сусідом, що в його групі обміну даними має найповільніший годинник. Пристрій вимірює проміжки часу між моментами часу, в які фактично приймаються пакети-маячки від кожного сусіда, і моментами часу, в які очікувався такий прийом. Різниця буде додатною у випадку, якщо у сусіда годинник повільніший. Після цього цей пристрій «затримує» свій BPST на час, що відповідає максимальній різниці, визначеній з-посеред всіх сусідів по групі обміну даними. Запобіжний інтервал визначається як сума тривалості максимально можливого дрейфу (який залежить від найгіршої точності годинника) і тривалості інтервалу SIFS. У випадку «жорсткого» резервування пристрій починає своє передавання на початку першого MAS, що відповідає зарезервованому інтервалу часу, виходячи з відліку часу його власним годинником. При «м'якому» резервуванні або в альтернативних варіантах здійснення перед передаванням може бути необхідним витратити певний час на прослуховування середовища передавання даних. У межах зарезервованого інтервалу часу відправник може передавати стільки пакетів, скільки йому потрібно, тобто також і групи пакетів даних, в яких пакети розділені, наприклад, інтервалами SIFS. Одержувач може не підтверджувати прийом пакетів даних (пакети DATA) (Фіг.14), підтверджувати прийом кожного окремого пакету даних пакетом негайного (Imm) підтвердження (АСК) (Фіг.15) або підтверджувати групу пакетів даних пакетом групового/відкладеного підтвердження. Пакет групового/відкладеного підтвердження містить інформацію, що підтверджує прийом кожного попереднього пакету даних, уможливлюючи тим самим селективне відбраковування неуспішно прийнятих пакетів. Відправник забезпечує, щоб час, необхідний для доступу (у випадку «м'якого» резервування), був достатнім для групи пакетів, при тому щоб разом із підтвердженням (АСК) і тривалістю останнього інтервалу SIFS він не перевищував тривалості зарезервованого інтервалу часу. У тому випадку, якщо передавання іншого пристрою заблокувало середовище передавання даних на певний проміжок часу під час зарезервованого інтервалу часу, відправник відповідно скорочує кількість даних, що передаються, щоб гарантувати закінчення передавання відповідно до графіку. 25 Оскільки годинник в одному пристрої може поспішати відносно реального часу, а в іншому - відставати відносного реального часу, пристрій, що чекає одержання або пакета-маячка 105 під час періоду ВР 101, або пакету під час DRPрезервування, починає приймати раніше, ніж настає момент часу, який, за його розрахунками, повинен бути початком періоду ВР 101 або початком DRP-резервування, і продовжує приймати після настання моменту часу, який, за його розрахунками, розташований на відстані (у часі) в один інтервал SIFS від завершення періоду ВР 101 або DRP-резервування. Тривалість часу, впродовж якого пристрій прослуховує середовище передавання даних до початку DRP-резервування або періоду ВР 101 або після завершення DRPрезервування або періоду ВР 101, вибирає розробник. Передбачені два механізми погодження резервування канального часу: явне погодження за допомогою спеціальних командних/керуючих пакетів «DRP-запит/DRP-відповідь» 1000/1100 (і, як опція, «DRP-погоджено») і неявне погодження шляхом включення інформаційних елементів DRP IE 700 в пакети-маячки 105 відправника і одержувача (одержувачів). Резервування погоджується між відправником і одержувачем (одержувачами) планованого передавання. Як тільки резервування здійснене, інформація про резервування включається в пакет-маячок 105 відправника, а також одержувача (одержувачів) в кожному суперкадрі 100, на який поширюється дане резервування. Це необхідне для того, щоб повідомляти пристроямсусідам відправника і одержувача (одержувачів) про наявне резервування. Пакети-маячки 105 відправника і одержувача (одержувачів) DRP-потоку передаються впродовж одного і того самого періоду ВР 101. Однак резервування визначаються у декількох періодах ВР 101. Тому пристрої прослуховують всі періоди ВР 101, щоб визначити наявні резервування, перш ніж почати нове DRPпогодження або змінити наявне. Крім того, пристрої періодично прослуховують всі наявні періоди ВР 101 для виявлення пакетів-маячків 105, щоб мати актуальну інформацію про стан існуючих резервувань і, можливо, розв'язувати конфлікти. У варіанті здійснення, якому віддається перевага, є лише один період ВР, який доводиться прослуховувати, і, відповідно, декодувати. Кожний пристрій в своєму пакеті-маячку 105 оголошує, чи він підтримує можливість явного DRP-погодження із використанням командних/керуючих пакетів «DRP-запит/DRP-відповідь» 1000/1100, а також - чи він підтримує можливість неявного DRP-погодження шляхом включення інформаційних елементів DRP IE 700 в пакетмаячок 105. Пристрій не починає DRP-погодження з іншим пристроєм, що не підтримує відповідний механізм DRP-погодження. Пристрої, що не придатні ані до явного, ані до неявного DRPпогодження, все одно працюють відповідно до здійснених резервувань, оголошених в елементах DRP IE 700 пакетів-маячків інших пристроїв. При явному DRP-погодженні використовуються DRP-команди, що передаються, наприклад, із 93028 26 використанням механізму конкурентного доступу (але, наприклад, вони також можуть передаватися у межах вже погодженого резервування). Явне погодження інтервалу часу для передавання даних одному конкретному пристрою може бути ініційоване як відправником, так і одержувачем даних, передавання яких планується; все ж у варіанті здійснення винаходу, якому віддається перевага, погодження ініціюється відправником. Явне погодження інтервалу часу для передавання даних групі пристроїв може бути ініційоване тільки відправником. Послідовність повідомлень, що використовуються під час ініційованого відправником погодження інтервалу часу для передавання даних одному конкретному пристрою, показана на Фіг.16. Послідовність повідомлень, що використовуються під час ініційованого одержувачем погодження інтервалу часу для передавання даних одному конкретному пристрою, показана на Фіг.17. Послідовність повідомлень, що використовуються під час ініційованого відправником погодження інтервалу часу для передавання даних групі пристроїв, показана на Фіг.18. Альтернативний варіант здійснення, що передбачає тришагове квитування, окремо не показаний, оскільки він відрізняється лише тим, що ініціатор в кінці послідовності повідомлень відправляє додатковий пакет «DRP-резервування погоджено» для підтвердження виконання погодження. Ініційоване одержувачем погодження аналогічно ініційованому відправником погодженню, з тією лише різницею, що один біт у командному/керуючому пакеті «запит на DRPрезервування» встановлюється рівним не одиниці, а нулю, щоб вказати, що даний пристрій має намір бути одержувачем, а не відправником відповідного потоку. Пристрій у межах одного DRP-погодження може одночасно запитувати декілька DRPрезервувань для одного і того самого потоку. У кожному DRP IE 700 пропонуються перший MAS, визначений в полі «зсув відносно BPST», і тривалість, виражена в кількості слотів MAS. Поле StreamID в кожному DRP IE 700 містить одне і те саме значення, вибране випадковим чином при першій настройці потоку або «спущене» з вищого рівня, із забезпеченням унікальності значення StreamID для даної пари пристроїв (або групи пристроїв - у разі групового з'єднання). Ініціатор вибирає слоти MAS, що пропонуються для резервування, на основі локально збереженої інформації, тобто із врахуванням існуючих резервувань і зайнятості одержувача (одержувачів). При одержанні пакету «запит на DRPрезервування», що містить ідентифікатор одного одержувача, пристрій відповідає пакетом негайного підтвердження (Imm-Ack), услід якому передає командний/керуючий пакет «відповідь на запит на DRP-резервування». Команда «відповідь на запит на DRP-резервування» передається із використанням конкурентного доступу після передавання негайного підтвердження (Imm-Ack) і обробки запиту. Якщо негайне підтвердження (Imm-Ack) не прийняте, відправник може повторно передати 27 пакет «запит на DRP-резервування» в режимі конкурентного доступу. Як тільки команда «запит на DRPрезервування» 1000 передана, пристрій вичікує тайм-аут mDRPRequestTimeout. Якщо протягом часу mDRPRequestTimeout після передавання запиту команда «відповідь на запит на DRPрезервування» 1100 не прийнята, пристрій може повторно передати команду «запит на DRPрезервування» 1000. При прийомі командного/керуючого пакета «запит на DRP-резервування» 1000, в якому ідентифікатор одержувача співпадає з ідентифікатором групи пристроїв, до якої записаний даний пристрій, він не відповідає пакетом негайного підтвердження (Imm-Ack). Такий пристрій відповідає на одержану команду передаванням команди «відповідь на запит на DRP-резервування», наприклад, в конкурентному режимі. Одержувач команди «запит на DRPрезервування» 1000 оцінює, чи буде вільним середовище передавання даних у час, що є предметом запиту, відповідно до локально збереженої інформації. Якщо середовище буде вільним і на час, що є предметом запиту, не заплановане ані передавання, ані прийом, пристрій може відповісти командою «відповідь на запит на DRPрезервування» 1100 із кодом відповіді «успішно», і тим самим дати позитивну відповідь на «запит на DRP-резервування». Якщо одержувач команди «запит на DRPрезервування» 1000 не може задовольнити запит, бо той конфліктує з іншими резервуваннями, у команді «відповідь на запит на DRPрезервування» 1100 використовується код відповіді «канальний час зайнятий». У цьому випадку для інформування про доступні для DRPрезервування слоти у команду «відповідь на запит на DRP-резервування» 1100 включається поле «бітовий масив зайнятості». При одержанні відповіді «канальний час зайнятий» в команді «відповідь на запит на DRPрезервування» 1100 відправник команди «запит на DRP-резервування» 1000 може заново почати процес погодження новою командою «запит на DRP-резервування» 1000, що стосуватиметься проміжку часу, вибраному із врахуванням зайнятості одержувача. Якщо одержувач команди «запит на DRPрезервування» 1000 виявить, що середовище передавання даних зайняте протягом часу, що планується резервувати, і визначення якогось альтернативного періоду часу є неможливим, одержувач команди «запит на DRP-резервування» 1000 відповідає передаванням команди «відповідь на запит на DRP-резервування» з кодом відповіді «запит відхилено». Така відповідь - «запит відхилено» - дається також у тому випадку, якщо одержувач не бажає погоджувати дане резервування з будьякої іншої причини. У тому випадку, якщо команда «запит на DRPрезервування» 1000 передається відправником групі пристроїв, цей відправник може одержати декілька команд «відповідь на запит на DRPрезервування» 1100. Деякі з таких відповідей мо 93028 28 жуть повідомляти про неуспішність погодження. Відправник може спробувати вибрати для резервування інтервал часу, прийнятний для максимальної кількості одержувачів - ґрунтуючись на бітових масивах зайнятості, прийнятих в пакетах «відповідь на запит на DRP-резервування». Одержувачі, які не можуть бути обслужені у такому найбільш придатному інтервалі резервування, могли б бути обслужені в інтервалах часу, окремо зарезервованих для групового з'єднання або з'єднання з одним конкретним пристроєм. Такі резервування необхідно визначати в межах окремих DRP-погоджень. . . Якщо відправник і одержувач (одержувачі) успішно погодили резервування, вони включають інформацію про резервування в свої відповідні пакети-маячки 105 в ВР 101 наступних суперкадрів 100. У альтернативному варіанті здійснення винаходу тільки одержувач (одержувачі) включає інформацію про резервування в свій пакет-маячок. Це було б можливе, наприклад, у випадку однонаправленого з'єднання. У ще одному варіанті здійснення інформацію про резервування включають в свій пакет-маячок одержувач і всі його найближчі («one-hop») пристрої-сусіди. У ще одному варіанті здійснення інформацію про резервування включають у свій пакет-маячок відправник і одержувач, а також всі найближчі («one-hop») сусіди відправника і одержувача. У тому випадку, якщо або відправник, або одержувач потоку, адресованого конкретному пристрою, або відправник потоку, адресованого групі пристроїв, побажають змінити резервування, вони можуть або ініціювати новий обмін командами «запит на DRP-резервування» 1000 і «відповідь на запит на DRP-резервування» 1100, або вдатися до неявного DRP-погодження із використанням елементів DRP IE 700 в своїх пакетах-маячках 105. DRP-погодження з'єднання з одним конкретним пристроєм із використанням елементів DRP IE 700 в пакетах-маячках 105 (т.зв. неявне погодження) може бути почате або відправником, або одержувачем запланованого сеансу передавання, хоч ініціювання погодження відправником є варіантом здійснення даного винаходу, якому віддається перевага. Неявне погодження групового з'єднання може бути ініційоване тільки відправником для групи пристроїв. При неявному DRP-погодженні із застосуванням елементів DRP IE 700 у пакетах-маячках 105 перед включенням елементів DRP IE 700 в пакетимаячки 105 відправника і одержувача (одержувачів) потоку не передається ані команда «запит на DRP-резервування», ані команда «відповідь на запит на DRP-резервування». Тому цей різновид DRP-погодження придатний для пристроїв, що не підтримують конкурентний доступ до каналів. Пристрій ініціює неявне DRP-погодження тільки з пристроями, які підтримують можливість принаймні неявного DRP-погодження. Пристрої, які підтримують можливість явного DRP-погодження за допомогою командних/керуючих пакетів протоколу DRP, підтримують також і можливість неявно 29 го DRP-погодження. Можуть існувати пристрої, які дійсно підтримують лише неявне DRP-погодження. Пристрій може почати неявне DRPпогодження шляхом включення в свій пакетмаячок 105 відповідного інформаційного елемента DRP IE 700. Біт «Tx/Rx» в елементі DRP IE є «0» у випадку, якщо пристрій має намір бути відправником у запланованому передаванні, або є «1» у випадку, якщо пристрій буде одержувачем. Поле «ідентифікатор відправника/одержувача» 704 встановлюється рівним ідентифікатору партнера (партнерів) по з'єднанню. Поле StreamID для нових потоків встановлюється рівним значенню, що не використовується на даний момент для даної групи пристроїв. Пакет-маячок 105 з інформаційним елементом DRP IE 700 передається в період ВР 101, в якому партнер по з'єднанню передає свої пакети-маячки. Це останнє правило втрачає актуальність при наявності лише одного періоду ВР, як у варіанті здійснення даного винаходу, якому віддається перевага. Пристрій, що підтримує4 неявне DRPпогодження, моніторить всі пакети-маячки 105 під час власних періодів ВР 101 для виявлення свого ідентифікатора в полі «ідентифікатор відправника/одержувача» 704 всіх елементів DRP IE 700. Якщо поле «ідентифікатор відправника/одержувача» 704 співпадає з його власним ідентифікатором, пристрій перевіряє, чи використовується вже цей StreamID 805 для обміну даними з відправником пакета-маячка 105. Якщо StreamID 805 не використовується, це вказує на нове неявне DRP-погодження. Неявне DRP-погодження, що має на меті зміну існуючого потоку, вважається новим неявним DRP-погодженням. Одержувач елемента DRP IE 700, що міститься в пакеті-маячку 105, оцінює, чи вільне середовище передавання даних в час, що є предметом запиту, відповідно до локально збереженої інформації. Якщо середовище вільне, і на час, що є предметом запиту, не заплановане ані передавання, ані прийом, пристрій може перенести елемент DRP IE 700 у власний наступний пакет-маячок 105, інвертувавши біт «Tx/Rx» 801 і замінивши ідентифікатор партнера по з'єднанню в полі «ідентифікатор відправника/одержувача» 704. Такий елемент DRP IE тлумачиться як позитивна відповідь на ініційоване неявне DRP-погодження. Якщо одержувач елемента DRP IE 700, що міститься в ініціюючому пакеті-маячку 105, не може погодитись на неявне резервування через конфлікт з іншим резервуванням, він може запропонувати в своєму елементі DRP IE 700 альтернативні зсуви відносно BPST або ТВТТ 705. Він може також включити бітовий масив, або застосувати для цієї мети і зсув, і бітовий масив. У альтернативному варіанті здійснення даного винаходу, в якому в елемент DRP IE вже включений бітовий масив, додаткового бітового масива не потрібно. Ініціатор неявного погодження може прийняти одну з альтернативних пропозицій щодо резервування і включити її в наступні пакети-маячки 105, або може повторно ініціювати процес погодження з новою пропозицією щодо резервування. Останнє не потрібно, якщо пристрій, що відповідає, включив 93028 30 всі можливі зсуви відносно BPST і тривалість у свій пакет-маячок, наприклад, у вигляді бітового масиву. Включення всіх придатних для резервування інтервалів часу в пакети-маячки пристроїв, що відповідають, особливо корисне у випадку потоків, призначених для групи пристроїв, бо дозволяє відправнику віднайти загальноприйнятий час для резервування. Одержувачі, які не можуть бути обслужені в остаточно вибраному періоді резервування, могли б бути обслужені в інтервали часу, окремо зарезервовані для групового з'єднання або з'єднання з одним конкретним пристроєм. Такі резервування необхідно визначати в межах окремих DRP-погоджень Якщо одержувач інформаційного елемента DRP IE 700, що міститься в ініціюючому пакетімаячку 105, виявить, що впродовж запропонованого для резервування часу середовище передавання даних зайняте і визначення альтернативного інтервалу часу є неможливим, або якщо пристрій не бажає погоджувати дане резервування з якихось інших причин, він переносить елемент DRP IE 700 у власний наступний пакет-маячок 105 з інвертованим битом «Tx/Rx» 801, з ідентифікатором партнера по з'єднанню в полі «ідентифікатор відправника/одержувача» 704 і з полем «тривалість» 706, рівним нулю. Такий елемент DRP IE 700, в якому поле «тривалість» 706 дорівнює нулю, тлумачиться як негативна відповідь на ініціювання неявного DRP-погодження. У цьому випадку ініціатор не повторює ініціювання неявного DRPпогодження. Якщо відправник і одержувач (одержувачі) успішно погодили резервування, вони вміщують інформацію про резервування в свої відповідні пакети-маячки 105 в періоди ВР 101 наступних суперкадрів 100. У альтернативному варіанті здійснення винаходу тільки одержувач (одержувачі) включає інформацію про резервування в свій пакет-маячок. У ще одному варіанті здійснення інформацію про резервування включають у свої пакети-маячки одержувач і всі його найближчі («onehop») пристрої-сусіди. У ще одному варіанті здійснення інформацію про резервування включають в свої пакети-маячки відправник, одержувач і всі найближчі («one-hop») сусіди відправника і одержувача. У тому випадку, якщо або відправник, або одержувач адресованого одному конкретному пристрою потоку, або відправник адресованого групі пристроїв потоку побажають змінити резервування, вони можуть ініціювати нове неявне DRPпогодження. Ідентифікатор StreamID 805 старого потоку може лишитися тим самим. Саме з цієї причини пристрій, який підтримує неявне DRPпогодження, перевіряє всі прийняті елементи DRP IE 700 власних існуючих потоків на зміни в полях, що стосуються резервування (наприклад, «тривалість» 706, «зсув відносно BPST або ТВТТ» 705) (і факультативне поле «номер каналу» 806). Змінений елемент DRP IE 700 вважається ініціюванням нового неявного DRP-погодження. Якщо виявлено сусідній період ВР 101, DRP IE 700 типу «жорстке» і підтипу «період ВР» включа 31 ється в пакет-маячок 105 для захисту сусіднього періоду ВР 101. Пристрої, які приймають інформацію про резервування в пакеті-маячку 105 іншого пристрою, зберігають цю інформацію про резервування локально і утримуються від доступу до середовища передавання даних в оголошений момент часу, вказаний полем «зсув відносно BPST» або «зсув відносно ТВТТ» 702 елемента DRP IE 700. Тільки власнику резервування дозволений доступ до середовища передавання даних на початку зарезервованого інтервалу часу. Може трапитись так, що дві незалежні групи пристроїв можуть здійснювати DRP-погодження паралельно. У цьому випадку може виникнути конфлікт між резервуваннями, який повинен бути розв'язаний. Якщо пристрій приймає інформацію про резервування якогось часу в майбутньому, на який цей пристрій сам зарезервував середовище передавання даних, пристрою дозволяється залишити його власне резервування тільки в тому випадку, якщо пріоритет запланованого цим пристроєм передавання вище, ніж пріоритет прийнятого резервування. У випадку рівних пріоритетів перевагу має резервування пристрою-відправника з меншим ідентифікатором StreamID; саме тому StreamID вибирається випадковим чином. Якщо пристрій виявить, що його власне резервування перекривається іншим пристроєм, він скасовує своє заплановане передавання і намагається здійснити нове резервування в наступному суперкадрі 100. Всі пристрої змінюють свою інформацію про резервування, що локально зберігається, в тому випадку, якщо вони одержують інформацію про резервування з вищим пріоритетом або з меншим ідентифікатором StreamID, яке стосується того самого інтервалу часу або інтервалу часу, що перетинається з первісним інтервалом часу. Пристрій скасовує резервування, яке було визначене шляхом явного DRP-погодження, шляхом передавання DRP-команди «скасування резервування». Команда «скасування DRPрезервування», яка стосується потоку, адресованого конкретному пристрою, підтверджується пакетом негайного підтвердження (Imm Ack) (див. Фіг.19). У разі скасування, що стосується потоку, адресованого групі пристроїв, команда «скасування DRP-резервування» не повинна бути підтверджена (див. Фіг.20). 93028 32 В альтернативному варіанті здійснення винаходу не тільки пристрій, який скасовує DRPрезервування, але і всі пристрої, що раніше передавали інформацію про це резервування в своїх пакетах-маячках, передають DRP-команду «скасування». Потоки, які були утворені за допомогою неявного DRP-погодження, можуть бути скасовані шляхом видалення елемента DRP IE 700 з пакетамаячка 105, або, як альтернатива, встановленням поля «тривалість» елемента DRP IE рівним нулю (або, як альтернатива, встановленням всіх бітів бітового масива рівними нулю) з подальшим видаленням елемента DRP IE. Відсутність елемента DRP IE 700 у коректно прийнятому пакеті-маячку 105 тлумачиться як скасування потоку. В альтернативному варіанті здійснення цей механізм може бути також використаний замість команди «скасування DRP-резервування» для скасування потоків, які були утворені за допомогою явного погодження. Як тільки DRP-резервування скасоване, всі відповідні пристрої звільняють свої пакети-маячки 105 від елемента DRP IE 700. Якщо приймається пакет-маячок 105 без елемента DRP IE 700, всі пристрої можуть видалити будь-яку локальну інформацію, що стосується резервування, пов'язаного з відсутнім елементом DRP IE. Якщо пристрій не приймає пакет-маячок 105 з одним або декількома елементами DRP IE 700 у послідовних суперкадрах кількістю mMaxLostBeacons, цей пристрій вивільнює зарезервовані за протоколом DRP інтервали часу, про які повідомлялось в цьому пакеті-маячку 105. Хоч були описані і проілюстровані варіанти здійснення даного винаходу, яким віддається перевага,фахівці в даній галузі техніки зрозуміють, що керівні пакети, архітектура пристрою і способи, як вони тут описані, є ілюстративними прикладами, і без виходу за рамки даного винаходу можливі різні зміни і модифікації, а також заміна їхніх елементів еквівалентними. Крім того, для пристосування ідей даного винаходу до конкретної ситуації можливі численні модифікації - без виходу за межі винаходу. Тому цей винахід не обмежується конкретними варіантами здійснення, розкритими як найкращий спосіб здійснення даного винаходу, але включає в себе всі варіанти здійснення, що не виходять за межі формули винаходу. 33 93028 34 35 93028 36 37 93028 38 39 Комп’ютерна верстка А. Рябко 93028 Підписне 40 Тираж 26 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП ―Український інститут промислової власності‖, вул. Глазунова, 1, м. Київ – 42, 01601