Спосіб передачі пакетів даних та передавач для передачі пакетів даних

1. Спосіб передачі пакетів даних від передавача, що має радіопротокол з верхнім рівнем та нижнім рівнем, який використовується для керування передачею пакета з повним заголовком до приймача, де у способі: якщо верхній рівень отримує з нижнього рівня інформацію про успішну передачу пакета з повним заголовком, верхній рівень встановлює - зупинити надсилання будь-якого додаткового пакета з повним заголовком, який містить той самий повний заголовок, що і попередній успішно переданий пакет з повним заголовком. 2. Спосіб за п. 1, у якому, якщо нижній рівень працює в підтвердженому режимі (AM), то він отримує інформацію про стан (стан PDU), яку надсилають з приймача, зазначаючи, чи був успішно прийнятий чи ні принаймні один блок протокольний даних, що включає пакет з повним 3. Спосіб за п. 2, у якому верхній рівень отримує заголовком. інформацію з нижнього рівня при доставці параметра, яка вказує, чи є необхідність нижньому рівню поінформувати верхній рівень про успішно переданий пакет. 4. Спосіб за п. 1, у якому інформація з нижнього рівня стосується результату передачі одного або більше пакетів. 5. Спосіб за п. 1, у якому інформація з нижнього рівня стосується результату, що періодично або неперіодично повторюється, передачі пакета з повним заголовком. 2 (19) 1 3 82886 4 дискримінатор успішної передачі, який надає верхньому рівню інформацію про успішну передачу принаймні одного пакета з пакетного потоку; та передачі, який контролює буфер та контролер блок передачі, щоб передавати приймачу пакети з повними заголовками та пакети зі стиснутими заголовками. 13. Передавач за п. 12, у якому дискримінатор успішної передачі отримує інформацію про стан від приймача, яка вказує, чи були успішно чи ні прийняті блоки протокольних даних пакета. 14. Передавач за п. 10, у якому, якщо нижній рівень працює у підтвердженому режимі (AM), то він отримує інформацію про стан (стан PDU), яку надсилають з приймача, зазначаючи, чи був успішно прийнятий чи ні принаймні один блок протокольних даних, що включає пакет з повним 15. Передавач за п. 14, у якому верхній рівень заголовком. отримує інформацію з нижнього рівня при доставці параметра, який вказує, чи необхідно нижньому рівню поінформувати верхній рівень про успішно переданий пакет. 16. Передавач за п. 10, у якому інформація з нижнього рівня стосується результату передачі одного або більше пакетів. 17. Передавач за п. 10, у якому інформація з нижнього рівня стосується результату, що періодично або неперіодично повторюється, передачі пакета з повним заголовком. 18. Передавач за п. 10, у якому з пакетом з повним заголовком також передають контекстний ідентифікатор (CID), щоб забезпечити ідентифікацію кожного пакетного потоку. 19. Передавач за п. 10, у якому верхній рівень є частиною рівня протоколу конвергенції пакетних даних (PDCP), а нижній рівень є частиною рівня керування радіоканалом (RLC). 20. Передавач за п. 10, у якому пакети є частиною потоку протоколу керування передачею в режимі без встановлення з'єднання (не-ТСР). 21. Передавач за п. 20, у якому протокол керування передачею в режимі без встановлення з'єднання (не-ТСР) є протоколом дейтаграм користувача / Інтернет-протоколом (UDP/IP). Наступний винахід загалом відноситься до передачі пакетних даних в комунікаційній системі, докладніше, до системи та способу контролю передачі пакетних даних, що включають інформацію заголовка. Внаслідок розвитку комунікаційних технологій очікується, що бездротові телефонні апарати стануть більш популярними, ніж класичні дротові телефонні апарати. Але дротові апарати, однак, залишаються зручнішими терміналами для деяких галузей застосування. Наприклад, технологія мобільного радіозв'язку ще значно відстає від існуючих дротових систем зв'язку, коли йдеться про передачу великої кількості даних та значний мовний трафік між терміналами. Декілька стандартів бездротового зв'язку були створені для вирішення цієї проблеми. Один зі стандартів має назву ІМТ-2000 та дозволяє передавати між терміналами велику кількість даних, і завдяки цьому запроваджується в багатьох країнах Фактично одним з завдань міжнародного співробітництва в цій галузі є створення єдиного стандарту для цієї технології. Нещодавно ці кооперативні зусилля призвели до створення ініціативи, яка відома як Проект Партнерства Третього Покоління (3GPP). Ініціатива 3GPP була висунута, серед інших цілей, для цілей стандартизації системи ІМТ-2000 третього покоління, базуючись на комплексі зв'язку, прийнятому в Європі. Стандарт, відомий як Універсальна мобільна телекомунікаційна система (УМТС або UMTS), був створений в результаті спільної праці та внеску з боку великої кількості національних, міжнародних та місцевих інститутів зі стандартизації, таких як TTA в Кореї, CWTS в Китаї, Т1 в США, ARIB/ТТС в Японії. УМТС використовує технологію широкосмугового багатостанційного доступу з кодовим розподіленням каналів (WCDMA) в якості мережної техніки радіозв'язку з абонентами, та розвивається для того, щоб включити послугу загального пакетного радіозв'язку (GPRS) на основі мережі з комутацією пакетів та глобальної системи для мобільного зв'язку (GSM), базуючись на мережі з комутацією каналів. УМТС також розвивається в інтересах забезпечення мультимедійних послуг, таких як голос, зображення та дані. Проект 3GPP включає п'ять технічноспецифікаційних груп (TSG), кожна з яких створює, схвалює та керує цим стандартом у відповідних галузях. Група мережного радіозв'язку з абонентами (RAN або TSG-RAN) керує створенням функціональних вимог та стандарту для інтерфейсу між бездротовими терміналами та наземною мережею радіозв'язку з абонентами УМТС (UTRAN). Група базової мережі (TSG-CN) керує розробкою функцій для базової мережі та вимог та стандарту для інтерфейсу, що дозволяє UTRAN мати доступ до комутаційної базової мережі або до базової мережі з комутацією пакетів. Повний заголовок грає критично важливу роль в техніці стискування заголовка відповідної базової мережі з комутацією пакетів. Якщо повний заголовок не передається належним чином, кожний пакет, отриманий після цього, не може бути розгорнутий та не враховується. Для того, щоб вирішити цю проблему, коли використовується не TCP-протокол, наприклад UDP/IP, система такого роду вимагає від сторони, яка передає, передати пакет з повним заголовком, що може бути використаний для багаторазового конструювання контексту для приймальної сторони в межах одного й того ж потоку даних відповідно до визначених норм. В техніці стискування Стиснутого не -TCP (техніка стискування заголовка використана для 5 UDP/IP протоколу) пакет з повним заголовком передається принаймні один раз в кожному періоді, що експоненційно збільшується, який має назву стартового уповільнення стискування (CSS). Відповідно до методу CSS, якщо інформація повного заголовка змінюється або використовується гнучка техніка стискування заголовка, інтервал передачі для одного й того ж заголовка зменшується на початковій стадії та після цього поступово збільшується. Фіг.1 є схемою, яка відображає інтервали передачі для передачі інформації повного заголовка відповідно до методу CSS. Як зазначено, інтервали передачі для пакета повного заголовка збільшуються експоненціально, та кількість стиснутих пакетів заголовків переданих між сусідніми пакетами повних заголовків (тобто в межах кожного інтервалу) збільшується на 1, 2, 4, 8... Інтервал передачі не збільшується нескінченно але підтримується того ж розміру, коли він досягає граничного значення інтервалу передачі, який зазвичай встановлюється на 256. Для додаткової інформації повні заголовки, передані завдяки методу CSS, мають те ж саме значення CID (контекстний ідентифікатор) та номер покоління. Тобто пакет повного заголовка передається в експоненціальному періоді для пакетного потоку з тим же самим CID та номером покоління. Як зазначено раніше, якщо використовується техніка стискування заголовка, розмір заголовка пакета може бути значно зменшений. Особливо, у випадку, коли нормальний пакет передається через радіоінтерфейс, тому що заголовок пакета надто великий, щоб бути проігнорованим, в порівнянні з розміром корисного навантаження (порція даних пакета), заголовок необхідно стиснути. є блок-схемою системи пакетної передачі Фіг.2 такого роду, яка використовує техніку стискування заголовка. Система включає модуль стискування заголовка 10, забезпеченого в рівні PDCP, що стискує заголовок даних, отриманих з верхнього рівня під контролем модуля стискування заголовка 12. Пакет повного заголовка, або пакет стиснутого заголовка, конвертований модулем стискування заголовка 10, передається до рівня RLC через модуль передачі даних 14. Буфер та модуль передачі 16 рівня RLC зберігають пакет повного заголовка або пакет стиснутого заголовка, отриманий з модуля передачі даних 14 PDCP та/або передає його до приймальної сторони. Робота системи буде тепер пояснена. Поперше, у випадку використання Стиснутого TCP як техніки стискування заголовка, передаюча сторона, спочатку, передає пакет повного заголовка для пакетного потоку, щоб сконструювати контекст на приймальній стороні. Один або більше стиснутих заголовків потім передаються вказуючи на різниці між успішними пакетами. пакет повного заголовка не передається Якщо успішно зі сторони, що передає, тому що контекст не сконструйований належним чином приймальною стороні, приймальна сторона не може відновити послідовно прийняті стиснуті заголовки. Додатково, навіть у випадку де пакет стиснутого заголовка успішно передається, 82886 6 внаслідок не належно модернізованого контексту приймальної сторони, наступні стиснуті заголовки не можуть бути відновленими, яку випадку, де пакет повного заголовка втрачений. Внаслідок того, що ушкоджений контекст може бути відновлений тільки завдяки отриманню нового повного заголовка відповідного контексту, приймальна сторона передає пакет стану контексту (context-state packet), що вимагає передачі нового повного заголовка відповідного контексту від передавальної сторони. Фіг.3 відображає структуру пакета стану контексту такого роду. Цей пакет включає велику кількість полів CID, кожне з яких визначає один ушкоджений контекст, тобто один ушкоджений пакетний потік. Такий пакет стану контексту не використовується, коли тільки один контекст є ушкодженим, але передається до передавальної сторони, коли більше ушкоджується попередньо визначена кількість контекстів. Додатково, передача самого пакета стану контексту з приймальної сторони до передавальної сторони неефективно витрачає радіоресурси, тому частота його використання обмежена в RFC 2507. В передачі пакетних даних, що використовує техніку стискування заголовка "Стиснутий TCP", якщо пакет повного заголовка або пакет стиснутого заголовка втрачається, це займає велику кількість часу щоб відновити відповідний контекст приймальною стороною. Більш того, передаюча сторона не знає що відповідний контекст був ушкоджений. Таким чином, наступні пакети стиснутих заголовків передаються безцільно, що призводить до даремного витрачання радіоресурсів. структуру Фіг.4 відображає стиснутого заголовка використаного в протоколі UDP/IP. Як було обговорено раніше, у виконання стискування заголовка UDP/IP, обсяг покоління відповідної заголовної інформації також як і обсяг CID використовуються, щоб розрізняти пакетні потоки. Таким чином, стиснутий заголовок тільки містить поле CID, поле покоління, та поле контрольної суми та в результаті має загальну довжину близько 4-5 октетів. У стиснутому заголовка Фіг.4, якщо використовується восьмирозрядний CID, CID (2) розташований у третьому октеті не є необхідним. Якщо використовується шістнадцятирозрядний CID, 8 розрядів розміщуються до CID (1) та інші 8 розрядів розміщуються до CID (2). Приймаючи до уваги те, що розмір повного заголовка є 48 октетів, слід зазначити, що тої самої мети можна досягнути завдяки передачі дуже малої кількості. В передачі пакетних даних, що використовує техніку стискування заголовка "Стиснутий TCP", наступний Алгоритм стискування заголовка TCP/IP (RFC 2507 "Стиснутий TCP"), пакет повного заголовка передається як перший пакет пакетного потоку. Контекст пакетного потоку впродовж цього модернізується стиснутим заголовком у відповідності з попередньо прийнятими пакетними заголовками. В передачі пакетних даних, що використовує іншу техніку стискування заголовка «Стиснутий TCP», наступний Алгоритм стискування заголовка 7 TCP/IP (RFC 2507 "Стиснутий TCP" з неприпустимою помилкою (не дельта)), пакет повного заголовка передається як перший пакет пакетного потоку. Наступні пакети передаються зі стиснутим заголовком, що містить дисперсію від попередньо переданого повного заголовка пакетного потоку. Контекст пакетного потоку постійно модернізується стиснутим заголовком відповідно до попередньо отриманого повного заголовка. В передачі пакетних даних, що використовує Алгоритм стискування заголовка UDP/IP (Стиснутий не-ТСР, Стискування зі стартовим уповільненням, в подальшому CCS), пакети повних заголовків передаються в першому пакеті та в деяких наступних пакетах в пакетному потоці за заздалегідь встановленим правилом. Фіг.5 є блок-схемою способу відповідного роду та для передачі пакета повного заголовка та пакета стиснутого заголовка відповідно до способу CCS. На цій фігурі, обсяг інтервалу INT (Інтервал) відображає кількість пакетів стиснутих заголовків, які можуть бути передані між двома пакетами повного заголовка, що передаються послідовно, та обсяг CNT (Рахунок) відображає кількість переданих пакетів стиснутих заголовків. Відповідно до цього способу, пакет стиснутого заголовка передається, і коли обсяг CNT та обсяг INT становляться однаковими, пакет повного заголовка передається замість пакета стиснутого заголовка. Обсяг INT модернізується в час, коли повний заголовок повинен бути переданий. Коли обсяг INT досягає MaxINT, який відповідає граничному обсягу інтервалу передачі, обсяг INT більше не збільшується та MaxINT підтримується. Процес припиняється, коли усі дані в пакетному потоці передаються або коли інформація повного заголовка змінюється. Спосіб передачі тепер буде описаний більш детально. По-перше, мінімальна кількість INT пакетів стиснутих заголовків, що може бути передана між пакетами повного заголовка встановлюється в первісному обсязі як "1". Коли ініціюється операція передачі пакета заголовка, спочатку передається пакет повного заголовка (S80), та після CNT, що відображає кількість переданих пакетів стиснутих заголовків, встановлюється як "0" (CNT=O) (S81). Далі, пакет стиснутого заголовка передається (S82) та після CNT, що відображає кількість переданих пакетів стиснутих заголовків, збільшується на "1" (CNT=CNT+1) (S83). Наступне, порівнюються обсяги CNT та INT (S84), і якщо обидва обсяги є різними, передається додатково пакет стиснутого заголовка та кроки S82-S84 повторно виконуються. Якщо обидва обсяги є однаковими, перевіряється чи є обсяг INT більшим за MaxINT ( в цьому винаході MaxlNT=256) (S85). Якщо обсяг INT менше за MaxINT, кроки S80-S85 повторно виконуються, в той час збільшуючи обсяг INT завдяки множенню на "2" (1, 2, 4, 8, 16, ..., 256). Але якщо є однаковим або більшим за обсяг MaxINT, обсяг INT далі не збільшується та той же самий інтервал передачі підтримується. 82886 8 Передача пакетів повного заголовка використовуючи спосіб CSS такого роду є передовим внаслідок принаймні двох аспектів. Поперше, навіть якщо пакет повного заголовка втрачений протягом передачі, стиснутий заголовок може бути відновлений використовуючи пакет повного заголовка, що передається наступним. По-друге, у випадку, коли один й той же пакет транслюється до кількох користувачів через техніку широкої трансляції, навіть якщо підключається під час віщання, новий користувач може нормально отримати дані після отримання пакета повного заголовка (тобто новий користувач може отримати стиснуті пакети та потім відновити їх, базуючись на інформації пакета повного заголовка, що передається наступним). Ці переваги додають значної стабільності системі. Незважаючи на ці переваги, спосіб CCS такого роду має багато недоліків. Наприклад, внаслідок того, що повний заголовок значно більше стиснутого заголовка, повторна передача значної кількості пакетів повного заголовка, в межах одного й того ж потоку даних значно знижує ефективність передачі. Це особливо спостерігається, якщо пакет повного заголовка успішно передається на першому етапі. У цих обставинах таким способом будуть продовжувати періодично передавати пакети повного заголовка в системі даних, навіть якщо первісний пакет повного заголовка був успішно переданий. Як стане ясніше нижче, автори цього винаходу визначили, що кожний пакет повного заголовка, переданий після того, як первісний пакет повного заголовка був успішно прийнятий, може бути розглянутий як такий, передавати який не є необхідним. стискування заголовка "Стиснутий Техніка TCP", яка слідує за Алгоритмом стискування заголовка TCP/IP такого роду також має деякі недоліки. Наприклад, контекст пакета стиснутого заголовка відновлюється відносно повного заголовка прямо або непрямо. Якщо один з цих заголовків пакета в потоці не приймається успішно або повний заголовок не приймається успішно, декілька пакетів, що ідуть за цим пакетом, не можуть бути відновлені принаймні зараз. Тобто передача пакетних даних з використанням Техніки стискування заголовка "Стиснутий TCP", якщо пакет повного заголовка або пакет стиснутого заголовка втрачається, потребує багато часу, щоб відновити відповідний контекст приймальною стороною. Більш того, сторона, що передає, не знає про ушкодження відповідного контексту. Таким чином, наступні пакети стиснутих заголовків безцільно передаються, що призводить до даремного витрачання радіоресурсів. Якщо приймач передає запит на надсилання пакета повного заголовка до передавача негайно, навантаження на трафік для запиту може бути значним навантаженням для радіоканалу. Предметом цього винаходу є вирішення принаймні вищезазначених проблем та/або подолання перешкод та забезпечення переваг, описаних далі. Іншим предметом цього винаходу є досягнення вищезазначеної мети завдяки забезпеченню системи та способу який контролює 9 передачу пакетів в системі зв'язку у такий спосіб, що є швидкішим та ефективнішим ніж інші системи/способи, які були запропоновані Іншим предметом цього винаходу є досягнення вищезазначеної мети завдяки значному збільшенню ефективності відновлення контексту заголовної інформації та пакетів, переданих в системі, в той же самий час, зменшуючи потребу у надсиланні пакета повного заголовка до передавача у будь-якому потоці даних порівняно з іншими запропонованими системами. Ще одним предметом цього винаходу є досягнення вищезазначеної мети завдяки використанню покращеної схеми стискування заголовка, яка оптимізує передачу пакетів повного заголовка та мінімізує кількість запитів на посилання пакета повного заголовка в будь-якому потоці даних, таким чином поліпшуючи ефективність передачі порівняно з іншими запропонованимипредметом цього винаходу є Ще одним системами. досягнення вищезазначеної мети завдяки значному зменшенню кількості пакетів повного заголовка переданих в системі, в той же час збільшуючи кількість пакетів стиснутого заголовка в будь-якому даному потоці даних, таким чином поліпшуючи ефективність передачі порівняно з іншими запропонованими системами. Ще одним предметом цього винаходу є досягнення вищезазначеної мети завдяки використанню покращеної схеми стискування заголовка, яка мінімізує кількість пакетів повного заголовка та максимально збільшує кількість пакетів стиснутого заголовка в будь-якому даному потоці даних, таким чином покращуючи ефективність передачі порівняно з іншими запропонованими системами. Іншою метою цього винаходу є забезпечення способу системи передачі пакетних даних, який поліпшує ефективність передачі та ефективність розпакування пакета, коли використовується техніка стискування "Стиснутий TCP" в системі УMTC. Іншою метою цього винаходу є забезпечення способу передачі пакетних даних, в якому пакет повного заголовка специфічного пакетного потоку знов передається періодично або неперіодично, і передача пакета повного заголовка контролюється для збільшення ефективності. Для досягнення цих та інших цілей та переваг забезпечується спосіб передачі пакетних даних комунікаційної системи, в якому, відносно одного пакетного потоку, рівень стискування заголовка сторони, що передає, визначає передачу пакета повного заголовка з повним заголовком або пакета стиснутого заголовка зі стиснутим заголовком через рівень каналу передачі даних відповідно до стану передачі попереднього пакета даних в рівні каналу передачі даних. В способі передачі пакетних даних цього винаходу, переважно, в рівні стискування заголовка передавальної сторони системи зв'язку, що включає кроки отримання потоку пакетних даних з верхнього рівня, передачі пакета повного заголовка, що має інформацію повного заголовка потоку пакетних даних через нижчий рівень, передачі пакета стиснутого заголовка, що має стиснутий заголовок, який містить порцію 82886 10 інформації повного заголовка через нижчий рівень, виявлення того, що пакет був прийнятим приймальною стороною завдяки доповіді нижчого рівня та передачі пакета, що повинен бути переданий як пакет повного заголовка, якщо виявляється, що цей пакет не був прийнятим. В способі передачі пакетних даних цього винаходу, переважно на етапі виявлення, включені наступні кроки: визначення того, чи виявляє рівень каналу передачі даних невдалу передачу пакета; та отримання інформації про виявлену невдалу передачу з рівня каналу передачі даних. В способі передачі пакетних даних цього винаходу, переважно, інформація про невдалу передачу містить ID інформацію та/або інформацію, що відображає невдалу передачу відповідного пакета. В способі передачі пакетних даних цього винаходу, переважно, попередньо встановлений спосіб стискування означає, що контекст модернізується заголовком цього пакета відповідно до заголовка попереднього пакета, вдало модернізованого від повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, спосіб стискування, що модернізується заголовком цього пакета відповідно до заголовка попереднього пакета, вдало модернізованого від повного заголовка, є технікою "Стиснутого TCP". В способі передачі пакетних даних цього винаходу, переважно, попередньо встановлений спосіб стискування означає, що контекст модернізується заголовком цього пакета відповідно до попереднього повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, спосіб стискування, що контекст модернізується пакетом повного заголовка є технікою неприпустимої помилки (nondelta) "Стиснутого TCP". В способі передачі пакетних даних цього винаходу, переважно, рівень стискування заголовка є рівнем протоколу конвергенції пакетних даних (PDCP) та рівень каналу передачі даних є рівнем контролю (RLC) радіоканалу. В способі передачі пакетних даних цього винаходу, переважно, верхній рівень матриці контролю рівня RLC є рівень RRC, що керує радіоресурсом, та рівень RRC встановлює радіопеленгатор так, що інформація про SDU, що був відбракований RLC, надсилається до рівня PDCP. В способі передачі пакетних даних цього винаходу, переважно, коли рівень PDCP передає PDCP PDU до рівня RLC, рівень PDCP інструктує рівень RRC інформувати рівень PDCP про невдалий результат передачі відповідного PDU. В способі передачі пакетних даних цього винаходу, переважно, коли рівень PDCP передає PDCP PDU до рівня RLC, рівень PDCP передає індикатор доповіді про невдалу передачу разом з відповідним PDU. Щоб досягнути цієї мети та інших цілей та переваг, забезпечується спосіб передачі пакетної інформації системи зв'язку, в якому відповідно до пакетного потоку, рівень стискування заголовка передавальної сторони передає пакет повного 11 заголовка з повним заголовком або пакет стиснутого заголовка з стиснутим заголовком через рівень каналу передачі даних та рівень стискування заголовка приймальної сторони відновлює інформацію стиснутого заголовка пакета стиснутого заголовка, використовуючи інформацію повного заголовка пакета повного заголовка, що включає кроки отримання потоку пакетних даних використовуючи Інтернет протокол, передачу пакета повного заголовка, що має інформацію повного заголовка потоку пакетних даних, передачу пакета стиснутого заголовка, що має стиснутий заголовок, який має порцію інформації повного заголовка, виявлення того, чи був прийнятий приймальною стороною цей пакет; та передачу пакета, що повинен бути переданий відразу після пакета повного заголовка, якщо визначається, що цей пакет не був прийнятий. В способі передачі пакетних даних цього винаходу, переважно, крок виявлення включає в себе виявлення того, чи визначає рівень каналу передачі даних невдалу передачу пакета та передачу виявленої інформації про невдалу передачу до рівня стискування заголовка. В способі передачі пакетних даних цього винаходу, переважно, інформація про невдалу передачу містить ID інформацію та/або інформацію, що відображає невдалу передачу відповідного пакета. В способі передачі пакетних даних цього винаходу, переважно, спосіб попередньо визначеного стискування полягає в тому, що контекст модернізується заголовком справжнього пакета відповідно до заголовка попереднього пакета успішно модернізованого від повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, цей спосіб стискування модернізований заголовком справжнього пакета відповідно до заголовка попереднього пакета, успішно модернізованого від повного заголовка є технікою "Стиснутого TCP". В способі передачі пакетних даних цього винаходу, переважно, спосіб попередньо визначеного стискування полягає в тому, що контекст модернізується заголовком справжнього пакета відповідно до попереднього повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, цей спосіб стискування полягає в тому, що контекст модернізується пакетом повного заголовка і це є технікою неприпустимої помилки "Стиснутого TCP". Спосіб передачі пакетних даних цього винаходу, переважно, надалі включає крок передачі свіжого пакета повного заголовка до передавальної сторони рівня каналу передачі даних, якщо отримується інформація про невдалу передачу з рівня каналу передачі даних. В способі передачі пакетних даних цього винаходу, переважно, коли рівень стискування заголовка отримує інформацію про невдалу передачу, рівень стискування заголовка стискує наступний перший пакет використовуючи той же самий CID з пакета, передача якого була невдалою, до пакета повного заголовка та передає його. 82886 12 В способі передачі пакетних даних цього винаходу, переважно, рівень стискування заголовка є рівнем протоколу конвергенції пакетних даних (PDCP) та рівень каналу передачі даних є рівнем контролю радіоканалу (RLC). В способі передачі пакетних даних цього винаходу, переважно, верхній рівень в матриці контролю рівня RLC є рівнем RRC, що керує радіоресурсом, та рівень RRC встановлює радіопеленгатор так, що інформація про SDU, який був відбракований RLC, надсилається до рівня PDCP. В способі передачі пакетних даних цього винаходу, переважно, коли рівень PDCP передає PDCP PDU до рівня RLC, рівень PDCP інструктує рівень RRC інформувати рівень PDCP про невдалий результат передачі відповідного PDU. В способі передачі пакетних даних цього винаходу, переважно, коли рівень PDCP передає PDCP PDU до рівня RLC, рівень PDCP передає індикатор доповіді про невдалу передачу разом з відповідним PDU. Цей винахід також забезпечує спосіб передачі пакетних даних в рівні стискування заголовка, що передає пакет повного заголовка або стиснутого заголовка через рівень каналу передачі даних відносно одного пакетного потоку, так що приймальна сторона може відновити інформацію стиснутого заголовка пакета стиснутого заголовка, використовуючи інформацію повного заголовка пакета повного заголовка; разом з кроками передачі пакета стиснутого заголовка або пакета повного заголовка до рівня каналу передачі даних, визначення результату передачі пакета рівнем каналу передачі даних; та посилання наступного пакета як пакета повного заголовка та передача його, коли інформація про невдалу передачу отримується з рівня каналу передачі даних через більш ніж один пакет. забезпечує апарат передачі Цей винахід також пакетних даних, що включає в себе модуль стискування заголовка, забезпечений в рівні стискування заголовка, та стискування заголовка даних, отриманих з верхнього рівня для трансформування його пакета повного заголовка або пакета стиснутого заголовка, модуль контролю стискування заголовка для контролю стискування заголовка модулем стискування заголовка відповідно до інформації про невдалу передачу; модуль передачі даних для передачі трансформованого пакета повного заголовка або пакета стиснутого заголовка до рівня каналу передачі даних, де буфер та модуль передачі забезпечені в рівні каналу передачі даних, та передачу пакета, переданого з модуля передачі даних рівня стискування заголовка до приймальної сторони, та модуль розрізнювання невдалої передачі для розрізнювання пакета або пакетів, передача яких була невдалою, переданих до приймальної сторони та доставляння інформації про невдалу передачу до модуля контролю стискування заголовка. В апараті передачі пакетних даних цього винаходу, переважно, інформація про невдалу передачу містить ID інформацію відповідного пакета та/або індикатор невдалої передачі. 13 В апараті передачі пакетних даних цього винаходу, переважно, модуль контролю стискування заголовка контролює модуль стискування заголовка, щоб стиснути наступний перший пакет, використовуючи той же самий CID, що і CID пакета, передача якого була невдалою, як пакет повного заголовка, якщо він отримує інформацію про невдалу передачу з модуля розрізнювання невдалої передачі. В апараті передачі пакетних даних цього винаходу, переважно, рівень стискування заголовка є рівнем протоколу конвергенції пакетних даних (PDCP) та рівень каналу передачі даних є рівнем контролю радіоканалу (RLC). Цей винахід також забезпечує спосіб передачі пакетних даних комунікаційної системи, в якому, стосовно одного пакетного потоку, рівень стискування заголовка передавальної сторони визначає передачу пакета повного заголовка з повним заголовком або пакета стиснутого заголовка з стиснутим заголовком через рівень каналу передачі даних відповідно до успіху передачі попереднього пакета повного заголовка в рівні каналу передачі даних. В способі передачі пакетних даних цього винаходу, переважно, в рівні стискування заголовка передавальної сторони системи зв'язку, що включає кроки отримання потоку пакетних даних з верхнього рівня; передачі пакета повного заголовка, що має інформацію повного заголовка потоку пакетних даних через нижчий рівень, передачі пакета стиснутого заголовка, що має стиснутий заголовок, який містить порцію інформації повного заголовка через нижчий рівень, виявлення факту прийняття пакета приймальною стороною через доповідь нижчого рівня; та передачу пакета, що повинен бути переданий як пакет стиснутого заголовка, якщо виявляється, щопередачі пакетних даних цього В способі пакет був прийнятий. винаходу, переважно, передавальна сторона передає пакет повного заголовка або пакет стиснутого заголовка і приймальна сторона відновлює інформацію стиснутого заголовка пакета стиснутого заголовка, використовуючи інформацію повного заголовка пакета повного заголовка, разом з кроками отримання потоку пакетних даних використовуючи Інтернетпротокол, передачі пакета повного заголовка, що має інформацію повного заголовка потоку пакетних даних, виявлення того, чи був прийнятий приймальною стороною цей пакет; та передачу пакетів в тому ж самому потоці, який передає їх наступним як пакети стиснутих заголовків, коли виявляється, що цей пакет був прийнятий. В способі передачі пакетних даних цього винаходу, переважно, якщо принаймні один пакет повного заголовка з переданих пакетів повного заголовка вдало передається, рівень стискування заголовка не передає більше пакета повного заголовка і передає тільки пакет стиснутого заголовка. В способі передачі пакетних даних цього винаходу, переважно, пакет повного заголовка передається з використанням техніки стискування з уповільненням. 82886 14 В способі передачі пакетних даних цього винаходу, переважно, рівень виконання стискування заголовка отримує інформацію щодо невдалої передачі пакета повного заголовка через специфічний пакетний потік з рівня каналу передачі даних, і якщо попередньо не було вдало прийнято пакет повного заголовку, рівень виконання стискування заголовка негайно додатково передає пакет повного заголовка для відповідного пакетного потоку, не приймаючи до уваги період передачі пакета повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, пакет повного заголовка передається в попередньо встановлений період передачі пакета повного заголовка після додаткової передачі пакета повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, результатом передачі є пакет ID інформації та інформації результату передачі. В способі передачі пакетних даних цього винаходу, переважно, коли рівень стискування заголовка передає пакет повного заголовка до рівня каналу передачі даних, нижчий рівень, що передає пакет повного заголовка і індикатор пакета повного заголовка разом являють собою пакет повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, коли рівень стискування заголовка отримує інформацію, що пакет повного заголовка був вдало переданий з рівня каналу передачі даних, рівень стискування заголовка не виконує періодично або неперіодично повторну передачу пакета повного заголовка відносно відповідного пакетного потоку але передає тільки пакет стиснутого заголовка. Цей винахід також забезпечує спосіб передачі пакетних даних системи зв'язку, в якому рівень стискування заголовка повторно передає пакет повного заголовка через специфічний потік бітів (подвійних сигналів) до приймальної сторони через рівень каналу передачі даних періодично або неперіодично, включаючи кроки передачі пакета повного заголовка або пакета стиснутого заголовка, визначення результату передачі пакета стиснутого заголовка та передачі тільки стиснутого заголовка, а не пакета повного заголовка, коли принаймні один пакет повного заголовка успішно передається відносно одного пакетного потоку. В способі передачі пакетних даних цього винаходу, переважно, пакет повного заголовка передається з використанням техніки стискування з уповільненням. Переважно, спосіб передачі пакетних даних цього винаходу надалі включає крок додаткової передачі пакета повного заголовка відносно відповідного пакетного потоку, незважаючи на період передачі пакета повного заголовка, якщо передача пакета повного заголовка відносно специфічного пакетного потоку не є вдалою і попередньо не було успішно передано пакетів повного заголовка. В способі передачі пакетних даних цього винаходу, переважно, результат передачі є ID інформація пакета та інформація результату передачі. Винахід буде детально описаний з посиланням на наступні графічні матеріали, в яких 15 номери посилань відносяться до ідентичних елементів, де: Фіг.1 є схемою, що показує інтервали передачі, використані, щоб передати інформацію повного заголовка відповідно до способу CSS такого рівня техніки; Фіг.2 є блок-схемою системи пакетної передачі, що використовує техніку стискування заголовка відповідно до такого рівня техніки; Фіг.3 є схемою, що відображає структуру пакета стану контексту, використаного для відновлення контексту пакетів переданих в системі зв'язку; є схемою, що відображає структуру Фіг.4 стиснутого заголовка використаного в протоколі UDP/IP; Фіг.5 є блок-схемою, що відображає спосіб для передачі пакетів повного та стиснутого заголовків завдяки способу CSS такого роду; Фіг.6 є схемою, що відображає мережну структуру в домені пакета серед мережних структур рекомендованих 3GPP; Фіг.7 є схемою, що відображає структуру радіоінтерфейсного протоколу між терміналом та UTRAN на основі 3GPP мережного стандарту радіозв'язку з абонентами; Фіг.8 є схемою, що відображає структуру протоколу матриці користувача, що використовується, коли мережа УМТС забезпечує послугу пакетної комутації. Фіг.9 є схемою, що відображає структуру нормального заголовка, переданого для TCP/lРv6; Фіг.10A є схемою, що відображає структуру повного заголовка, переданого при використанні техніки стискування заголовка для TCP/IPv6; Фіг.10Б та 10В відображають формат стиснутого TCP та формат стиснутого ТСРз неприпустимою помилкою, відповідно; Фіг.11 є схемою, що відображає структуру нормального заголовка, переданого для UDP/IPv6; Фіг. 12А є схемою, що відображає структуру повного заголовка, переданого при використанні техніки стискування заголовка для UDP/IPv6; Фіг.12Б та 12В відображають формат стиснутого не-ТСР 8-бітного CID та формат стиснутого не-ТСР 16-бітного CID, відповідно; Фіг.13А графічно відображає особливість кращого варіанту втілення винаходу відповідно до передачі пакета стиснутого та повного заголовка для TCP передачі; Фіг.13В графічно відображає цю особливість кращого варіанту втілення винаходу відповідно до передачі пакета стиснутого та повного заголовка для не-ТСР передачі; Фіг.14 є блок-схемою, що відображає систему пакетної передачі, яка використовує техніку стискування заголовка відповідно до одного варіанту втілення цього винаходу ; та Фіг.15 є блок-схемою, що відображає кроки включені до способу для передачі пакетів повного заголовка та стиснутого заголовка завдяки CSS відповідно до одного варіанту втілення цього винаходу. Режими для виконання переважних варіантів втілення 82886 16 Фіг.6 є схемою, що відображає мережну структуру домену комутації пакетів, запропонованого TSG-RAN та TSG-CN. В цій структурі UTRAN включає велику кількість радіомережних підсистем (RNS), кожна з яких включає велику кількість вузлів В, з'єднаних з одним контролером радіомережі (RNC). Базова мережа (CN) має іншу структуру відповідно до прийнятого комутаційного режиму (мережа з комутацією пакетів або мережа з комутацією каналів або ліній). У випадку, де мережа з комутацією пакетів враховується в цьому винаході, CN, переважно, включає велику кількість Службових GPRS вузлів підтримки (SGSN) та один GPRS вузол підтримки міжмережного інтерфейсу (GGSN). Кожний вузол В служить як пункт з'єднання для встановлення зв'язку між абонентською апаратурою (UE) (головним чином має назву мобільної станції або терміналу) та UTRAN. RNC призначає радіоресурс кожному UE, та керує цим радіоресурсом. RNC класифікується за одним з двох типів. Один тип RNC, відомий як контрольний RNC (CRNC), керує загальним радіоресурсом. Другий тип RNC, відомий як службовий RNC (SRNC), керує призначеним радіоресурсом, наданим кожному терміналу. RNC, де розміщується даний SRNC даного UE, називається SRNC, коли розглядається зі специфічного UE. Маршрутна інформація SGSN, передана з UTRAN до CN та GGSN, служить як міжмережний перехід (інтерфейс), щоб передати інформацію з UTRAN до різних CN, якщо призначенням інформації є мережа, що відрізняється від поточної CN. Інтерфейси за даними кожної сторони мають різні імена, а саме, інтерфейс між UE та вузлами В має назву "Uu" , інтерфейс між вузлами В та зв'язаним RNC має назву "lub", інтерфейс між різними RNC має назву "lur", інтерфейс між різними RNC та різними SGSN має назву "Іu", та інтерфейс між різними SGSN та GGSN або між різними SGSN має назву "Gn". Мережа пакетних доменів (PDN) є базовою мережею домену з комутацією пакетів, котра підтримує зв'язок між різними мережами в зоні обслуговування пакета (зоні впевненого прийому пакета). На Фіг.6 показано приклад мережної структури, в якій інтерфейс „lur" може необов'язково (на вибір) існувати між різними RNC та іншим SGSN. Також інтерфейс "Gn" може необов'язково існувати між різними SGSN. На Фіг.7 та 8 показано, що мережна структура Фіг.6 має ієрархічну структуру. На Фіг.7 показано детальну ієрархію UTRAN або UE для підтримки інтерфейсу "Uu", який є радіоінтерфейсом. На цій фігурі матриця користувача (U -матриця) є регіоном, до якого передається інформація про трафік користувача, така як мовний або IP пакет, та матриця контролю (С-матриця) є регіоном, до якого передається контрольна інформація, наприклад, обслуговування та управління інтерфейсом або викликом. U-матриця включає фізичний рівень (L1), що служить як перший рівень, рівень протоколу конвергенції пакетних даних (PDCP)1 рівень 17 контролю радіоканалу (RLC), рівень протоколу управління доступом (МАС), та рівень широкого віщання (ВМС), що служить як другий рівень (рівень каналу передачі даних) - 7 „рівнів, визначених моделлю взаємодії відкритих систем OSI (Open Systems Interconnection). С-матриця включає рівень контролю радіоресурсу (RRC), рівень RLC, рівень МАС, рівеньL1. L1 (фізичний рівень) забезпечує Рівень послугу передачі інформації до верхнього рівня використовуючи різноманітні техніки радіозв'язку з абонентами. Рівень L1 з'єднується з рівнем МАС через транспортний канал і обмін даними між рівнем L1 та рівнем МАС відбувається через транспортний канал. Транспортний канал класифікується за одним з двох типів, а саме виділений транспортний канал та загальний транспортний канал, залежно від того, чи використовується один термінал для каналу або багато терміналів використовують цей канал. Рівень МАС забезпечує послугу перерозподілу параметру МАС для розміщення та перерозподілу радіоресурсу. Рівень МАС приєднується до RLC рівня через логічний канал, та різноманітні логічні канали забезпечуються відповідно до типів інформації, що передається. Загалом, коли інформація передається на С-площину, використовується контрольний канал, і коли інформація передається на U-площину, використовується канал трафіка. встановлення або Рівень RLC виконує функції розмикання радіоканалу, сегментування та перекомлонування елементів службових даних (SDU) RLC, що надходять з верхнього рівня, та виконання повторної передачі RLC PDU втрачених протягом передачі. Розмір RLC SDU контролюється в рівні RLC. Потім заголовки приєднуються для того, щоб трансформувати SDU в елементи даних протоколу (PDU) для передачі до рівня МАС. Рівень RLC працює в трьох режимах, а саме в прозорому режимі, підтвердженому режимі та непідтвердженому режимі, відповідно до способу обробки RLC SDU. Буфер RLC включається до рівня RLC для зберігання RLC SDU або RLC PDU. Рівень PDCP є верхнім рівнем рівня RLC, який дозволяє даним, переданим через IP мережний протокол, такий як IPv4 або IPv6, ефективно передаватися до рівня RLC. Рівень PDCP також зменшує інформацію заголовка, яка не є необхідною для бездротової мережі, але яка може бути використана для дротової мережі, таким чином гарантуючи те, що ці дані можуть бути ефективно передані. Ця функція, що має назву стискування заголовка, може бути використана для зменшення кількості інформації заголовка, використаної, наприклад, в зв'язку TCP/IP. Для наочності рівень PDCP та рівень ВМС показані розташованими на матриці користувача, тому що вони передають тільки дані користувача. Рівень RLC може належати матриці користувача або матриці контролю, відповідно до рівня з'єднаного з верхнім рівнем. Це означає, що коли рівень RLC отримує дані з рівня RRC, він належить матриці контролю, в той час в інших 82886 18 випадках рівень RLC належить матриці користувача. Загалом, послуга передачі даних користувача, надісланих з матриці користувача до верхнього рівня завдяки рівню L2 визначається як сигнальний пеленгатор (SRB). Як надалі показано на Фіг.7, рівень RLC та рівень PDCP можуть кожний включати велику кількість об'єктів Це внаслідок того, що один UE може мати декілька RB та, загалом, один RLC рівень та рівень PDCP можуть виконувати незалежні функції в кожному рівні. Рівень ВМС передає повідомлення з центру сотового віщання (CBC) через радіоінтерфейс. Головною функцією ВМС є планування повідомлення сотового віщання переданого до UE та передача його через рівень RLC, що працює в непідтвердженому режимі (режим без підтвердження). розташований найбільш низько в Рівень RRC, третьому рівні (L3), визначається тільки в матриці контролю. Він функціонує для трансляції системної інформації до кожного UE розташованого в довільно вибраному районі. Рівень RRC також обробляє сигнал матриці контролю для контрольного сигналу, виміряного в третьому рівні, та виконує функцію встановлення, підтримання в працездатному стані та вивільнення радіоресурсу між UE та UTRAN. При виконанні останньої функції рівень RRC встановлює, перебудовує та розмикає RB та виконує функцію розміщення, перекомпонування та вивільнення радіоресурсу необхідного для встановлення радіоресурсного з'єднання. Тоді ж встановлення RB включає процес визначення протокольного рівня та канальних характеристик, необхідних для визначення попередньо визначеної послуги в радіозоні, також як і встановлення кожного специфічного параметру способу експлуатації. Послуги, що забезпечуються для UE, можуть бути загалом класифіковані як послуги з комутації каналів та послуги з комутації пакетів. Послуга мовного виклику включена, наприклад, в послузі комутації каналів та послузі швидкого огляду файлів WWW (Web-browsing service) через з'єднання Інтернет, може бути включена до послуги комутації пакетів. Послуга комутації каналів з'єднується з UTRAN через MSC базової мережі, та послуга комутації пакетів забезпечується через SGSN базової мережі. Таким чином, місце доступу до базової мережі, до якої приєднана UTRAN, може бути різним залежно від типу послуги, схема, що відображає приклад Фіг.8 - це що забезпечується. протокольної структури матриці користувача, яка може бути використана для забезпечення послуги комутації пакетів в мережі УМТС. Тут SGSN підтримує послугу комутації пакетів, направлених до UTRAN, та виконує функції управління мобільністю, такі як модернізація маршрутизації, реєстрація інформації про місцезнаходження або виклик та контроль питань безпеки. SGSN підтримує зв'язок з різними мережами з комутацією пакетів наприклад з мережею Інтернет. Процес передачі послуги комутації' пакетів з зовнішньої мережі з комутацією пакетів до терміналу буде описанийрізних процедур обробки Після проходження далі. пакети, що відносяться до прикладної програми, 19 досягають SGSN в формі пакетів IP. По підтвердженні адреси IP пакета SGSN передає пакети до UTRAN через SGSN. В цей час GTP-U, використана для передачі IP пакета, капсулює дані користувача між UTRAN та SGSN або між SGSN та GGSN, та тунелює їх. Тобто GTP-U отримує пакет даних користувача з зовнішньої пакетної мережі, виявляє адрес призначення пакета та передає його до наступного пункту призначення відповідно до встановленого шляху. Протокол передачі дейтаграм користувача (UDP)/IP протокол широко використовується для пакетної передачі в дротовій мережі, розташований нижчому рівні протоколу GTP-U та несе пакет GTP-U. IP пакет, переданий до RNC мережі UTRAN завдяки GTP-U, передається до рівня PDCP, який зменшує розмір заголовка завдяки техніці стискування заголовка та передає результат до рівня RLC у формі PDCP PDU (=RLC SDU). Рівень RLC належним чином сегментує або конкатенує RLC SDU, що надходять з верхнього рівня та перетворює їх у форму RLC PDU, таким чином створюючи RLC PDU. Якщо RLC SDU є більшим ніж RLC PDU, RLC SDU може бути сегментованим, щоб сконструювати декілька RLC PDU. З іншого боку, якщо RLC SDU є меншим ніж RLC PDU, декілька RLC SDU можуть бути згруповані разом для конструювання одного RLC PDU. Сконструйовані таким чином RLC PDU мультиплексуються з RLC PDU інших UE в рівні МАС та передаються до фізичного рівня. В UE (або терміналі) PDCP PDU передаються через рівні МАС та RLC до рівня PDCP, та рівень PDCP UE відновлює інформацію стиснутого заголовка щоб відновити оригінальний IP заголовок. Результуючий IP пакет після передається до IP рівня. Техніка стискування заголовка, яку рівень PDCP виконує в UE та UTRAN, буде описана далі. В передачі IP пакета та особливо при передачі IP пакета через радіоінтерфейс, причиною стиснення заголовку є те, що розмір заголовка IP пакета не є настільки малим, щоб бути проігнорованим порівняно з розміром корисного навантаження пакета. Наприклад, коли UE отримує дані з IP мережі, інформація заголовка IP додається до кожного пакета щоб дозволити пакету пересилатися за визначеними маршрутами в IP мережі. В цей же час, у випадку IPv4, інформація заголовка в 24 октети приєднується та у випадку IPv6, інформація заголовка в 40 октетів приєднується. Якщо TCP рівень або UDP рівень розташовуються над рівнем IP, 24 октети та 8 октетів інформації заголовка вимагаються додатково. Таким чином, у випадку передачі пакету з використанням TCP/IPv6, принаймні інформація заголовка в 64 октети вимагається для пакету, в той же час у випадку передачі пакету з використанням UDP/IPv6, принаймні інформація заголовка в 48 октетів вимагається на пакет. Слід зазначити, що у випадку послуги передачі мови по IP протоколу VoIp (Voice over IP), де пакет передається, використовуючи UDP/IPv6, інформація заголовка в 82886 20 48 октетів є значно більшою порівняно з корисним навантаженням, яке має тільки множину октетів (тобто 20 октетів у випадку коли інформація заголовка стискується 8Кб/с G.729 кодеком (компресором-декомпресором)). Таким чином, якщо IP пакет передається як у випадку, де він використовується для каналу з обмеженою смугою пропускання передачі, наприклад, радіоканалу, легко очікувати, що матиме місце значне погіршення роботи. Щоб уникнути такого роду проблем, були проведені дослідження техніки стискування заголовка для зменшення інформації заголовка в пакетах. Техніки стикування заголовка виконують стискування, базуючись на усвідомленні того, що пакети, які належать тому ж самому пакетному потоку, мають майже однакову інформацію заголовка. Інакше кажучи, пакетний потік позначає послідовні пакети, що мають схожу інформацію заголовка, та, загалом, пакети, що використані для забезпечення якоїсь специфічної послуги, можуть розглядатися як ті, що належать до одного пакетного потоку. Наприклад, у випадку передачі пакетів для TCP/IP пакети, передані з однаковою адресою та номером порту розглядаються як такі, що належать до одного пакетного потоку. На Фіг.9 показано поле заголовка TCP/IPv6, надане, щоб зрозуміти принцип та ступінь стискування техніки стискування заголовка. Спершу, як зазначено вище, стосовно обговорення пакетного потоку, внаслідок того, що адресні поля IPv6 та номери портів TCP заголовка належать до одного пакетного потоку, вони можуть розглядатися як постійні. На Фіг.9, поле варіанту відображає використання заголовка IPv6 та поле наступного заголовка (NH) відображає, що інформація заголовка, яка надходить після заголовка IPv6, є TCP заголовок. Як результат, обидва можуть бути розглянуті як схожі відносно відповідного пакетного трафіка. Поле класу трафіка відображає пріоритет відповідного пакета, та поле мітки потоку (FL) контролює пакет відповідно до пріоритету. В цей час, якщо значення FL встановлюється не на відмітці "0", поле класу трафіка попереду поля FL не змінюватиметься. З іншого боку, якщо значення FL встановлюється на відмітці "0", поле класу трафіка попереду поля FL може бути змінено. Однак, внаслідок того, що пакети, які мають показник іншого поля класу трафіка, можуть бути визначеними як такі, що належать іншому пакетному потоку, показники поля класу трафіка та поля FL розглядаються незмінними відносно одного пакетного потоку. Поле ретрансляційного ліміту (HL) зменшується на "1", коли маршрутизатор передається в мережі Якщо показник поля HL стає "0", відповідний пакет відбраковується. Загалом, внаслідок того, що пакети передаються через той же самий шлях в мережі, показник поля HL також розглядається майже постійним для специфічного пакетного потоку. Поле відхилення відображає стартову точку даних TCP, що є постійною. У випадку, коли передаються пакети, що належать одному пакетному потоку, поля заголовка, які містять інформацію, що не 21 змінюється, переважно відносяться до полів Фіг. 9, що затінені. Більш того, слід зазначити, що деталізовані описи техніки стискування заголовка розкриваються в формальній технічні документації відносно технології Інтернет, що надані проблемною групою проектування Інтернет IETF. Наприклад, рівень PDCP може використовувати техніку стискування заголовка, що базується на RFC 2507 та RFC 3095. Що стосується техніки стискування заголовка RFC 2507, інша техніка стискування заголовка може бути використана залежно від того, чи протокол розташований над рівнем IP TCP або не-ТСР. Якщо протокол, розташований над рівнем IP, не використовує TCP, такий як протокол UDP/IP, може бути використаний спосіб "Стиснутий не-ТСР". Якщо протокол розташований над рівнем IP є TCP, він розділяється на "Стиснутий TCP" ("Compressed TCP") та "Стиснутий TCP" неприпустима помилка" ("Compressed TCP nondelta") відповідно до шляху передачі змінного поля заголовка. Техніка стиснутого TCP - це спосіб передачі різних показників між невідібраних пакетів, скоріше ніж надсилання загального показника поля. Це виконується, базуючись на концепції, що мала різниця існує між показниками змінних полів заголовка. З іншого боку, "Compressed TCP nondelta" є способом передачі змінного поля заголовка як такого. Для того, щоб приймальна сторона відновила стиснутий заголовок, необхідним є контрольне значення. Таким чином, стискування заголовка може бути виконано завдяки передачі повного заголовка, що містить кожне поле не-стиснутого заголовку. Незмінна порція в специфічному пакетному потоці повного заголовка, як показано завдяки затіненим частинам на Фіг.4, використовується, щоб відновити стиснутий заголовок, який повинен бути переданий надалі. Інформацією, яка є потрібною для відновлення стиснутого заголовка, визначається контекст відповідного пакетного потоку, та цей контекст служить в якості еталонної інформації в відновленні стиснутого заголовка до нормального заголовка. Пакет, що містить повний заголовок, який потрібен для модернізації або створення контексту може бути визначений як пакет повного заголовка, і пакет, в якому інформація заголовку стискується і передається, може бути визначений як пакет стиснутого заголовка. Коли має місце зміна в контексті протягом пакетної передачі, змінений повний заголовок повинен бути переданий до передачі пакетів стиснутого заголовка. Як зазначено вище, пакет повного заголовка є значно більшим, ніж загальний пакет стиснутого заголовка, і пакетний потік переважно створюється так, що поле не часто змінюється в пакетному потоці. для стискування заголовка Використана техніка стискування заголовка, що використовує "Compressed TCP" або "Compressed TCP nondelta", такі як TCP/IP, буде розкрито. Вище було обговорено, що була запропонована техніка заголовка, яка передає пакет повного заголовка як перший пакет в потоці даних. Відповідно до цієї техніки, внаслідок того що може бути більш ніж 82886 22 один пакетний потік в мережі, може бути використаний ідентифікатор, що відображає контекст кожного пакетного потоку для відокремлення цих потоків. Ідентифікатор цього типу має назву контекстного ідентифікатора (CID). У багатьох, якщо не у всіх випадках, обсяг CID має 8 біт (розрядів) для пакету TCP, та коли стиснутий заголовок повного заголовку передається, показник CID також має бути переданим. Передана інформація повного заголовка зберігається в приймальній стороні відповідно до показника CID, і коли пакет надходить, приймальна сторона читає інформацію повного заголовка, базуючись на показнику CID, щоб відновити інформацію оригінального заголовка. На Фіг.10A показано структуру переданого повного заголовку при прийнятій техніці стискування заголовку для TCP/IPv6. B цей час повний заголовок є однаковим для "Compressed TCP" або "Compressed TCP nondelta". Якщо оригінальне поле заголовку TCP/IPv6 не включає поле CID, неможливо ввести показник CID. Таким чином, необхідно знайти відповідне поле для вводу показника CID. Внаслідок того, що інформація про існуюче поле "довжини корисного навантаження" є інформацією, яка може бути отримана з нижчого рівня, використання відповідного поля не є необхідним. Отже, показник CID може бути введений до поля "довжини корисного навантаження" та переданий. Фіг.10Б та 10В відображають формат стиснутого TCP та формат з неприпустимою помилкою стиснутого TCP, відповідно, згідно з переважним варіантом втілення цього винаходу. Стиснутий заголовок, сформований технікою стиснутого TCP та переданий з використанням TCP/IPv6, створюється у відповідності з незатіненими порціями заголовку Фіг.10А. Тоді ж для полів стиснутого заголовка поле CID має фіксований обсяг, поле контрольної суми має змінний обсяг, та поля, що залишилися мають обсяг, що відрізняється від попередньо стиснутого заголовка. Розмір стиснутого заголовка є за звичай 4-7для TCP/IPv6 використовується техніка Якщо октетів. "Compressed TCP nondelta", стиснутий заголовок формується у відповідності з незатіненими порціями заголовку Фіг.10А, що є такою ж, як техніка "Compressed TCP". Тоді ж для полів стиснутого заголовка поле CID має фіксований обсяг, та поля, що залишилися, мають змінний обсяг. Внаслідок того, що всі ці поля, на відміну від поля CID, мають змінний обсяг, змінні обсяги зазвичай мають більше бітів ніж обсяги різниці (difference value), розмір заголовка Compressed TCP nondelta більше за заголовок Compressed TCP. Розмір стиснутого заголовка є зазвичай 17 октетів. Протокол, що не використовує TCP, такий як UDP/IP протокол, стискує заголовок, використовуючи спосіб "Compressed non-TCP" аналогічно випадку TCP/IP. Як і в TCP/IP, для того, щоб використати техніку стискування заголовка для специфічного пакетного потоку, процес передачі пакету повного заголовка як першого пакету є необхідним, та включення CID для ідентифікації кожного пакетного потоку є також 23 необхідним. Показник CID, який зазвичай має довжину 8 бітів або 16 бітів, передається разом з стиснутим заголовком або повним заголовком. В техніці стискування заголовка UDP/IP, додатково до показника CID, додатково використовується поле покоління (generation field), що відображає покоління інформації заголовка. Поле покоління (generation field) відображає, наскільки старою є інформація заголовка пакета, і вона завжди передається разом з показником CID. На Фіг.12А показано структуру повного заголовку, переданого відповідно до техніки стискування заголовку, використану для пакету UDP/IPv6. Як показано, що як нормальне UDP/IPv6 поле заголовка (Фіг.11) не має поля CID або поля покоління (generation field), то CID та показники покоління вводяться до існуючого поля "довжина корисного навантаження" або поля „довжина" та потім передаються. У випадку, де використовується 8-бітний обсяг CID, тільки CID (1) може бути використаний. У випадку, де використовуються 16-бітний обсяг CID, тільки CID (2) може бути використаний, та частина поля корисного навантаження використовується для показника покоління. Фіг.12Б та 12В відображають формат стиснутого не-ТСР ("Compressed non-TCP") 8бітного CID та формат стиснутого не-ТСР ("Compressed non-TCP") 16-бітного CID, відповідно, згідно з переважним варіантом втілення цього винаходу. Стиснутий заголовок переданий з використанням техніки стискування заголовка для UDP/IPv6, формується у відповідності з незатіненими порціями заголовку, показаного на Фіг.12А. Розмір цього заголовка зазвичай 4-5 октетів. Тоді ж для полів стиснутого заголовка, поле CID та поле покоління мають фіксований обсяг, та поле контрольної суми має змінний обсяг. Цей винахід є системою та способом для контролю передачі пакетів в системі зв'язку у спосіб, що є швидшим та ефективнішим за інші системи, що пропонуються. Цей винахід досягає таких успіхів, завдяки запровадженню пакетної схеми стискування заголовка, яка визначає передачу пакета з одним повним заголовком або стиснутим заголовком відповідно до доповіді нижчого рівня, переважно, без будьякого запиту з боку приймача. Переважно, визначення виконується в рівні PDCP, та нижчим рівнем є рівень RLC. Це гарантує, що процес приєднання повного заголовку до пакета запускається доповіддю RLC про невдалу передачу попереднього пакета, додатково до класичного способу, та один з тригерів приєднання повного заголовка до пакета, у відповідності з класичним способом, таким як спосіб CSS, виключається завдяки доповіді RLC про вдалу передачу попереднього пакета повного заголовка, тим Відповідно до одного варіанту втілення цього самим покращуючи ефективність передачі та винаходу, цей винахід дозволяє передачу пакету швидкість передачі даних. повного заголовка, навіть якщо приймач цього не вимагає. Класично, пакет повного заголовка є, переважно, першим пакетом, переданим в цьому потоці, але якщо це є бажаним, пакет повного заголовка може бути переданим після першого пакета. Пакети, що залишилися в потоці, є, 82886 24 переважно, пакетами стиснутих заголовків. В приймачі стиснуті заголовки трансформуються в повні заголовки, базуючись на інформації повного заголовка в ново-переданому пакеті повного заголовка, хоча приймач не в змозі встановити контекст інформації заголовка пакетного потоку з першим пакетом повного заголовка. Відповідно до іншого варіанту втілення цього винаходу, цей винахід досягає кращих характеристик завдяки запровадженню схеми пакетного стискування, яка мінімізує кількість пакетів, переданих з інформацією повного заголовка в будь-якому даному потоці даних. Це гарантує, що майже усі пакети в потоці передаються з інформацією стиснутого заголовка, тим самим поліпшуючи ефективність та швидкість передачі даних. Відповідно до цього варіанту втілення, винахід дозволяє передавати цілісний потік даних тільки з одним пакетом повного заголовка, та пакети, що залишились в потоці, передаються з стиснутими заголовками. В приймачі стиснуті пакети трансформуються в пакети повного заголовка, базуючись на інформації вчас, як поодинокому пакеті повного В той цьому цей винахід може бути використаний у великій кількості систем зв'язку, як заголовка. в дротових, так і в бездротових, цей винахід ідеально підходить для використання в системі мобільного радіозв'язку, такій як система УМТС, яка передає пакети відповідно до протоколу, який включає рівень стискування заголовка та рівень каналу передачі даних. Протягом роботи рівень стискування заголовка створює та посилає пакети стиснутих заголовків та пакети повних заголовків до рівня каналу передачі даних для передачі. В найкращих варіантах втілення, однією з нових характеристик є визначення одного повного або стиснутого заголовка відповідно до доповіді нижчого рівня, та переважно, не зважаючи на будь-який запит з боку приймача. Визначення виконується в PDCP, та нижчим рівнем є рівень RLCПосилаючись на перший варіант втілення, передавача. рівень стискування заголовка контролює, котрий пакет стискувати, базуючись на інформації зворотного зв'язку з рівня каналу передачі даних, що відображає, чи був відбракований попередньо переданий пакет повного заголовка (це означає, що передача була невдалою). Якщо так, наступний пакет в потоці може бути переданий як пакет повного заголовка. Якщо ні, приймач може спіткати невдача у встановленні контексту інформації заголовка пакетного потоку з цим першим пакетом повного заголовка або вдалим пакетом зі стиснутим заголовком, та він може не відновити інформацію заголовка завдяки пакету стиснутого заголовка. Якщо навіть цей приймач міг би встановити контекст інформації заголовка пакетного потоку з цим першим пакетом повного заголовка, рівень стискування заголовка передавача посилає пакет повного заголовка, коли б нижчий рівень не доповідав, що він відхилив пакет. Через цю інформацію зворотного зв'язку нижчого рівня, цей винахід, отже, є здатним мінімізувати кількість запитів пакетів повного заголовка змовою, в стиснутому TCP (включаючи Іншою приймача. "Стиснутий TCP" з неприпустимою помилкою), 25 навіть якщо цей приймач (це означає PDCP приймача) не вимагає передачі пакета повного заголовка, якщо будь-який RLC SDU (так само як PDCP PDU) відхиляється (це означає, що передача була невдалою), цей PDCP посилає пакет повного заголовка наступного разу. Фіг.13А графічно відображає цю особливість відповідно до передачі пакетів стиснутого та повного заголовків. Як тут зазначено, якщо рівень RLC (тобто передавача), доповідає, що передача пакета була невдалою, рівень PDCP (тобто передавача), посилає пакет повного заголовка після запропонованого часу доповіді. Посилаючись на другий варіант втілення, рівень стискування заголовка контролює, які пакети стискувати, базуючись на інформації зворотного зв'язку з рівня каналу передачі даних, котра відображає, чи був успішно прийнятий попередньо переданий пакет повного заголовка. Якщо так, пакети, що залишились в потоці, можуть бути передані як пакети стиснутого заголовка. Якщо ні, один або більше пакетів повного заголовка з перервами передаються, доки один з пакетів не буде вдало прийнятим. Пакети, що залишились, потім передаються як пакети стиснутого заголовка. Через цю інформацію зворотного зв'язку нижчого рівня, цей винахід, таким чином, має змогу мінімізувати кількість пакетів повного заголовка, переданих в будьякому наданому потоці даних. Іншою мовою, в стиснутому не-ТСР (Стискування з уповільненням), навіть якщо приймач (це означає PDCP приймача) не вимагає передачі пакета стиснутого заголовка замість передачі пакета повного заголовка, якщо цей RLC SDU (той же як PDCP PDU) видаляється з буфера без будь-якого відхилення (це означає, що передача була успішною), цей PDCP посилає пакети стиснутого заголовка наступного разу. Надалі, навіть якщо приймач (це означає PDCP приймача) не вимагає передачі пакета повного заголовка, якщо будь-який RLC SDU (той же як PDCP PDU) відхиляється (це означає, що передача була невдалою), цей PDCP посилає пакет повного заголовка наступного разу. Фіг.13Б графічно відображає цю особливість кращого варіанту втілення винаходу відповідно до передачі пакета стиснутого та повного заголовка для стиснутого не-ТСР для CSS. Як зазначено на ній, якщо рівень RLC (у цьому випадку передавача) доповідає, що передача пакета повного заголовка була успішною, рівень PDCP (у цьому випадку передавача) не посилає пакет повного заголовка в зазначені інтервали 1, 2, 4, 8 тощо, після отримання доповіді RLC. Однак, якщо рівень RLC доповідає, що передача зазначеного пакета стиснутого заголовка була невдалою, PDCP посилає пакет повного заголовка після отримання доповіді RLC. Фіг.13В відображає параметри, передані між PDCP та RLC для виконання інструкцій стосовно доповідей. Як зазначено, PDCP передає до RLC пакет, ідентифікатор пакету та параметр DiscardReq, що відображає чи має потребу передавальний RLC об'єкт інформувати верхні рівні про відхилені RLC SDU. Якщо вимагається, 82886 26 передавальний RLC об'єкт повідомляє верхні рівні коли SDU відхиляються. Протягом лише роботи в AM, параметр Стан (Status) відображає чи був RLC SDU успішно переданим або відхиленим. Цей винахід особливо добре підходить для використання в домені з комутацією пакетів, що був запропонований TSG-RAN та TSG-CN. Деталізовані варіанти втілення цього винаходу будуть тепер обговорені. Фіг.14 є блок-схемою системи передачі пакетів відповідно до першого варіанту втілення цього винаходу, включаючи блок PDCP та блок RLC. Блок RLC містить модуль розпізнавання помилки передачі 20, модуль передачі 16, та модуль контролю передачі 18. Модуль розпізнавання помилки передачі, краще, забезпечується в рівні RLC та виконує дві функції. Перша функція - це розпізнавання пакета даних з помилкою передачі серед пакетів даних, переданих через буфер. Друга функція - це надсилання інформації зворотного зв'язку до модуля контролю повноти заголовка 12 вздовж шляху зворотного зв'язку 200. Модуль розпізнавання помилки передачі також надсилає інформацію до відкритого рівня протоколу, яка відображає, що мала місце помилка протягом передачі пакетних даних. Елементи, що залишилися в системі, можуть бути схожі на елементи в системі пакетної передачі, що відображена на Фіг.2.пакетної передачі відповідно Робота системи до цього винаходу буде описана далі. Первісно, дані, трансформовані в пакет повного заголовка або пакет стиснутого заголовка в модулі стискування заголовка 10 рівня PDCP, передаються до рівня RLC через модуль передачі даних 14. Рівень RLC зберігає отримані пакетні дані в буфері та/або передає їх до приймальної сторони через модуль передачі, 16 базуючись на контрольній інформації з модуля контролю передачі 18. модуль розпізнавання помилки Тоді ж передачі 20 визначає, чи була передача пакета з рівня RLC до приймальної сторони невдалою, та передає інформацію щодо невдалої передачі (помилки передачі) до модуля контролю повноти заголовка 12 в рівні вздовж шляху 200. Інформація щодо невдалої передачі, найкраще, включає ідентифікаційну ID інформацію відповідного пакета та/або індикатор помилки передачі. Рівень PDCP контролює модуль стискування заголовка 10 на основі інформації щодо невдалої передачі, переданої з рівня RLC. Більш точно, якщо модуль контролю стискування заголовка в рівні PDCP отримує індикатор помилки передачі від модуля 20, що показує, що мала місце невдала передача з рівня RLC, контрольний модуль 12 контролює модуль стискування заголовка 10, щоб стиснути наступний пакет (краще перший наступний пакет), використовуючи той самий CID, як CID пакета, що був невдало переданий, як пакет повного заголовка та передає його до рівня RLC. Цей аспект винаходу можу бути модифікованим багатьма шляхами. У випадку використання техніки стискування заголовка, що модернізує контекст, завдяки тільки використанню пакета повного заголовка, коли пакет повного заголовка серед пакетів, переданих 27 з рівня PDCP до рівня RLC, не передається вдало до приймальної сторони, рівень RLC забезпечує ідентифікаційну ID інформацію та інформацію про помилку передачі відповідного пакета до рівня PDCP. В системі, що передає пакет даних з використанням техніки стискування заголовка TCP, якщо контекст приймальної сторони ушкоджується внаслідок невдалої передачі пакета, рівень стискування заголовка (рівень PDCP) передавальної сторони, передає новий пакет повного заголовка відповідного контексту до приймальної сторони негайно, коли він отримує інформацію щодо невдалої передачі відповідного пакета з нижчого рівня каналу передачі даних (рівень RLC). Відповідно, приймальна сторона може запобігти додатковій втраті пакетів та швидко відновити контекст. У випадку використання техніки стискування "Стиснутий не-ТСР", відповідно до цього винаходу, результат передачі на RLC SDU, переданий з рівня RLC, передається до рівня PDCP, так що рівень PDCP може ефективно контролювати, періодично або неперіодично, повторну передачу пакета повного заголовка. Для цього рівень RLC виконує додаткову функцію інформування результату передачі PDCP PDU (тобто RLC SDU), що надходить з рівня PDCP. Робота рівня RLC тепер буде описана. Рівень RLC, що передає RLC SDU (=PDCP PDU) переданих з рівня PDCP, працює в одному з трьох режимів: прозорий режим, непідтверджений режим та підтверджений режим. RLC рівень працює в прозорому режимі, Коли він передає RLC SDU з рівня PDCP як є, тобто без додавання до них інформації заголовка. Використовувати або ні функцію сегментації, може бути визначено відповідно до установок радіопеленгатора, але навіть у випадку, коли RLC SDU сегментується, не додається інформації заголовка. Коли RLC рівень працює в непідтвердженому режимі, він конструює RLC PDU, використовуючи функцію сегментації та конкатенації для RLC SDU, додає туди інформацію заголовка та передає його до приймальної сторони. Коли RLC рівень працює в прозорому режимі та непідтвердженому режимі, є можливим тільки зв'язок в одному напрямку. Приймальна сторона не передає будь-яку інформацію, що стосується отримання RLC PDU, до передавальної сторони (рівень RLC). Коли RLC рівень працює в непідтвердженому режимі, він сегментує або виконує конкатенацію RLC SDU для формування PDU попередньо визначеного розміру, додає заголовну інформацію RLC, яка містить порядковий номер, та зберігає цей результат в буфері RLC. В підтвердженому режимі зв'язок в двох напрямках між RLC є можливим. В результаті може бути виконана повторна передача пакета, загубленого під час передачі. Також, в підтвердженому режимі передавальна сторона передає RLC PDU в порядку, визначеному порядковим номером передачі. Рівень RLC приймальної сторони розпізнає, які RLC не були вдало прийняті завдяки огляду порядкових номерів RLC PDU, що були прийняті вдало. Після цього приймальна сторона 82886 28 створює PDU стану (статусний PDU), що відображає, які PDU були вдало, а які PDU були невдало передані. PDU, що були прийняті невдало, можуть бути позначені негативної інформацією підтвердження. Після створення PDU стану передається до передавальної сторони, і по прийому PDU стану передавальна сторона може повторно передати невдало передані RLC PDU, тобто ті, що були позначені негативним підтвердженням. Відповідно до цього винаходу, рівень RLC передавальної сторони розпізнає результат передачі специфічного RLC PDU, базуючись на інформації підтвердження/непідтвердження, що включена до PDU стану, переданих з рівня RLC до приймальної сторони. Додатково, внаслідок того, що рівень RLC передавальної сторони може розпізнати відповідний зв'язок між RLC PDU та RLC SDU, рівень RLC цього винаходу може легко розпізнати результат передачі для специфічного RLCТаким чином, коли рівень RLC працює в SDU. непідтвердженому режимі, рівень RLC може інформувати рівень PDCP про результат передачі специфічного RLC SDU, та в результаті рівень PDCP виявить результат передачі пакета повного заголовка, при цьому гарантуючи ефективнішу передачу повного заголовка порівняно зі способами такого роду. Для цього, відповідно до цього винаходу, коли результат передачі специфічного RLC SDU підтверджується рівнем RLC передавальної сторони, рівень RLC передавальної сторони інформує рівень PDCP передавальної сторони про ідентифікаційний номер та результат передачі відповідного RLC SDU. Результат передачі може бути інформацією про вдалу або невдалу передачу. Інформація про вдалу передачу надсилається до рівня PDCP, коли рівень RLC інформується, наприклад, базуючись на PDU стану, що був отриманий, що специфічний RLC SDU був успішно переданий. Інформація про невдалу передачу надсилається до рівня PDCP, наприклад, базуючись на PDU стану, що був отриманий, який відображає що специфічний SDU не був успішно переданий та/або коли рівень RLC відбраковує один або більше RLC SDU, що не передаються протягом тривалогорівень RLC, який є верхнім рівнем Цей часу. відповідно до рівня PDCP, який виконує стискування заголовка, встановлює радіопеленгатор так, що рівень RLC забезпечує рівень PDCP інформацією з RLC про відхилені RLC SDU. Коли рівень PDCP передає PDCP PDU до рівня RLC, він надає вказівку для рівня RLC інформувати рівень PDCP щодо результату невдалої передачі, що стосується відповідного PDCP PDU. Для цього, коли рівень PDCP передає PDCP PDU до рівня RLC, модуль візаві контролю передачі 18 рівня RLC передає індикатор результату передачі з відповідним PDU, так що рівень RLC забезпечує рівень PDCP інформацією стосовно відхилення відповідного PDU, коли це має В рівні PDCP результат передачі повного місце. заголовка може розглядатися як важливіший за результат передачі пакета стиснутого заголовка. Таким чином, навіть якщо рівень RLC скоріше 29 інформує рівень PDCP тільки про результат періодичної або неперіодичної повторної передачі пакета повного заголовка, скоріше за інформування рівня PDCP про результат передачі кожного пакета, цей винахід з великою перевагою досягає того ж самого ефекту, як і тоді, коли б він інформував рівень PDCP про результат передачі кожного пакета. У такому випадку, коли рівень PDCP передає PDCP PDU, що містять пакет повного заголовка, до рівня RLC, рівень PDCP передає індикатор повного заголовка разом з відповідним RLC SDU (=PDCP PDU), та рівень RLC інформує рівень PDCP про результат передачі відповідного RLC SDU. Внаслідок того, що рівень PDCP передавальної сторони виявляє результат періодичної або неперіодичної повторної передачі пакета повного заголовка з рівня RLC на нижчий рівень, він може виконувати різні операції, використовуючи цю інформацію для підвищення ефективності передачі пакета. Якщо пакет повного заголовка успішно передається, рівень PDCP приймальної сторони матиме наявну точну інформацію повного заголовка. В цих обставинах, отже, більше не є необхідним передавати повний заголовок відповідного пакетного потоку, тобто, тільки один пакет повного заголовка передається для усіх пакетів в даному потоці пакетних даних, якщо цей один пакет успішно приймається та передавальна сторона RLC інформується про те саме. Надалі в системі, в якій пакет повного заголовка для специфічного пакетного потоку повторно передається періодично або неперіодично, якщо інформація повного заголовка успішно передається, пакет повного заголовка більше не передається і пакети, що залишилися в потоці, можуть бути передані в формі тільки пакетів стиснутогоперіодична або неперіодична повторна Якщо заголовка. передача пакета повного заголовка була невдалою і кожний пакет повного заголовка, що був попередньо переданий, також був переданий невдало, рівень PDCP передавальної сторони може знов передати пакет повного заголовка для того ж самого пакетного потоку. Більш точно, у випадку, де пакет повного заголовка повторно передається, як періодично так і неперіодично, якщо передача пакета повного заголовка була невдалою і поки ще не було успішно передано пакета повного заголовка, пакет повного заголовка для того ж самого пакетного потоку може бути негайно переданий, скоріше за створення відповідності до попередньо встановленого періоду передачі пакета повного заголовка. Альтернативно, передача пакета повного заголовка може бути виконана відповідно до попередньо встановленого періоду або техніка CSS може бути повторно запущена. Коли з нижчого рівня RLC приймається повідомлення, яке відображає, що принаймні один пакет повного заголовка був успішно переданий, в той час як рівень PDCP передавальної сторони передає пакет повного заголовка та пакети стиснутого заголовка (пакети стиснутих заголовків), цей пакет 82886 30 повного заголовка для відповідного пакетного потоку більше не передається, і тільки пакет стиснутого заголовка передається надалі. Рівень PDCP передавальної сторони переважно перевіряє, чи був успішно прийнятий пакет повного заголовка, коли для нього підходить час передавати повний заголовок, в той час як дані передаються періодично або неперіодично з використанням техніки CSS. По перевірці, якщо принаймні один пакет повного заголовка був успішно переданий, рівень PDCP передавальної сторони не передає інший пакет повного заголовка для відповідного пакетного потоку. Замість цього, після прийому підтвердження, що пакет повного заголовка був успішно переданий з рівня RLC передавальної сторони, рівень PDCP передає пакети, що залишилися в потоці, як пакети стиснутого заголовка, не використовуючи лічильник спосіб або INT. Цей як CNT цього винаходу для передачі пакетів в системі зв'язку буде тепер обговорений. Відповідно до цього винаходу, пакети стиснутого заголовка, які передаються завдяки цьому способу, можуть включати в себе будь-яку інформацію стиснутого заголовка TCP, інформацію стиснутого заголовка з неприпустимою помилкою TCP (compressed TCP nondelta header information), та інформацію стиснутого заголовка не-ТСР. Переважно, пакети стиснутого заголовка відповідають типам пакетів стикування заголовка RFC 2507, тобто тим, що сумісні з протоколом стискування заголовка RFC 2507. Кваліфіковані в цій галузі фахівці, однак, можуть оцінити те, що пакетні дані, передані згідно з цим винаходом, можуть бути генеровані з використанням інших протоколів стискування заголовка, якщо є необхідним. Фіг.15 є блоксхемою, що відображає кроки, включені до одного варіанту втілення цього способу передачі пакетів, що містять повні та стиснуті заголовки відповідно до цього винаходу. В той же час, необхідно відмітити, що значення INT може бути встановлено на первісній стадії як "1". Коли розпочинається передача пакета, спосіб починає, завдяки тому, що має рівень RLC, передавати пакет повного заголовка до приймача (S90). Параметр CNT, що відображає поточне рахування кількості переданих пакетів стиснутого заголовка потім ініціалізується з показником "0" (CNT="0" (S91). Рівень RLC, потім передає пакет стиснутого заголовка (S92) та значення CNT збільшується на "1"(CNT = CNT + 1)(S93). Наступним кроком рівень RLC перевіряє, чи є однаковими показники CNT та INT (S94). Якщо показники є різними, повторно виконуються кроки S92-S94. Якщо показники є однаковими, рівень RLC перевіряє, чи є показник INT більшим за показник MaxINT, який переважно відповідає попередньо встановленому граничному обсягу, що визначає максимальну кількість пакетів стиснутого заголовка, що можуть бути передані до того, як наступний пакет повного заголовка повинен бути розглянутий з метою передачі. Якщо показник INT меншим за показник MaxINT, рівень RLC визначає чи був успішно переданим пакет повного заголовка (S96). Визначення може бути виконано, базуючись на, 31 наприклад, інформації, що знаходиться в PDU стану, переданого з приймача. Якщо визначається, що пакет повного заголовка був успішно прийнятим, рівень RLC припиняє операцію підрахунку пакетів стиснутого заголовка (S99) та пакети, що залишилися в потоці даних, передаються як пакети стиснутого заголовка (S 100 та S101). Якщо визначається, що передача пакета повного заголовка була невдалою в кроці S96, рівень RLC послідовно виконує кроки S90-S97, в той же час збільшуючи значення INT завдяки експоненціальному множенню на "2" (тобто 1, 2, 4, 8, 16,..., 256). (Дивись крок S97). Протягом цих ітерацій, навіть якщо значення INT стає більшим за показник MaxINT в кроці S95, визначається, чи була успішною передача пакета повного заголовка (S98). Якщо передача пакета повного заголовка була невдалою, виконується операція після кроку S90 передачі пакета повного заголовка. Але якщо передача пакета повного заголовка була вдалою, виконуються кроки S99-S101, тобто усі пакети, що залишились в потоці даних передаються як пакети стиснутого заголовка. Слід зазначити, що варіанти втілення цього винаходу були прийняті в 3GPP Технічних специфікаціях TS 25.322v4.2.0, що мають назву "RLC Protocol Specification" та TS 25.323v4.2.0, що мають назву "PDCP Protocol Specification". TS 25.323v4.3.0, TS 25.323v4.5.0 та TS 25.323v5.1.0 разом з усіма додатками та модифікаціями, зміст яких впроваджений тут завдяки посиланням. Ці характеристики винаходу можуть бути виражені, як описано далі: Управління Передачею Повного заголовка Передача пакета повного заголовка може контролюватись інформацією нижчого рівня. Для потоку TCP, якщо PDCP отримує з нижчого рівня інформацію про невдалу передачу поодинокого пакета, PDCP може надіслати наступний пакет як повний заголовок. Для потоку не-ТСР, якщо PDCP отримує з нижчого рівня інформацію про вдалу передачу пакета повного заголовка, PDCP може припинити посилання пакета повного заголовка, що містить такий же самий повний заголовок як попередньо переданий пакет. Спосіб стискування та передачі пакетних даних цього винаходу має принаймні наступні додаткові переваги. В системі, що передає пакети, використовуючи техніку стискування "Стиснутий TCP", якщо контекст приймальної сторони ушкоджується завдяки невдалій передачі довільного пакета, новий пакет повного заголовка відповідного контексту передається до приймальної сторони негайно коли рівень стискування заголовка (рівень PDCP) передавальної сторони отримує інформацію про невдалу передачу відповідного пакета з нижчого рівня каналу передачі даних. Таким чином, можливо запобігти додатковій втраті пакетів та контекст може бути відновлений швидко. Цей підхід може бути знов встановленим у такій спосіб. В RFC 2507, декомпресор (роздільник даних) може використовувати техніку Заголовних Запитів (Header Requests) для відновлення пошкодженого контексту. Але відновити контекст 82886 32 займає багато часу; декомпресор виявляє і пошкоджений контекст чекає доки декілька пошкоджених контекстів виявляються, після цього створює пакет CONTEXSTATE (СТАН_КОНТЕКСТУ), що містить їх показники CID, та надсилає його до компресора. Базуючись на отриманому пакеті CONTEXSTATE, компресор знає, який контекст є ушкодженим, та передає пакет повного заголовка для кожного ушкодженого показника CID. Під час відновлення контексту усі стиснуті пакети показників CID будуть відбраковані в декомпресорі. Швидке відновлення пошкодженого контексту є дуже важливим для швидкої пропускної здатності. Якщо підхід розглядає характеристики RLC, він може відновити контекст значно швидше за техніку Заголовного Запиту. Відповідно до цього винаходу, коли RLC SDU відбраковуються, цей RLC Tx відображає інформацію відбракування до верхнього рівня (PDCP). Використовуючи цю інформацію, PDCP може знати, який контекст є пошкодженим (тобто котрий RLC SDU відбраковується), та передає наступний пакет, значно покращуючи пропускну здатність. Пошкоджений контекст швидко виявляється, і завдяки негайному надсиланню пакета повного заголовка запобігають подальшій втраті пакетів (завдяки невдалій розпаковці). Стисло, проста індикація пошкоджених SDU може значно збільшити перепускну здатність. В системі, що передає пакет, використовуючи техніку стискування "Стиснутий не-ТСР", коли пакет повного заголовка передається відповідно до правила, якщо пакет повного заголовка успішно передається для одного потоку даних, цей пакет повного заголовка більше не передається, і тільки пакет стиснутого заголовка передається. Таким чином, ефективність передачі цього пакета може бути збільшена. Цей підхід може бути знов встановленим у такій спосіб. Коли контекст пошкоджується відбракуванням пакета повного заголовка, що змінив контекст, Стискування з уповільненням та техніка Періодичного Оновлення Заголовка може бути використана для відновлення пошкодженого контексту. Ці техніки надсилають періодично "ті ж самі" повні заголовки, щоб гарантувати, що повний заголовок вдало приймається Приймачем. Це означає, що навіть якщо повний заголовок успішно (вдало) надсилається, ті ж самі повні заголовки (тобто октети 32-48) все ще періодично надсилаються. Ці техніки є добрими для симплексного каналу, - тому що компресор не знає чи була передача повного заголовка успішною або ні. Таким чином, вони також є добрими для TM та UM RLC. Але якщо використовувати AM RLC, можливо надалі покращити ефективність не надсилаючи успішно прийнятий повний заголовок. В AM RLC є доповіді про стан з Приймача, який інформує Відправника про вдалу або невдалу передачу кожного RLC SDU (більш точно стан /статус/ кожного RLC PDU). Якщо RLC SDU вдало передається, цей Відправник доповідає це до вищого рівня завдяки MUI (Message Unit Identifier 33 або Ідентифікатор одиниці повідомлення). Відповідно до цього винаходу, коли пакет повного заголовка вдало передається, в Компресорі зупиняються техніки Стискування з уповільненням та техніка Періодичного Оновлення Заголовка. Посилання такого ж заголовка, що був вже вдало переданий є тільки надмірним витрачанням радіоресурсу, і цього треба уникнути для покращення перепускної здатності. Цей винахід є здатним значною мірою покращити ефективність передачі через техніку стискування заголовка. Далі слід звернути увагу, що цей винахід не обмежується тільки системою УМТС. але також може бути використаний для будь-якої комунікаційної системи пакетних даних. 82886 34 Вищезазначені варіанти втілення та переваги є тільки ілюстративними та не повинні тлумачитися як такі, що обмежують цей винахід. Ця інструкція може бути без труднощів використана для інших типів апаратури. Опис цього винаходу є ілюстративним та не обмежує сферу формули винаходу. Опис цього винаходу призначений бути ілюстративним та не обмежувати можливості Формули винаходу. Багато альтернативних варіантів, модифікацій та змін будуть очевидними для кваліфікованих фахівців. У Формулі винаходу, пункти значенняплюс-функції (means-plus-function) призначені для висвітлення описаної тут структури як такої, що виконує наведену функцію, і не лише структурних еквівалентів, але й еквівалентних структур. 35 82886 36 37 82886 38 39 82886 40 41 82886 42 43 82886 44 45 82886 46 47 Комп’ютерна верстка О. Рябко 82886 Підписне 48 Тираж 26 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601