Керування бездротовими ретрансляційними вузлами з використанням індентифікаторів

Реферат: Набір бездротових ретрансляційних вузлів керується, щоб спрощувати міжвузлову маршрутизацію пакетів в наборі. У деяких аспектах, унікальні ідентифікатори задаються для бездротових ретрансляційних вузлів, щоб спрощувати маршрутизацію пакетів в рамках набору. У деякому аспекті, таблиця маршрутизації надається в кожний з бездротових ретрансляційних вузлів, при цьому таблиця маршрутизації ідентифікує кожний бездротовий ретрансляційний вузол в наборі та об'єкт наступної ретрансляції для кожного з цих бездротових ретрансляційних вузлів. Кожний з бездротових ретрансляційних вузлів потім може задавати таблицю перенаправления на основі таблиці маршрутизації. UA 100546 C2 (12) UA 100546 C2 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 Дана заявка заявляє перевагу і пріоритет попередньої заявки, що знаходиться у спільній власності на патент (США) № 61/024764, яка подана 30 січня 2008 року і має адвокатську виписку № 080566P1; розкриття суті якої тим самим міститься за посиланням в даному документі. Перехресне посилання на споріднену заявку Дана заявка належить до заявки, що одночасно подана і знаходиться у спільній власності на патент (США) № 12/361448, яка озаглавлена «MANAGEMENT OF WIRELESS RELAY NODES USING ROUTING TABLE» і має адвокатську виписку номер 080566U2, розкриття суті якої тим самим міститься за посиланням в даному документі. Рівень техніки Галузь техніки, до якої належить винахід Дана заявка, загалом, належить до бездротового зв’язку, а більш конкретно, але не тільки, до керування бездротовими ретрансляційними вузлами. Вступ Системи бездротового зв’язку широко розгорнені для того, щоб надавати різні типи зв'язку (наприклад, мову, дані, мультимедійні послуги тощо) декільком користувачам. Оскільки попит на послуги високошвидкісної передачі і передачі мультимедійних даних швидко зростає, виникає складна задача, щоб реалізовувати ефективні та відмовостійкі системи зв'язку з підвищеною продуктивністю. Щоб доповнювати традиційні базові станції мобільної телефонної мережі, додаткові базові станції можуть розгортатися, щоб надавати більш відмовостійке покриття бездротового зв’язку для мобільних модулів. Наприклад, бездротові ретрансляційні станції і базові станції з невеликим покриттям (наприклад, які звичайно називаються базовими станціями точки доступу, власними вузлами В або фемтостільниками) можуть розгортатися для інкрементного підвищення пропускної здатності, розширення функціональних можливостей користувачів і забезпечення покриття всередині будівель. Оскільки ці інші типи базових станцій можуть додаватися в традиційну мобільну телефонну мережу (наприклад, транзитну) способом, відмінним від традиційних базових станцій (наприклад, базових макростанцій), є потреба в ефективних технологіях для керування цими іншими типами базових станцій. Суть винаходу Суть зразкових аспектів розкриття суті наводиться нижче. Потрібно розуміти, що посилання на термін «аспекти» в даному документі можуть посилатися на один або більше аспектів розкриття суті. Дане розкриття суті відноситься в деякому аспекті до керування бездротовими ретрансляційними вузлами. Наприклад, розкриваються технології для конфігурування набору бездротових ретрансляційних вузлів таким способом, який спрощує маршрутизацію пакетів в рамках набору. Дане розкриття суті відноситься в деякому аспекті до надання таблиці маршрутизації для набору бездротових ретрансляційних вузлів. Таблиця маршрутизації може ідентифікувати, наприклад, кожний бездротовий ретрансляційний вузол в наборі та однострибковий об'єкт для кожного з цих бездротових ретрансляційних вузлів. Кожний з бездротових ретрансляційних вузлів потім може задавати таблицю перенаправлення на основі таблиці маршрутизації. Таблиця перенаправлення, в свою чергу, може використовуватися за допомогою бездротових ретрансляційних вузлів для того, щоб ефективно перенаправляти пакети між бездротовими ретрансляційними вузлами набору. Дане розкриття суті відноситься в деякому аспекті до надання ідентифікаторів бездротових ретрансляційних вузлів, які використовуються для того, щоб спрощувати маршрутизацію пакетів у рамках набору бездротових ретрансляційних вузлів. Різний ідентифікатор може бути заданий для кожного бездротового ретрансляційного вузла набору. У деяких аспектах, ці ідентифікатори використовуються (наприклад, за допомогою протоколу керування ретрансляцією), щоб описувати топологію набору бездротових ретрансляційних вузлів. Крім цього, пакети, що маршрутизуються в рамках набору, можуть включати в себе відповідні ідентифікатори бездротових ретрансляційних вузлів, щоб ідентифікувати вихідний вузол і/або цільовий вузол для пакетів в рамках набору. Таким чином, коли бездротовий ретрансляційний вузол набору приймає пакет, бездротовий ретрансляційний вузол може визначати те, як перенаправляти пакет, на основі ідентифікатора призначення в пакеті і на основі таблиці перенаправлення. У деяких аспектах, ідентифікатори бездротових ретрансляційних вузлів використовуються для того, щоб ефективно маршрутизувати стиснуті пакети. Наприклад, заголовок пакета, який повинен маршрутизуватися через набір бездротових ретрансляційних вузлів, може стискуватися, щоб зменшувати обсяг службового трафіку. Оскільки традиційні адреси джерела і 1 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 призначення пакета також можуть стискуватися в цьому випадку, ідентифікатор бездротового ретрансляційного вузла може додаватися до пакета, щоб надавати інформацію джерела і призначення для маршрутизації пакета в рамках набору. Переважно, ідентифікатор бездротового ретрансляційного вузла може бути відносно невеликим (наприклад, в порівнянні з традиційними адресами джерела і призначення). Таким чином, використання цього ідентифікатора може трохи збільшувати обсяг службової інформації з маршрутизації в системі. Ідентифікатори бездротових ретрансляційних вузлів можуть приймати різні форми в різних реалізаціях. У деяких реалізаціях більш глобально унікальні (наприклад, на противагу заданим унікальним) ідентифікатори можуть використовуватися для того, щоб ідентифікувати вузли кластера. Наприклад, адреси Інтернет-протоколу (IP), призначені ретрансляторам, можуть використовуватися для того, щоб маршрутизувати пакети в рамках набору бездротових ретрансляційних вузлів (тобто ідентифікатори бездротових ретрансляційних вузлів можуть містити IP-адреси). Альтернативно, в деяких реалізаціях ідентифікатори бездротових ретрансляційних вузлів - це MAC-адреси бездротових ретрансляційних вузлів. У деяких реалізаціях може використовуватися перенаправлення рівня 2 або рівня 3, при якому всі бездротові ретрансляційні вузли в наборі є частиною однієї підмережі. У деяких реалізаціях може використовуватися маршрутизація рівня 3, при якій каскадні підмережі задаються для кожного бездротового ретрансляційного вузла в наборі. Короткий опис креслень Ці та інші зразкові аспекти розкриття суті описуються в докладному описі та прикладеній формулі винаходу, яка наведена нижче, і на прикладених кресленнях, на яких: Фіг.1 є спрощеною блок-схемою декількох зразкових аспектів системи зв'язку, що включає в себе набір бездротових ретрансляційних вузлів; Фіг.2 є блок-схемою послідовності операцій способу декількох зразкових аспектів операцій, які можуть виконуватися для того, щоб керувати набором бездротових ретрансляційних вузлів і маршрутизувати пакети через набір бездротових ретрансляційних вузлів; Фіг.3 є спрощеною блок-схемою декількох зразкових аспектів компонентів зв'язку; і Фіг.4A та 4B є блок-схемою послідовності операцій способу декількох зразкових аспектів операцій, які можуть виконуватися для того, щоб керувати набором бездротових ретрансляційних вузлів; Фіг.5A та 5B є блок-схемою послідовності операцій способу декількох зразкових аспектів операцій, які можуть виконуватися для того, щоб маршрутизувати пакети в рамках набору бездротових ретрансляційних вузлів; Фіг.6 є спрощеною блок-схемою декількох зразкових аспектів компонентів зв'язку; і Фіг.7-10 є спрощеними блок-схемами декількох зразкових аспектів пристроїв, виконаних з можливістю надавати керування бездротовими ретрансляційними вузлами, як розглядається в даному документі. Відповідно до сталої практики, різні ознаки, проілюстровані на кресленнях, можуть не бути намальовані в масштабі. Відповідно, розміри різних ознак можуть бути довільно збільшені або зменшені для розуміння. Крім цього, деякі з креслень можуть бути спрощені для розуміння. Таким чином, креслення можуть не ілюструвати всі компоненти даного пристрою (наприклад, пристрої) або способу. Нарешті, аналогічні номери посилань можуть використовуватися для того, щоб означати аналогічні ознаки по всьому докладному опису і кресленнях. Докладний опис винаходу Різні аспекти розкриття суті описуються нижче. Повинне бути очевидним те, що ідеї в даному документі можуть бути здійснені у множині форм, і що всі конкретні структури, функції або і те, і інше, розкрите в даному документі, є просто характерними. На основі ідей в даному документі, фахівці в даній галузі техніки повинні брати до уваги, що аспекти, розкриті в даному документі, можуть бути реалізовані незалежно від будь-яких інших аспектів, і що два або більше з цих аспектів можуть бути комбіновані різними способами. Наприклад, пристрій може бути реалізований або спосіб може бути використаний на практиці за допомогою будь-якої кількості аспектів, викладених в даному документі. Крім цього, такий пристрій може бути реалізований або спосіб може бути використаний на практиці за допомогою іншої структури, функціональності або структур і функціональності, крім або відмінної від одного або більше аспектів, викладених у даному документі. Крім того, аспект може містити щонайменше один елемент формули винаходу. Фіг.1 ілюструє декілька вузлів у зразковій системі 100 зв'язку (наприклад, частини мережі зв'язку). З метою ілюстрації, різні аспекти розкриття суті описуються в контексті одного або більше бездротових ретрансляційних вузлів, точок доступу, терміналів доступу і мережних вузлів, які обмінюються даними один з одним. Потрібно брати до уваги, однак, те, що ідеї в 2 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 даному документі можуть бути застосовні до інших типів пристроїв або інших аналогічних пристроїв, які згадуються з використанням інших термінів. Наприклад, точка доступу може реалізовуватися або згадуватися як базова станція або е-вузол В, тоді як термінал доступу може реалізовуватися або згадуватися як абонентський пристрій або мобільний модуль. Точки доступу (наприклад, коренева точка 102 доступу) і бездротові ретрансляційні вузли (наприклад, бездротові ретрансляційні вузли 104, 106, 108, 110 та 112) в системі 100 надають одну або більше послуг (наприклад, можливості мережного підключення) для одного або більше бездротових терміналів (наприклад, термінала 114 доступу), які можуть постійно розміщуватися в рамках або які можуть пересуватися по всій асоційованій географічній зоні. У прикладі за фіг.1, точка 102 доступу обмінюється даними з одним або більше мережних вузлів (представлених, для зручності, за допомогою мережного вузла 116), щоб спрощувати можливості підключення до глобальної обчислювальної мережі. Ці мережні вузли можуть приймати різні форми, такі як, наприклад, одна або більше радіостанцій і/або об'єктів базової мережі (наприклад, шлюзи доступу, об'єкти керування мобільністю, сеансові опорні мережні контролери або деякий інший відповідний мережний об'єкт або об'єкти). Фіг.1 і нижченаведений опис описує різні схеми керування набором бездротових ретрансляційних вузлів, щоб спрощувати маршрутизацію інформації (наприклад, пакетів) через набір. Зокрема, ідеї в даному документі можуть використовуватися для того, щоб ефективно маршрутизувати пакети по декількох ретрансляційних перескоках. У деяких аспектах, термін «коренева точка доступу» при використанні в даному документі згадується як точка доступу, яка використовує одну технологію для того, щоб надавати бездротовий доступ (наприклад, для терміналів доступу і/або бездротових ретрансляційних вузлів), і використовує іншу дротову або бездротову технологію для того, щоб надавати можливості транзитних з'єднань. У деяких аспектах, термін «бездротовий ретрансляційний вузол» при використанні в даному документі згадується як точка доступу, яка використовує ідентичну бездротову технологію для того, щоб надавати доступ (наприклад, для терміналів доступу) і надавати можливості транзитних з'єднань (наприклад, відправляти інформацію і приймати інформацію від базової мережі через кореневу мережу доступу або інший бездротовий ретрансляційний вузол). Таким чином, з точки зору термінала доступу, бездротовий ретрансляційний вузол може працювати в деяких аспектах як точка доступу. На відміну від цього, з точки зору кореневої точки доступу, бездротовий ретрансляційний вузол може працювати в деяких аспектах як термінал доступу. Для зручності, бездротовий ретрансляційний вузол може згадуватися просто як ретранслятор у нижченаведеному описі. У деяких аспектах, термін «ретрансляційний кластер» (який може просто згадуватися як кластер в даному документі) згадується як коренева точка доступу і набір бездротових ретрансляційних вузлів, які можуть передавати в базову мережу через цю кореневу мережу доступу. Тут, коренева точка доступу асоційована з одним кластером, тоді як ретранслятор може бути асоційований з одним або більше кластерів. Зразкові операції системи 100 далі описуються в зв'язку з блок-схемою послідовності операцій способу за фіг.2. Етапи 202-210 описують декілька операцій, які можуть виконуватися для того, щоб керувати набором ретрансляторів у кластері. Ці операції містять в собі, в деяких аспектах, керування (наприклад, створення і видалення) унікальними конкретними для кластера ідентифікаторами для кожного ретранслятора в кластері, зберігання перетворення між цими ідентифікаторами та іншими ідентифікаторами (наприклад, мережними ідентифікаторами), призначеними ретрансляторам, і зберігання таблиці маршрутизації, яка служить ознакою топології кластера, яку ретранслятори в кластері можуть використовувати для того, щоб формувати таблицю перенаправлення. Етапи 212 та 214 описують декілька операцій, які можуть виконуватися для того, щоб маршрутизувати пакети в рамках кластера (наприклад, перенаправляти пакети у відповідну лінію зв'язку), за допомогою вищезгаданої інформації. Наприклад, за допомогою збереженої зв'язаної з топологією інформації, маршрутизація може підтримуватися в або від термінала доступу, обслуговуючою мережею доступу якого є ретранслятор в кластері, і маршрутизація може підтримуватися в або від ретранслятора, обслуговуючою мережею доступу якого є ретранслятор в кластері. У деяких аспектах, операції за фіг.2 можуть виконуватися за допомогою протоколу керування ретрансляцією, реалізованого у вузлах кластера. Як представлено за допомогою етапу 202, унікальний ідентифікатор може бути заданий для кожного ретранслятора в кластері, і ці ідентифікатори можуть відправлятися в усі ретранслятори в кластері. Як детальніше пояснюється нижче, ретранслятори в кластері можуть використовувати ці ідентифікатори, щоб маршрутизувати пакети в рамках кластера. У деяких реалізаціях ідентифікатори використовуються тільки у випадках, коли стиснуті пакети маршрутизуються в рамках кластера. У таких випадках може стискуватися інформація 3 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 джерела і призначення в заголовку пакета. Таким чином, ідентифікатори можуть додаватися до пакетів, щоб спрощувати маршрутизацію пакетів в рамках кластера. Переважно, ідентифікатори можуть бути відносно невеликими (наприклад, 10 бітів або менше), оскільки вони повинні бути унікальними тільки в рамках кластера. Таким чином, пакети можуть ефективно маршрутизуватися в рамках кластера, оскільки додання ідентифікаторів не може призводити до значного обсягу службової інформації. Ідентифікатор може бути заданий для даного ретранслятора кожний раз, коли той ретранслятор приєднується до кластера. Наприклад, на фіг.1 ідентифікатор може бути заданий, коли ретранслятор 106 спочатку підключається до кореневої точки 102 доступу або коли ретранслятор 108 спочатку підключається до ретранслятора 104. У типовій реалізації ідентифікатор для нового ретранслятора задається за допомогою кореневої точки доступу кластера. Проте, в інших реалізаціях ретранслятор (наприклад, ретранслятор, з яким з’єднується новий ретранслятор) може задавати ідентифікатор для нового ретранслятора. У деяких аспектах, конкретний для кластера ідентифікатор для кожного ретранслятора асоційований з іншим ідентифікатором, який призначається цьому ретранслятору. У деяких аспектах, цей інший ідентифікатор може використовуватися для того, щоб унікально ідентифікувати даний ретранслятор в більш широкому діапазоні ідентифікаторів, ніж кластер. Наприклад, цей інший ідентифікатор може унікально ідентифікувати ретранслятор в рамках мережі (наприклад, приватної мережі, мережі оператора або глобальної мережі). У деяких реалізаціях цей інший ідентифікатор містить IP-адресу або оснований на IP-адресі, призначеній ретранслятору. Для зручності цей інший ідентифікатор може згадуватися в даному документі як ідентифікатор мережі. У деяких аспектах, ретранслятори кластера можуть використовувати ідентифікатори мережі, щоб перенаправляти пакети в інші вузли в кластері. У нижченаведеному описі можна передбачити, що ретрансляторам 104, 106, 108, 110 та 112 призначаються ідентифікатори мережі RS1, RS2, RS3, RS4 та RS5, відповідно. У деяких реалізаціях, конкретні для кластера ідентифікатори, задані для ретрансляторів у кластері, надаються в усі ретранслятори кластера в формі списку, який перетворює конкретний для кластера ідентифікатор для кожного ретранслятора в його асоційований ідентифікатор мережі. Наприклад, коли ретранслятор приєднується до кластера, ретранслятор може відправляти свій ідентифікатор мережі в кореневу точку доступу. Коренева точка доступу потім може оновлювати список з новим конкретним для кластера ідентифікатором та асоційованим ідентифікатором мережі для цього ретранслятора і відправляти список в усі ретранслятори в кластері. Знов посилаючись на фіг.2, як представлено за допомогою етапу 204, таблиця маршрутизації зберігається для кластера, і ця інформація таблиці маршрутизації може відправлятися в усі ретранслятори в кластері кожний раз, коли є зміна в кластері. Наприклад, коренева точка доступу кластера може задавати нову таблицю маршрутизації кожний раз, коли ретранслятор приєднується, переміщається в рамках або виходить з кластера. У деяких аспектах таблиця маршрутизації описує топологію кластера. Наприклад, таблиця маршрутизації може описувати деревоподібну зв'язаність для всіх ретрансляторів у кластері. Таблиця 1 ілюструє приклад таблиці маршрутизації, яка ідентифікує обслуговуючий вузол для кожного ретранслятора (тобто як ідентифіковано за допомогою конкретних для кластера ідентифікаторів ретрансляторів, описаних вище) в кластері. За допомогою фіг.1 як прикладу, ретрансляторам 104, 106, 108, 110 та 112 призначаються ідентифікатори 1, 2, 3, 4 та 5 ретрансляторів, відповідно. Кореневій точці 102 доступу призначається ідентифікатор 0. Таким чином, оскільки коренева точка 102 доступу є обслуговуючим вузлом для ретрансляторів 104 та 106, записом ідентифікатора обслуговуючого вузла в таблиці маршрутизації для кожного з ідентифікаторів 1 та 2 є ідентифікатор 0 обслуговуючого вузла. Аналогічно, оскільки ретранслятор 108 є обслуговуючим вузлом для ретрансляторів 110 та 112, записом ідентифікатора обслуговуючого вузла в таблиці маршрутизації для кожного з ідентифікаторів 4 та 5 ретрансляторів є ідентифікатор 3 обслуговуючого вузла. Ідентифікатор ретранслятора 1 2 3 4 5 Ідентифікатор вузла 0 0 1 3 3 Таблиця 1 обслуговуючого 4 UA 100546 C2 5 10 15 20 25 30 35 Як представлено за допомогою етапу 206 на фіг.2, кожний з ретрансляторів у кластері приймає конкретні для кластера ідентифікатори, відправлені на етапі 202. Як згадано вище, ці ідентифікатори можуть відправлятися в формі списку, який також включає в себе інші ідентифікатори, які асоційовані з ретрансляторами. Таким чином, кожний ретранслятор в кластері може зберігати таблицю, яка перелічує ідентифікатори, асоційовані з кожним ретранслятором, який знаходиться в даний момент в кластері. Як представлено за допомогою етапу 208, кожний з ретрансляторів у кластері також приймає інформацію таблиці маршрутизації, відправлену на етапі 204. Таким чином, кожний ретранслятор в кластері може зберігати таблицю, яка описує поточну топологію кластера. Як представлено за допомогою етапу 210, кожний з ретрансляторів у кластері може задавати таблицю перенаправлення на основі інформації з таблиці маршрутизації. У деяких аспектах, таблиця перенаправлення для даного ретранслятора може включати в себе запис для кожного ретранслятора, який є низхідним для цього ретранслятора. Як показано в таблицях 2 та 3, кожний запис в таблиці перенаправлення може включати в себе, наприклад, ідентифікатор низхідного ретранслятора (ідентифікатор ретранслятора) та ідентифікатор наступної лінії зв'язку (ідентифікатор наступної лінії зв'язку) від поточного ретранслятора в напрямку низхідного ретранслятора. Звертаючись знов до прикладу за фіг.1, таблиця 2 ілюструє таблицю перенаправлення для ретранслятора 104. У цьому випадку передбачено три низхідних ретранслятора: ретранслятори 108, 110 та 112, яким призначені ідентифікатори 3, 4 та 5 ретрансляторів, відповідно. Внаслідок топології за фіг.1 (як вказано за допомогою таблиці маршрутизації, таблиці 1), наступною лінією зв'язку, низхідною по відношенню до ретранслятора 104 для кожного з цих ретрансляторів, є ретранслятор 108. Таким чином, глобальний ідентифікатор, призначений ретранслятору 108 (RS3), використовується як ідентифікатор наступної лінії зв'язку для кожного з цих ідентифікаторів ретрансляторів. Аналогічно, таблиця 3 ілюструє таблицю перенаправлення для ретранслятора 108. У цьому випадку передбачено два низхідних ретранслятора: ретранслятори 110 та 112, яким призначені ідентифікатори 4 та 5 ретрансляторів, відповідно. Внаслідок топології за фіг.1 (як вказано за допомогою таблиці маршрутизації, таблиці 1), наступною лінією зв'язку, низхідною по відношенню до ретранслятора 108 для ретранслятора 110, є ретранслятор 110, і наступною лінією зв'язку, низхідною по відношенню до ретранслятора 108 для ретранслятора 112, є ретранслятор 112. Таким чином, глобальний ідентифікатор, призначений ретранслятору 110 (RS4), використовується як ідентифікатор наступної лінії зв'язку для ідентифікатора 4 ретранслятора, а глобальний ідентифікатор, призначений ретранслятору 112 (RS5), використовується як ідентифікатор наступної лінії зв'язку для ідентифікатора 5 ретранслятора. Ідентифікатор ретранслятора 3 4 5 Інший Ідентифікатор ретранслятора 4 5 Інший 40 45 Таблиця 2 Ідентифікатор наступної лінії зв'язку RS3 RS3 RS3 Значення за умовчанням (висхідна лінія зв'язку) Таблиця 3 Ідентифікатор наступної лінії зв'язку RS4 RS5 Значення за умовчанням (висхідна лінія зв'язку) Таблиці 2 та 3 також ілюструють, що таблиця перенаправлення може задавати лінію зв'язку за умовчанням, щоб розглядати випадок, коли ретранслятор приймає пакет, який призначається для ретранслятора, який не є низхідним. Наприклад, якщо ретранслятор 104 приймає пакет, який має призначення ідентифікатора 2 ретранслятора, ретранслятор 104 може відправляти пакет по висхідній лінії зв'язку (тобто в кореневу точку 102 доступу). Аналогічно, якщо ретранслятор 108 приймає пакет, який має призначення ідентифікатора 1 або 2 ретранслятора, ретранслятор 108 може відправляти пакет по висхідній лінії зв'язку (тобто в ретранслятор 104). Коли таблиці перенаправлення встановлені в кожному ретрансляторі в кластері, 5 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 ретранслятори можуть використовувати таблицю перенаправлення, щоб маршрутизувати пакети в рамках кластера. Наприклад, як детальніше описано нижче, коли пакет повинен відправлятися через кластер, вузол кластера (наприклад, коренева точка доступу або ретранслятор) може додавати заголовок, який включає в себе конкретні для кластера ідентифікатори, асоційовані з джерелом і призначенням для пакета, якщо застосовно. Таким чином, як представлено за допомогою етапу 212, в деякій точці у часі ретранслятор може приймати пакет, який повинен маршрутизуватися в рамках кластера. Ретранслятор потім може визначати те, включає чи ні пакет в себе конкретний для кластера ідентифікатор. Якщо так, як представлено за допомогою етапу 214, ретранслятор визначає те, як обробляти пакет, на основі конкретного для кластера ідентифікатора в пакеті і таблиці перенаправлення. Наприклад, ретранслятор може вибирати обробляти пакет, якщо цей ретранслятор є планованим призначенням, як вказано за допомогою конкретного для кластера ідентифікатора в пакеті. На відміну від цього, ретранслятор може вибирати перенаправляти пакет, якщо цей ретранслятор не є планованим призначенням. У цьому випадку, ретранслятор може використовувати таблицю перенаправлення, щоб визначати вузол в кластері, в який повинен відправлятися пакет. З урахуванням вищевикладеного, додаткові подробиці, що стосуються керування кластером і маршрутизації пакетів у рамках кластера, описуються в контексті блок-схем послідовності операцій способу фіг.4A-5B. Зокрема, фіг.4A та 4B описують зразкові операції, які можуть використовуватися для того, щоб керувати ідентифікаторами та асоційованими списками або таблицями в кластері. У цьому прикладі передбачається, що коренева точка доступу для кластера задає ідентифікатори і таблицю маршрутизації, що використовується за допомогою ретрансляторів кластера. Фіг.5A та 5B описують зразкові операції, які можуть використовуватися для того, щоб маршрутизувати пакети в рамках кластера з використанням керованої інформації. Для ілюстрації, операції фіг.4A-5B описуються, частково, в контексті мережі, в якій вузли мережі можуть обмінюватися даними один з одним за допомогою встановлення маршрутів між вузлами. Прикладом цієї мережі є мережа за стандартом надширокосмугового зв'язку для мобільних пристроїв. Тут, ідентифікатор мережі, що згадується вище, може містити ідентифікатор вузла доступу (ANID). Крім цього, конкретний для кластера ідентифікатор може містити стиснутий ANID (наприклад, що містить тільки невелику кількість бітів). ANID може використовуватися в багатострибковій передачі, щоб ідентифікувати ретранслятор у кластері. Наприклад, ANID для ретранслятора може бути визначений на основі IP-адреси, призначеної ретранслятору. Оскільки IP-адреса є частиною сеансу ретранслятора, IP-адреса не повинна передаватися кожний раз, коли ретранслятор відкриває маршрут. Для зручності операції фіг.4A-5B (або будь-які інші операції, що пояснені або розглядаються в даному документі) можуть описуватися як такі, що виконуються за допомогою конкретних компонентів (наприклад, компонентів системи 300, як показано на фіг.3). Потрібно брати до уваги, однак, що ці операції можуть бути виконані за допомогою інших типів компонентів і можуть бути виконані за допомогою іншої кількості компонентів. Також потрібно брати до уваги, що одна або більше з операцій, описаних в даному документі, можливо, не використовується в даній реалізації. Фіг.3 ілюструє зразкові компоненти, які можуть використовуватися у вузлі 302, який керує кластером (наприклад, кореневій точці доступу), і вузлі 304, який надає доступ (наприклад, ретрансляторі). Щоб зменшувати складність фіг.3, тільки два вузли показуються в системі 300. На практиці, проте, система, така як система 300 (наприклад, яка відповідає системі 100) може мати множину вузлів, які працюють як керуючі вузли, і множину вузлів, які працюють як вузли доступу в даний час. Вузли 302 та 304 включають в себе відповідні приймально-передавальні пристрої 306 та 308 для обміну даними один з одним і з іншими вузлами в системі 300. У деяких реалізаціях вузол 304 включає в себе інший приймально-передавальний пристрій 310 для обміну даними з іншими вузлами (наприклад, терміналами доступу) в системі 300. Тут, приймальнопередавальні пристрої 308 та 310 можуть здійснювати один тип бездротової технології (наприклад, LTE-радіоінтерфейс). В інших реалізаціях, однак, вузол 304 може включати в себе один приймально-передавальний пристрій (наприклад, приймально-передавальний пристрій 308), який виконаний з можливістю підтримувати як бездротовий зв'язок по мережах доступу, так і бездротовий зв’язок по транзитних з'єднаннях. У деяких випадках, вузол 304 може обмінюватися даними з одним вузлом (наприклад, точкою доступу) в деяких чергуваннях та обмінюватися даними з іншим вузлом (наприклад, терміналом доступу) в інших чергуваннях. Приймально-передавальний пристрій 306 включає в себе передавальний пристрій 312 для 6 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 відправки сигналів (наприклад, пакетів для керування ретрансляцією та іншого трафіку) і приймальний пристрій 314 для прийому сигналів. Приймально-передавальний пристрій 308 також включає в себе передавальний пристрій 316 для відправки сигналів і приймальний пристрій 318 для прийому сигналів. Аналогічно, приймально-передавальний пристрій 310 включає в себе передавальний пристрій 320 для відправки сигналів і приймальний пристрій 322 для прийому сигналів. З метою ілюстрації декілька компонентів, які можуть використовуватися в зв'язку з керуванням кластером і відправкою/прийомом трафіку, показуються у вузлі 302. Потрібно брати до уваги, що частина або вся ця функціональність може реалізовуватися в інших вузлах (наприклад, в деяких реалізаціях ретранслятор може надавати функціональність кластерного керування). Як показано, вузол 302 може включати в себе диспетчер 324 ретрансляторів, який надає функціональність, що стосується керування ретрансляторами в асоційованому кластері. Інші аспекти диспетчера 324 ретрансляторів детальніше описані нижче. Вузол 302 також може включати в себе контролер 326 зв'язку для обробки трафіку (наприклад, керування передачею і прийомом пакетів) і надання інших зв'язаних із зв'язком операцій. Крім того, вузол 302 може включати в себе пакетний процесор 328 для обробки пакетів (наприклад, надання пакетів, які повинні бути передані, і обробки пакетів, що приймаються) і надання інших зв'язаних операцій. З метою ілюстрації декілька компонентів, які можуть використовуватися в зв'язку з відправкою/прийомом трафіку в бездротовому ретрансляційному вузлі, показуються у вузлі 304. Потрібно брати до уваги, що аналогічна функціональність може реалізовуватися в інших бездротових ретрансляційних вузлах у системі 300. Вузол 304 включає в себе диспетчер 330 топології ретрансляторів, який надає функціональність, що стосується збереження інформації (наприклад, інформації топології) для асоційованого кластера. Інші аспекти диспетчера 330 топології ретрансляторів детальніше описані нижче. Вузол 304 також може включати в себе контролер 332 зв'язку для обробки трафіку (наприклад, керування передачею і прийомом пакетів) і надання інших зв'язаних із зв'язком операцій. Крім того, вузол 304 може включати в себе пакетний процесор 334 для обробки пакетів (наприклад, надання пакетів, які повинні бути передані, і обробки пакетів, що приймаються) і надання інших зв'язаних операцій. Посилаючись тепер на фіг.4A, як представлено за допомогою етапу 402, в деякій точці у часі ретранслятор приєднується до кластера або переміщається в рамках кластера. Як приклад першого сценарію, ретранслятор 110 за фіг.1, який встановлений в зоні покриття ретранслятора 108, можливо, недавно включений і підключений до ретранслятора 108. Як приклад другого сценарію, ретранслятор 112 може бути мобільним вузлом, який підключений до ретранслятора 106, але переміщений в зону покриття ретранслятора 108 і тепер підключається до ретранслятора 108. Як представлено за допомогою етапу 404, в зв'язку з приєднанням або переміщенням в рамках кластера, ретранслятор може запитувати конкретний для кластера ідентифікатор. Наприклад, ретранслятор може передавати повідомлення, яке запитує задавання ідентифікатора для цього ретранслятора. Тут, повідомлення із запитом може включати в себе ідентифікатор мережі ретранслятора. Отже, вузол, який задає ідентифікатор, може оновлювати свій список ідентифікаторів ретрансляторів для кластера з цією інформацією. У прикладі за фіг.3, формувач 336 запитів може формувати запит і взаємодіяти з передавальним пристроєм 316, щоб передавати запит. У деяких реалізаціях (наприклад, основаній на LTE реалізації), ретранслятор може відправляти запит у вузол, до якого підключений ретранслятор. Наприклад, ретранслятор 110 за фіг.1 може відправляти запит в ретранслятор 108. У цьому випадку, ретранслятор 108 (наприклад, контролер 338 ідентифікаторів у ретрансляторі) може визначати те, що він не може обробляти цей запит (наприклад, на основі ідентифікатора повідомлення в запиті). Ретранслятор 108 потім може перенаправляти повідомлення у вузол, до якого він підключений (наприклад, ретранслятор 104). Цей процес може продовжуватися доти, доки запит не досягає вузла, який обробляє запит (наприклад, кореневої точки 102 доступу). У прикладі за фіг.3, процесор 340 запитів може взаємодіяти з приймальним пристроєм 314, щоб приймати запит, після чого процесор 340 запитів обробляє запит. У деяких реалізаціях (наприклад, основаній на UMB реалізації), ретранслятор може встановлювати маршрут до вузла, який повинен обробляти запит, і потім відправляти запит в цей вузол через маршрут. У цьому випадку, після прийому індикатора RouteOpen, ретранслятор може виконувати нижченаведені операції. Ретранслятор відправляє повідомлення RootRequest за маршрутом. Якщо ретранслятор не має маршруту до ANID в RootResponse, ретранслятор може відкривати маршрут до кореневої точки доступу і переміщувати свою точку приєднання даних (якщо треба) в кореневу точку доступу для обслуговуючого е-вузла В прямій лінії зв'язку 7 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 (FLSE). Ретранслятор може відправляти IDRequest в кореневу точку доступу після прийому RouteOpenAccept від кореневої точки доступу. Як представлено за допомогою етапу 406, коренева точка доступу задає конкретний для кластера ідентифікатор для ретранслятора (наприклад, при прийомі запиту від ретранслятора). Як згадано вище, оскільки запит може включати в себе ідентифікатор мережі ретранслятора, коренева точка доступу може асоціювати новий заданий ідентифікатор з цим ідентифікатором мережі. У прикладі за фіг.3, ці операції можуть виконуватися за допомогою модуля 342 задавання ідентифікаторів. Коренева точка доступу може відповідати на запит за допомогою відправки нового заданого ідентифікатора в ретранслятор на етапі 408. У прикладі за фіг.3, модуль 342 задавання ідентифікаторів може взаємодіяти з контролером 326 зв'язку і передавальним пристроєм 312, щоб передавати відповідь. Ретранслятор потім може приймати відповідь на запит на етапі 410. У прикладі за фіг.3, контролер 338 ідентифікаторів може взаємодіяти з приймальним пристроєм 314, щоб приймати відповідь, і контролер 338 ідентифікаторів обробляє відповідь, щоб одержувати ідентифікатор. У деяких реалізаціях (наприклад, основаній на UMB реалізації), коренева точка доступу призначає конкретний для кластера ідентифікатор після прийому індикатора RouteOpen для ретранслятора (наприклад, після прийому IDRequest від ретранслятора, як пояснено вище). Коренева точка доступу потім відправляє повідомлення IDAssign в ретранслятор, яке включає в себе призначений конкретний для кластера ідентифікатор для цього ретранслятора. Коли ретранслятор приймає призначення ідентифікатора через повідомлення IDAssign, ретранслятор може задавати свій CurrentID рівним ідентифікатору в повідомленні IDAssign і відправляти повідомлення підтвердження прийому IDAssignAck в кореневу точку доступу. Як згадано вище, коренева точка доступу може зберігати таблицю ідентифікаторів (наприклад, список), яка включає в себе конкретний для кластера ідентифікатор та ідентифікатор мережі для кожного ретранслятора в кластері. Посилаючись на приклад, описаний вище в зв'язку з фіг.2, таблиця може включати в себе перетворення ідентифікаторів 1, 2, 3, 4 та 5 до ідентифікаторів мережі (наприклад, ANID) RS1, RS2, RS3, RS4 та RS5, відповідно. На фіг.3, ці операції можуть виконуватися за допомогою модуля 344 задавання списків. Як представлено за допомогою етапу 412, коренева точка доступу може відправляти цю інформацію нових ідентифікаторів в усі ретранслятори кластера. Таким чином, всім ретрансляторам кластера може повідомлятися конкретний для кластера ідентифікатор та ідентифікатор мережі нового ретранслятора в кластері. У деяких реалізаціях коренева точка доступу може відправляти всю таблицю ідентифікаторів (наприклад, список) в ретранслятори кластера кожний раз, коли змінюється таблиця ідентифікаторів. Альтернативно, в деяких реалізаціях коренева точка доступу може просто вказувати всі зміни таблиці ідентифікаторів. Наприклад, коренева точка доступу може відправляти повідомлення, яке містить ідентифікаційні дані всіх нових ідентифікаторів, які додані в таблицю, або всіх ідентифікаторів, які видалені з таблиці з моменту, коли остання інформація таблиці ідентифікаторів відправлена. Тут, коренева точка доступу може використовувати схему синхронізації (наприклад, за допомогою включення порядкового номера в повідомлення), щоб забезпечувати, що ретранслятори можуть визначати те, мають вони чи ні актуальну таблицю ідентифікаторів. У прикладі за фіг.3, модуль 344 задавання списків може взаємодіяти з контролером 326 зв'язку і передавальним пристроєм 312, щоб передавати вищезгадану інформацію. У деяких реалізаціях (наприклад, основаній на UMB реалізації), коренева точка доступу може відправляти (залежно від політики) повідомлення IDTable, що включає в себе інформацію таблиці ідентифікаторів, в усі ретранслятори в кластері, коли ретранслятору, що відкриває новий маршрут в кластері, призначається конкретний для кластера ідентифікатор, або коли ретранслятор закриває маршрут в кластері. У деяких випадках, ретранслятор може відправляти IDTableRequest після прийому повідомлення IDAssign. У цьому випадку, коренева точка доступу може відправляти повідомлення IDTable у відповідь на запит від ретранслятора. Посилаючись тепер на фіг.4B, ретранслятори приймають інформацію списку ідентифікаторів, як представлено за допомогою етапу 414. У прикладі за фіг.3, контролер 346 списків може взаємодіяти з приймальним пристроєм 318, щоб приймати інформацію списку, після чого контролер 346 списків обробляє інформацію. У деяких випадках (наприклад, основаній на LTE реалізації), кожний ретранслятор, який приймає список, може перенаправляти список в інший ретранслятор. Наприклад, при прийомі списку ідентифікатора, ретранслятор 104 (наприклад, контролер 346 списків ретранслятора) може перенаправляти список в ретранслятор 108. Ретранслятор 108, в свою чергу, може перенаправляти список в ретранслятори 110 та 112. 8 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 У деяких випадках (наприклад, основаній на UMB реалізації), після прийому повідомлення IDTable, ретранслятор може виконувати нижченаведені операції. По-перше, ретранслятор може перевіряти достовірність повідомлення. Тут, ретранслятор може відкидати повідомлення, якщо повідомлення є недопустимим. Потім, ретранслятор може визначати те, включає чи ні поле MessageSequence повідомлення в себе наступну очікувану послідовність повідомлень для повідомлення IDTable. Якщо ні, ретранслятор може відкидати повідомлення і відправляти повідомлення IDTableRequest з полем MessageSequence, рівним останньому MessageSequence, що приймається для повідомлення IDTable, яке оброблене успішно. Інакше, ретранслятор може оновлювати свою таблицю взаємозв'язку ідентифікаторів та ANID на основі вмісту повідомлення IDTable. Тут, ретранслятор може додавати всі ретранслятори, перелічені в повідомленні IDTable, для яких поле IsNewEntry вказує, що це новий запис (наприклад, поле задане рівним 1). Ретранслятор може видаляти всі ретрансляційні станції, перелічені в IDTable, для яких поле IsNewEntry вказує, що цей запис повинен видалятися (наприклад, поле задане рівним 0). Ретранслятор потім може відправляти повідомлення підтвердження прийому IDTableAck в кореневу точку доступу. Як представлено за допомогою етапу 416, коренева точка доступу також може задавати нову таблицю маршрутизації у відповідь на зміну в топології кластера (наприклад, приєднання нового ретранслятора до кластера). У прикладі за фіг.3, таблиця маршрутизації може зберігатися за допомогою модуля 348 задавання таблиць маршрутизації. Як представлено за допомогою етапу 418, коренева точка доступу відправляє інформацію нової таблиці маршрутизації в усі ретранслятори кластера. Таким чином, всім ретрансляторам кластера може повідомлятися нова топологія кластера. У деяких реалізаціях коренева точка доступу може відправляти всю таблицю маршрутизації в ретранслятори кластера кожний раз, коли таблиця маршрутизації змінюється. Альтернативно, в деяких реалізаціях коренева точка доступу може просто вказувати всі зміни таблиці маршрутизації. Наприклад, коренева точка доступу може відправляти повідомлення, яке містить записи таблиці маршрутизації всіх нових ідентифікаторів, які додані, або індикатор відносно всіх записів таблиці маршрутизації, які видалені з моменту, коли остання інформація таблиці маршрутизації відправлена. З іншого боку, коренева точка доступу може використовувати схему синхронізації (наприклад, за допомогою включення порядкового номера в повідомлення), щоб гарантувати, що ретранслятори можуть визначати те, мають вони чи ні актуальну таблицю маршрутизації. У прикладі за фіг.3, модуль 348 задавання таблиць маршрутизації може взаємодіяти з контролером 326 зв'язку і передавальним пристроєм 312, щоб передавати вищезгадану інформацію. У деяких випадках (наприклад, основаній на UMB реалізації), коренева точка доступу відправляє повідомлення ClusterTopology, яке включає в себе інформацію таблиці маршрутизації, в усі ретранслятори в асоційованому обслуговуючому кластері. Коренева точка доступу може відправляти це повідомлення, коли ретранслятор або коренева точка доступу стають FLSE для ретранслятора або більше не є FLSE для ретранслятора. Таким чином, повідомлення може відправлятися, коли таблиці перенаправлення в кластері змінюються. Обслуговуючий кластер може бути заданий як кластер, для якого є тракт від кореневої точки доступу до ретранслятора, для якого обслуговуюча точка доступу кожного ретранслятора в тракті є членом кластера. Кожна ретрансляційна станція в обслуговуючому кластері може мати точно один запис в таблиці ClusterTopology, навіть якщо вона має відкриті маршрути до декількох членів кластера. Ретранслятор, який має запис в IDTable, але не має в таблиці ClusterTopology, не знаходиться в обслуговуючому кластері. У деяких випадках, ретранслятор може відправляти запит на інформацію таблиці маршрутизації. Наприклад, якщо коренева точка доступу знаходиться в обслуговуючому кластері, ретранслятор може відправляти ClusterTopologyRequest після прийому повідомлення IDAssign. У прикладі за фіг.3, формувач 336 запитів може взаємодіяти з передавальним пристроєм 316, щоб передавати цей запит. Ретранслятори кластера приймають інформацію таблиці маршрутизації, як представлено за допомогою етапу 420. У прикладі за фіг.3, контролер 350 таблиць маршрутизації може взаємодіяти з приймальним пристроєм 318, щоб приймати інформацію таблиці маршрутизації, після чого контролер 350 таблиць маршрутизації обробляє інформацію. У деяких випадках (наприклад, основаній на LTE реалізації), кожний ретранслятор, який приймає інформацію таблиці маршрутизації, може перенаправляти інформацію в інший ретранслятор. Наприклад, після прийому нової таблиці маршрутизації, ретранслятор 104 (наприклад, контролер 350 таблиць маршрутизації ретранслятора) може перенаправляти таблицю маршрутизації в ретранслятор 108. Ретранслятор 108, в свою чергу, може 9 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 перенаправляти таблицю маршрутизації в ретранслятори 110 та 112. У деяких випадках (наприклад, основаній на UMB реалізації), після прийому повідомлення ClusterTopology, ретранслятор може виконувати нижченаведені операції. По-перше, ретранслятор може перевіряти достовірність повідомлення. Тут, ретранслятор може відкидати повідомлення, якщо повідомлення є недопустимим. Потім, ретранслятор може визначати те, включає чи ні поле MessageSequence повідомлення в себе наступну очікувану послідовність повідомлень для повідомлення ClusterTopology. Якщо ні, ретранслятор може відкидати повідомлення і відправляти повідомлення ClusterTopologyRequest з полем MessageSequence, рівним останньому MessageSequence, що приймається для повідомлення ClusterTopology, яке оброблене успішно. Інакше, ретранслятор може оновлювати свою таблицю перенаправлення (пояснена нижче) на основі вмісту повідомлення ClusterTopology. Тут, ретранслятор може додавати всі ретранслятори, перелічені в повідомленні ClusterTopology, для яких поле IsNewEntry вказує, що це новий запис (наприклад, поле задане рівним 1). Ретранслятор може видаляти всі ретранслятори, перелічені в ClusterTopology, для яких поле IsNewEntry вказує, що цей запис повинен видалятися (наприклад, поле задане рівним 0). Ретранслятор також може видаляти з кластера всі ретранслятори нижче видаленого ретранслятора. Ретранслятор потім може відправляти повідомлення підтвердження прийому ClusterTopologyAck в кореневу точку доступу. Як представлено за допомогою етапу 422, кожний ретранслятор кластера задає таблицю перенаправлення на основі інформації таблиці маршрутизації, що приймається. Таблиця перенаправлення може приймати форму таблиці 2 або 3, поясненої вище, або деяку іншу підходящу форму. У прикладі за фіг.3, таблиця перенаправлення може бути задана за допомогою модуля 352 задавання таблиць перенаправлення. Як представлено за допомогою етапу 424, вузли кластера можуть виконувати операції, аналогічні описаним вище, щоб зберігати (наприклад, оновлювати) ідентифікатори і таблиці кожний раз, коли є зміна в топології кластера. Наприклад, таблиця ідентифікаторів, таблиця маршрутизації і таблиці перенаправлення можуть модифікуватися кожний раз, коли ретранслятор виходить з кластера, приєднується до кластера або переміщається в рамках кластера. У деяких реалізаціях, коренева точка доступу може автоматично виявляти зміну в топології кластера, оскільки коренева точка доступу містить маршрут до кожного ретранслятору в кластері (наприклад, на відміну від систем, в яких зміна в топології виявляється локально і повинна проникати аж до кореня). У будь-якому випадку, коренева точка доступу доцільно може відправляти оновлення топології на основі знання зміни в топології. Наприклад, коренева точка доступу може відправляти оновлення тільки в зачеплену частину топології (наприклад, частина ретрансляторів у кластері), і не повідомляти іншій частині топології. Коренева точка доступу може вибирати не відправляти інформацію топології для мережі, яка має два перескоки (один для доступу та один для транзитного з'єднання), або в ретранслятор, який не перенаправляє пакети в низхідному напрямку. Проте, коренева точка доступу як і раніше може відправляти таблицю ідентифікаторів, щоб надавати стиснення (пояснено нижче). Як приклад вищезгаданого, коли коренева точка доступу приймає індикатор RouteClosed (який вказує, що маршрут до ретранслятора закритий), коренева точка доступу може відправляти оновлене повідомлення ClusterTopology в усі ретранслятори в кластері, що залишилися. Крім цього, після прийому індикатора RouteClosed, ретранслятор може видаляти ідентифікатор і таблиці перенаправлення для кластера. Коли ретранслятор виходить з кластера, конкретний для кластера ідентифікатор для ретранслятора не може бути повторно використаний протягом заданого періоду часу. Наприклад, ідентифікатор не може бути повторно використаний протягом визначеного періоду часу після того, як маршрут до ретранслятора закривається, так що всі пакети в кластері для цього ретранслятора можуть «очищатися» з кластера. Посилаючись тепер на фіг.5A та 5B, описуються зразкові операції, які можуть виконуватися за допомогою вузлів кластера, щоб маршрутизувати пакети в рамках кластера. У цьому прикладі, допускається, що пакет, який передається через кластер, стискується після входу в кластер або коли він сформований за допомогою вузла кластера. Потрібно брати до уваги, однак, те, що ідеї в даному документі можуть бути застосовними до реалізацій, в яких пакети маршрутизируються через кластер без стиснення. Як представлено за допомогою етапу 502 за фіг.5A, в деякій точці у часі вузол в кластері приймає або формує пакет, який повинен маршрутизуватися в рамках кластера. Як один приклад, ретранслятор може формувати керуючий пакет, який повинен відправлятися в базову 10 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 мережу (наприклад, через шлюз доступу, як представлено за допомогою мережного вузла 116 на фіг.1). Як інший приклад, ретранслятор (наприклад, ретранслятор 108) може приймати пакет від асоційованого термінала доступу (наприклад, термінала 114 доступу), який повинен відправлятися в інший пристрій через базову мережу. Як ще один інший приклад, коренева точка 102 доступу може приймати пакет від базової мережі, яка призначається для ретранслятора (наприклад, у випадку керуючого пакета) або термінала доступу, який підключається до ретранслятора (наприклад, у випадку пакета даних). У прикладі за фіг.3, пакетний процесор 328 або 334 може формувати цей пакет або взаємодіяти з асоційованим приймальним пристроєм 314 або 318, щоб приймати пакет. Як представлено за допомогою етапу 504, вузол стискає пакет до маршрутизації пакета через кластер. Наприклад, вузли кластера можуть реалізовувати протокол стиснення, який стискає заголовки пакетів, які повинні маршрутизуватися в рамках кластера. Як конкретний приклад, протокол стиснення може стискати UDP/IP-заголовок або L2TPv3/IP-заголовок пакета мережної операційної системи (IOS). Тут, протокол стиснення може підтримувати стисненнянаступних IOS-інтерфейсів: інтерфейс обміну службовими сигналами між ANRI (IAS), який переносить службову інформацію сеансів/пошукових викликів між ANRI для термінала доступу; інтерфейс IP-тунелювання (IPT), який переносить службові повідомлення, щоб повідомляти і перенаправляти тунельований трафік на основі мобільності термінала доступу та інкапсулює тунельовані IP-пакети, які повинні бути передані між мережами доступу для термінала доступу; інтерфейс тунелювання канального рівня (LLT), який переносить тунелювання пакетів канального рівня в обслуговуючу мережу доступу прямої лінії зв'язку і від обслуговуючої мережі доступу зворотної лінії зв'язку. Протокол стиснення може стискати UDP- та IP-заголовки інтерфейсів передачі службових сигналів IAS та IPT. Протокол стиснення може стискати L2TPv3- та IP-заголовки інтерфейсів даних LLT та IPT. У деяких аспектах, стиснення може спрощувати маршрутизацію через декілька перескоків (наприклад, IP-адреса або маршрутна адреса може зчитуватися із стиснутого заголовка без розпаковування пакета). У деяких реалізаціях, стиснення між ретранслятором та іншим ретранслятором або точкою доступу надається за допомогою відкриття маршруту до цього ретранслятору або точки доступу. У прикладі за фіг.3, пакетні процесори 328 та 334 можуть реалізовувати протокол стиснення. Як представлено за допомогою етапу 506, протокол стиснення може додавати заголовок до пакета, при цьому заголовок може включати в себе конкретні для кластера ідентифікатори, щоб вказувати вузол кластера (наприклад, ретранслятор), який є джерелом пакета, і вузол кластера (наприклад, ретранслятор), який є призначенням пакета. Наприклад, заголовок пакета, що приймається, може включати в себе вихідну адресу і/або цільову адресу, яка відповідає ідентифікатору мережі (наприклад, ANID) вузла в кластері, як вказано за допомогою списку ідентифікаторів (описаного вище). Таким чином, протокол стиснення може використовувати ідентифікатор мережі і список ідентифікаторів, щоб визначати те, який конкретний для кластера ідентифікатор(и) повинен використовуватися в доданому заголовку, щоб маршрутизувати пакет в рамках кластера. Як представлено за допомогою етапу 508, вузол перенаправляє пакет в ретранслятор в кластері. Як пояснено вище, протокол керування ретрансляцією, реалізований за допомогою вузла, може використовувати таблицю перенаправлення для того, щоб ідентифікувати ретранслятор, в який повинен перенаправлятися пакет. Наприклад, якщо пакет виходить в ретрансляторі 104 на фіг.1 і призначається для ретранслятора 110, вузол 104 може перенаправляти пакет в ретранслятор 108. У прикладі за фіг.3, пакетний процесор 328 або 334 може визначати відповідне призначення для пакета і взаємодіяти з асоційованим передавальним пристроєм 312 або 316, щоб передавати пакет. Ретранслятор в кластері потім приймає пакет, як представлене за допомогою етапу 510. З іншого боку, на фіг.3 пакетний процесор 328 або 334 може взаємодіяти з асоційованим приймальним пристроєм 314 або 318, щоб приймати пакет. Як представлено за допомогою етапу 512 за фіг.5B, коли вузол приймає пакет (наприклад, через протокол роботи лінії радіозв'язку), протокол керування ретрансляцією може спочатку визначати те, включає чи ні пакет в себе інформацію маршрутизації. Якщо ні (наприклад, поле IPHeaderIncluded доданого заголовка задане рівним 0), це вказує, що поточний вузол є призначенням для пакета. У цьому випадку, протокол керування ретрансляцією може відправляти пакет в протокол стиснення (наприклад, реалізований щонайменше частково, за допомогою пакетного процесора), за допомогою якого пакет розпаковується (етап 514). Пакет потім може перенаправлятися в протокол верхнього рівня (наприклад, в кінцевому призначенні). Наприклад, у випадку якщо пакет призначається для ретранслятора, на етапі 516, пакетний процесор 334 може обробляти пакет і надавати пакетну інформацію у відповідний додаток, що 11 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 виконується у вузлі (наприклад, в контролері 332 зв'язку). Альтернативно, у випадку якщо пакет призначається для термінала доступу, який асоційований з ретранслятором, на етапі 516, ретранслятор може перенаправляти пакет в термінал доступу. У прикладі за фіг.3, це може містити в собі формування за допомогою процесора 332 зв'язку відповідного повідомлення і взаємодію з передавальним пристроєм 320, щоб відправляти пакет по радіоінтерфейсу в термінал доступу. Якщо пакет дійсно включає в себе інформацію маршрутизації на етапі 512 (наприклад, поле IPHeaderIncluded доданого заголовка задане рівним 1), протокол керування ретрансляцією може визначати те, вказує чи ні інформація маршрутизації, що поточний вузол є призначенням для пакета (етап 518). Це може містити в собі, наприклад, порівняння конкретного для кластера ідентифікатора вузла (наприклад, що зберігається в списку ідентифікаторів) з ідентифікатором призначення в доданому заголовку пакета. Якщо поточний вузол є призначенням для пакета, послідовність операцій переходить до етапів 514 та 516. Таким чином, пакет може перенаправлятися в протокол стиснення, так що пакет може розпаковуватися і потім надаватися у вузол, асоційований термінал доступу або деяку іншу позначену кінцеву точку. Якщо інформація маршрутизації вказує на етапі 518, що цей вузол не є призначенням для пакета (наприклад, протокол керування ретрансляцією приймає стиснутий пакет, який повинен перенаправлятися), протокол керування ретрансляцією визначає наступну лінію зв'язку для пакета (етап 520). Тут, пакетний процесор 334 може використовувати ідентифікатор призначення з доданого заголовка пакета, а також таблицю перенаправлення вузла, щоб визначати вузол, в який повинен маршрутизуватися пакет. Як представлено за допомогою етапу 522, протокол керування ретрансляцією визначає те, є чи ні наступна лінія зв'язку ідентичною вихідній лінії зв'язку (тобто лінії зв'язку, з якої пакет прийнятий). Цей випадок може виникати, наприклад, коли низхідний ретранслятор видалений з кластера. У цьому випадку, запис для ретранслятора видаляється з таблиці перенаправлення поточного вузла. Крім цього, таблиця перенаправлення для вузла може вказувати висхідну лінію зв'язку як наступну лінію зв'язку для всіх ідентифікаторів, які не знаходяться в таблиці перенаправлення (наприклад, як показано в таблицях 2 та 3). Якщо наступна лінія зв'язку не є ідентичною вихідній лінії зв'язку на етапі 522, протокол керування ретрансляцією перенаправляє пакет у вузол, вказаний в таблиці перенаправлення (етап 526). Таким чином, протокол керування ретрансляцією може перенаправляти пакет в екземпляр протоколу керування ретрансляцією на наступній лінії зв'язку. Якщо, з іншого боку, наступна лінія зв'язку є ідентичною вихідній лінії зв'язку на етапі 522, протокол керування ретрансляцією може відправляти пакет назад у вихідну лінію зв'язку (етап 524). Наприклад, якщо ретранслятор має маршрут до ретранслятора, що відповідає ідентифікатору призначення в доданому заголовку, ретранслятор може перенаправляти пакет у відповідний протокол (наприклад, IRTP-протокол) для цього маршруту. Інакше, протокол керування ретрансляцією може відкидати пакет на етапі 524. Ідеї в даному документі можуть реалізовуватися різними способами в різних реалізаціях. Наприклад, можуть використовуватися різні типи ідентифікаторів, можуть використовуватися різні технології для того, щоб розподіляти ідентифікатори по кластеру, і можуть використовуватися різні технології для того, щоб маршрутизувати трафік через кластер на основі цих ідентифікаторів. У деяких реалізаціях IP-адреси використовуються як комутаційні теги (наприклад, комутаційним теги рівня 2), щоб маршрутизувати пакети в ретрансляційному кластері. Тут, кожному ретранслятору може бути призначена унікальна IP-адреса. Кожний з ретрансляторів потім може бути виконаний з можливістю розпізнавати IP-адреси всіх своїх низхідних ретрансляторів (наприклад, всіх ретрансляторів нижче нього). Як результат, ретранслятор може комутувати пакети напряму. У кластері з декількома ретрансляційними вузлами, коренева точка доступу може вибирати перенаправляти пакети, маршрутизувати пакети маршруту або не здійснювати нічого з цього. Приклади цих сценаріїв наводиться нижче. Спочатку описуються операції, що стосуються невикористання маршрутизації або перенаправлення. Потім описуються операції, що стосуються використання перенаправлення рівня 2. Далі описуються операції, що стосуються використання статичного перенаправлення рівня 3. На завершення описуються операції, що стосуються використання маршрутизації рівня 3. У реалізації, в якій коренева точка доступу вибирає не маршрутизувати або перенаправляти, може використовуватися наступна послідовність виявлення адрес. Коли ретранслятор активується, ретранслятор може відправляти широкомовне DHCP-повідомлення. 12 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 Коренева точка доступу вміщує його в L2TP-тунель і перенаправляє його в шлюз доступу. Обернені пакети входять в L2TP-тунель, що передається по радіоінтерфейсу за допомогою кореневої точки доступу. Наступні операції виділення адрес також можуть використовуватися. Адреси виділяються за допомогою шлюзу доступу або DHCP-сервера за шлюзом доступу. Тут, шлюз доступу є маршрутизатором першого перескоку. Ретранслятор може тунелювати пакети для «ретрансляторів-у-ланцюжку» в кластері. Наприклад, з посиланням на фіг.1, ретранслятор 108 може вміщувати пакети з термінала 114 доступу в GRE-тунель. Аналогічно, ретранслятор 104 може вміщувати пакети з ретранслятора 108 в GRE-тунель. Пакет, що досягає кореневої точки 102 доступу, таким чином, має два GREзаголовки. Перевага цієї схеми полягає в тому, що вона дає можливість кожному ретранслятору трактувати всі низхідні елементи як термінали доступу. Недолік цієї схеми полягає в тому, що додаткові GRE-заголовки додаються при кожному перескоку. На відміну від вищеописаної схеми, коренева точка доступу може перенаправляти або маршрутизувати пакети в ретранслятор. Коли пакети маршрутизуються в кореневу точку доступу, коренева точка доступу може мати власну підмережу. Тут, коренева точка доступу може виступати як шлюз за умовчанням для всіх ретрансляторів у рамках своєї підмережі. Адреси для ретрансляторів можуть виділятися з підмережі. DHCP-сервер може розташовуватися в іншому місці. Коренева точка доступу може виконувати протокол маршрутизації із шлюзом доступу та іншою точкою доступу (наприклад, іншою кореневою точкою доступу, не показаною на фіг.1, підключеною до мережного вузла 116). Цей протокол маршрутизації виконаний по транзитному з'єднанню. Перевага такого сценарію полягає в тому, що пакети можуть маршрутизуватися напряму без тунелів. Цей сценарій потенційно може бути переважним, коли лінія зв'язку існує між кореневими точками доступу. Потенційний недолік цієї схеми полягає в тому, що стек маршрутизації, можливо, повинен реалізовуватися в кореневій точці доступу. Коли пакет перенаправляється нижче кореневої точки доступу, пакет, що надходить в ретранслятор 104, може мати IP-адресу ретранслятора 108. Такий пакет може вийти із шлюзу доступу (наприклад, мережного вузла 116) або кореневої точки 102 доступу. Ретранслятор 104 повинен бачити IP-пакет (наприклад, після детунелювання), і ретранслятор 104 повинен відправляти пакет в ретранслятор 108. Три схеми надання можливості ретранслятору 104 визначати те, де маршрутизувати пакет, далі описуються по черзі. Як згадано вище, перша схема містить в собі перенаправлення рівня 2 (L2), друга схема містить в собі статичне перенаправлення рівня 3 (L3), і третя схема містить в собі маршрутизацію рівня 3 (L3). У перенаправленні L2 кожний вузол ретрансляційного кластера в рамках кореневої точки доступу може бути частиною однієї підмережі. Тут, кожний вузол розпізнає MAC-адресу кожного вузла нижче нього в дереві (кожному вузлу призначається власний унікальний MACідентифікатор). MAC-адреси можуть бути розпізнані, наприклад, за допомогою стандартного протоколу міжмережного перетворення даних L2 (наприклад, протокол L2, такий як STP, може бути виконаний). Реалізація STP може бути відносно прямою, оскільки кластер має деревоподібну топологію. Таблиці перенаправлення L2 можуть бути використані в цій схемі (наприклад, реалізованій відповідно до ідей в даному документі). Для DHCP-тракту в цій схемі DHCP-запит може бути переданий по всіх лініях зв'язку в кластері і повинен, зрештою, досягати кореневої точки доступу. Коренева точка доступу перенаправляє запит в DHCP-сервер (в або через шлюз доступу). DHCP-відповідь (що включає в себе нову IP-адреса для вузла) повертається в підмережу і передається в широкомовному режимі по L2 доти, доки він не досягає цільового ретранслятора. Таким чином, ця схема може використовувати механізм міжканальної широкомовної передачі. У деяких реалізаціях альтернативне транспортування для пакетів між ретрансляторами і між ретранслятором і кореневою точкою доступу може використовуватися. Наприклад, протокол стільникової маршрутизації WiFi може використовуватися в деяких випадках. Чотири ідентифікатори можуть використовуватися в цих випадках: ідентифікатор джерела, ідентифікатор призначення, проміжний ідентифікатор джерела і проміжний ідентифікатор призначення. Проміжний заголовок може змінюватися при кожному перескоку. У перенаправленні L3 кожний вузол ретрансляційного кластера в рамках кореневої точки доступу може бути частиною однієї підмережі. Ці IP-адреси призначаються по декількох перескоках. У цьому випадку, кожний вузол розпізнає IP-адресу кожного вузла нижче нього в дереві. Як описано вище, ця схема використовує механізм міжканальної широкомовної передачі. Крім цього, ця схемаможе по суті виконувати протокол L2 із застосуванням IP-адрес. Для DHCP-тракту в цій схемі, з посиланням на фіг.1, DHCP-запит від ретранслятора 108 13 UA 100546 C2 5 10 15 20 25 30 35 40 45 50 55 60 ретранслюється за допомогою ретранслятора 104 (агента DHCP-ретранслятора) в маршрутизатор за умовчанням (кореневу точку 102 доступу). Коренева точка доступу перенаправляє запит в шлюз доступу. Тут, шлюз доступу потенційно перенаправляє запит в DHCP-сервер. DHCP-відповідь, що включає в себе призначену IP-адресу, повертається в поточну підмережу (яку може мати шлюз доступу або коренева точка 102 доступу). Ця схема є аналогічною наявності DHCP-сервера в інший підмережі. Тут, пакет DHCP-відповіді може відправлятися через широкомовну передачу в ретранслятор 108. Таким чином, ця схема може включати в себе механізм широкомовної передачі. IP-пакет, який досягає кореневої точки 102 доступу, перенаправляється в цільовий ретранслятор. Тут, наступні ознаки вузлів можуть використовуватися. Кожний вузол знає всі IPадреси під собою. Наприклад, аналогічним чином, як пояснено вище для конкретних для кластера ідентифікаторів, таблиця IP-адрес може зберігатися і розподілятися в усі вузли в кластері. Крім того, кожний вузол може розпізнавати таблицю перенаправлення. У деяких аспектах, ця схема по суті використовує механізм перенаправлення L2 із застосуванням IPадрес. Також можуть робитися заходи для того, щоб запобігати контурам в таблицях. У маршрутизації L3 каскадні підмережі можуть надаватися для кожного ретранслятора. Іншими словами, кожний ретранслятор має підмережу. IP-адреса для кожного нового ретранслятора може виділятися з підмережі вище. Таким чином, дочірні ретранслятори можуть одержувати адреси і/або підмережі з підмережі батьківського вузла. Ця схема тим самим містить в собі найдовший збіг префіксів. IP-маршрути повинні бути розпізнані. Кожний ретранслятор реалізовує стандартний стек IP-маршрутизації. Пакети перенаправляються на основі IP-маршрутизації. Система бездротового зв’язку з множинним доступом може одночасно підтримувати зв'язок для декількох бездротових терміналів доступу. Кожний термінал може обмінюватися даними з однією або більше точками доступу за допомогою передачі по прямій і зворотній лінії зв'язку. Пряма лінія зв'язку (або низхідна лінія зв'язку) відноситься до лінії зв'язку від точок доступу до терміналів, а зворотна лінія зв'язку (або висхідна лінія зв'язку) відноситься до лінії зв'язку від терміналів до точок доступу. Ця лінія зв'язку може встановлюватися через систему з одним входом та одним виходом, систему з багатьма входами і багатьма виходами (MIMO) або деякий інший тип системи. MIMO-система використовує декілька (NT) передавальних антен і декілька (NR) приймальних антен для передачі даних. MIMO-канал, сформований за допомогою NT передавальних і NR приймальних антен, може бути розкладений на NS незалежних каналів, які також згадуються як просторові канали, де NS