Спосіб підтвердження прийому блоків даних

1. Спосіб підтвердження прийому блоків даних, який включає прийом блоків даних, переданих по радіоканалу; генерування блока підтвердження для отриманих блоків даних, причому блок підтвердження містить поле індикатора підтвердження; вибір будь-якого використовуваного наявного радіоканалу для відсилання підтвердження; задавання індикатора підтвердження для указування, чи належить це підтвердження до отримуваних блоків даних, переданих по тому ж радіоканалу, C2 2 (19) 1 3 76995 4 прийшло підтвердження; і передавання підтвернали SACCH, SDCCH і FACCH підтримують як дження по наявному радіоканалу. сервіс підтвердження, так і непідтвердження. Ці В даному винаході проблема неефективного логічні канали можуть підтримувати 4 або навіть 8 використання ресурсів вирішується за рахунок радіочастотних несучих, причому кожна радіочастого, що підтвердження посилається по будьтотна несуча ідентифікується відповідним ідентиякому наявному радіоканалу, який використовуфікатором. У цьому інтерфейсі працює протокол ється, наприклад, для передачі даних, та за рахууправління лінією зв'язку/управління доступом до нок встановлення індикатора, який показує, віднолінії зв'язку (RLC/MAC). Формати заголовків блоків ситься це підтвердження до згаданого RLC/MAC для даних і управлінської інформації радіоканалу, чи ні. Підтвердження, переважно, має вже були запропоновані. В цій пропозиції підтверформу бітового масиву. дження для певної радіочастотної несучої, яка Поле індикатора підтвердження встановлюпрацює в режимі з підтвердженням, передаються в ється, переважно, на значення '01', аби показати, зворотному напрямі вкладеними разом з даними в що ідентифікатор радіоканалу включений до опису блоки даних для тієї ж радіочастотної несучої. Якпідтвердження/непідтвердження для ідентифікації що дані, призначені для пересилання, відсутні, то того, якому з радіоканалів призначений цей опис підтвердження може бути посланим з пустим блопідтвердження/непідтвердження. ком даних. Однак, це є надлишковим витрачанням Індикатор підтвердження встановлюється, пересурсів, а задача даного винаходу полягає в тореважно, на значення '10', аби показати, що радіому, щоб покращити використання ресурсів на тій канал, по якому здійснюється прийом, і радіоканал основі, що підтвердження для однієї радіочастотдля підтвердження є одним і тим же. ної несучої можуть бути передані в зворотному Радіоканал, переважно, містить радіочастотну напрямі шляхом їх вкладання в блок даних для несучу GERAN. Наявний радіоканал використовуіншої радіочастотної несучої. Це особливо зручно ється, переважно, для передавання даних. Далі у випадку кількох радіочастотних несучих, оскільки буде описано приклад способу підтвердження це зменшує вірогідність того, що підтвердження прийому даних, відповідно до даного винаходу, з буде послане з пустим блоком даних. Подальша посиланням на додані ілюстрації, де: оптимізація полягає в тому, що в одному блоці на Фіг.1 показано спосіб згідно з даним винаданих можуть бути розміщені підтвердження для ходом, в якому радіочастотні несучі для даних і кількох радіочастотних несучих. для підтвердження мають один і той же ідентифіАльтернативою є передавання підтвердження катор; для одної радіочастотної несучої шляхом його на Фіг.2 показано спосіб згідно з даним винавкладання в блок даних зворотного напряму для ходом для кількох радіочастотних несучих; і радіочастотної несучої, яка працює в режимі без на Фіг.3 показано спосіб згідно з даним винапідтвердження. В цьому випадку необхідно, щоб ходом, в якому для кількох несучих радіочастотні отримувач підтвердження повідомив, що він отринесучі для даних і для підтвердження мають однамав це підтвердження. кові ідентифікатори. Підтвердження можуть або бути передані Даний винахід здатний покращити ефективвкладеними в блоки даних зворотного напряму, ність використання ресурсів, наявних в системах або бути переслані в блоках, які не містять даних, мобільного зв'язку. Хоча спосіб може працювати і якщо відсутні дані, призначені для сигнальної рав системах проводового зв'язку, тут відсутні такі ж діочастотної несучої (SRB) в напрямі передавання стимули для його застосування. Таким чином, в підтвердження. У випадку кількох потоків тимчасосистемах зв'язку, де використовується-кілька логівих блоків (TBFs) може скластися ситуація, коли чних каналів і де деякі з цих логічних каналів підтдля SRB необхідно надіслати підтвердження, а римують передавання підтверджень, ефективність дані, призначені для цієї SRB в напрямі підтверможна покращити за рахунок передавання підтведження, відсутні, але є дані, призначені для іншої рдження для одного логічного каналу, вклавши SRB в напрямі передавання підтвердження. В його в блок даних іншого логічного каналу, що пецьому випадку вигідно, коли підтвердження для редається у зворотному напрямі. Один з приклаSRB X надсилається з даними для SRB Y. дів, де це може бути використано, є описана нижДля того, щоб показати, чи підтвердження сточе система Geran. В мережі радіодоступу до сується іншої SRB, ніж та SRB, для котрої признаGSM/EDGE (Geran) між мобільною станцією та чено цей блок даних, додається визначення поля мережею існують виділені фізичні підканали індикатора підтвердження (АІ), як це показано в (DPSCH), прокладені через повітряний простір. Таблиці 1. Коли поле АІ показує, що підтвердженПідтвердження блоків радіоданих на повільному ня стосуються SRB, іншої, ніж та SRB, для котрої приєднаному каналі управління (SACCH), автонопризначені дані, то формат бітового масиву підтмному виділеному каналі управління (SDCCH) і вердження має вигляд, показаний нижче в Таблиці швидкодіючому приєднаному каналі управління 2. (FACCH) відображується на DPSCH. Однак на Ця пропозиція вносить додаткові складнощі в логічних каналах SACCH, SDCCH і FACCH при їх RLC, і одна з таких внесених проблем стосується відображенні на DPSCH пропускна здатність допересилання підтвердження разом з даними для волі обмежена. Наприклад, SACCH з'являється радіочастотної несучої, яка працює в режимі без лише в 13-му і 26-му фреймах багатофреймової підтвердження. Якщо підтвердження посилаються структури DPSCH. А тому важливо, щоб викорисна радіочастотних несучих, що працюють без підттання цих каналів було оптимізоване. вердження, то вони можуть бути втрачені і їх не Для кількох радіочастотних несучих логічні каможна буде ретранслювати. Це може примусити 5 76995 6 створити вікно, і в такому разі відправник матиме Якщо блок даних підлягає пересиланню, то незванеобхідність періодично проводити опитування в жаючи на те, що повинен бути посланим останній пошуках відповіді. Альтернативно отримувач міг бітовий масив, повинні бути посланими і підтверби послати у зворотному напрямі підтвердження, дження для радіочастотної несучої, яка була підтаби показати, що він отримав бітовий масив підтверджена в першій передачі, щоб уникнути можвердження/непідтвердження на радіочастотній ливих проблем із впорядкуванням при прийомі. несучій без підтвердження. Це передбачає переДля того, щоб відправник бітового масиву підтверсилання індикатора радіочастотної несучої і стардження/непідтвердження знав, коли він може актового номера посланого бітового масиву підтвертивізувати своє вікно, необхідно зберігати копії дження/непідтвердження. бітових масивів для кожної з несучих, на яких цей Інша складність виникає з ретрансляціями. бітовий масив послано. Таблиця 1 Індикатор підтвердження 0 0 0 1 1 0 1 1 АІ: Індикатор підтвердження Опис підтвердження/е підтвердження не врахований Зарезервований Опис підтвердження/е підтвердження врахований різні TFI Опис підтвердження/е підтвердження врахований Опис підтвердження/е підтвердження не врахований. Відсутній запит на ретрансляцію (всі блоки FINAL_ACK_INDICATION==1) RLC отримані, подібно до Примітка: АІ займає тут два біти, щоб уникнути одного додаткового біта в описі підтвердження/непідтвердження. Це перешкоджає марному витрачанню 7 бітів даних RLC, припускаючи, що дані вирівняні по границі байта (як в GPRS) Таблиця 2 Опис підтвердження/не підтвердження Опис підтвердження/непідтвердження ::= {0|1} STARTING_SEQUENCE_NUMBER: Див. 44.060 (Опис підтвердження/непідтвердження). RECEIVED_BLOCK_BITMAP: Див. 44.060 (Опис підтвердження/непідтвердження). На Фіг.1-3 показані приклади конкретних форматів бітових масивів підтвердження для трьох варіантів. На Фіг.1 бітовий масив підтвердження призначений для тієї ж радіочастотної несучої, що і для даних, в той час як на Фіг.2 дані для радіочастотної несучої 1 містять бітові масиви підтвердження для радіочастотних несучих 1 і 2. На кожній з фігур розташування опису підтвердження/непідтвердження визначається задаванням поля 'АІ'. На Фіг.1 показано потік даних на радіочастотній несучій 1 від адміністративної системи (MS) до мережі для послідовностей з номерами від 5 до 10. Всі дані прийняті мережею, за винятком пакета даних з порядковим номером 7. В описі підтвердження/непідтвердження стартовий порядковий номер бітового масиву підтвердження - 5, і бітовий масив показує, що були прийняті послідовності з номерами 5, 6, 8, 9 і 10. На Фіг.2 показано потік даних від MS до мережі на радіочастотних несучих 1, 2 і 3. Підтвердження посилається мережею разом з даними для радіочастотної несучої 3. Підтвердження стосуються даних, отриманих на радіочастотних несучих 2 і 3. Показана установка '01' для поля АІ , а ідентифікатор радіочастотної несучої включений до опису підтвердження/непідтвердження для ідентифікації того, якій з радіочастотних несучих призначений цей опис підтвердження/непідтвердження. Бітові масиви підтвердження/ непідтвердження для радіочастотних несучих 1 і 2 передаються у зворотному напрямі разом з даними для радіочастотної несучої 3. Фіг.3 стосується того ж потоку даних мережі, що і на Фіг.2, хоча на Фіг.2 менше на два повідомлення, якими обмінюються. Однак, формат опису підтвердження/непідтвердження на Фіг.2 складні 7 76995 8 ший, ніж на Фіг.3. Формат потоку даних на Фіг.2 проводового зв'язку, де немає такої потреби робимає переваги, коли є необхідність обмежити кільти ефективним використання ресурсів, цей мехакість обмінів повідомленнями, як у випадку систенізм дасть менше переваг. ми Geran через повітряний простір. Для мережі Комп’ютерна верстка Т. Чепелева Підписне Тираж 26 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601