Підтримка передачі обслуговування для мереж, що мають різні протоколи встановлення каналу зв’язку

1. Спосіб передачі обслуговування мобільного вузла від обслуговуючого вузла у цільовий вузол у системі зв'язку, який містить етапи, на яких: здійснюють доступ до згаданого обслуговуючого вузла за допомогою першого протоколу рівня мережного інтерфейсу; приймають вказівку на згадану передачу обслуговування; і здійснюють доступ до згаданого цільового вузла за допомогою другого протоколу рівня мережного інтерфейсу; при цьому етап здійснення доступу включає в себе етап, на якому мобільний вузол відправляє набір варіантів параметрів для аутентифікації, конфігурації каналу зв'язку і доступу до мережі в одному повідомленні запиту. 2. Спосіб за п. 1, в якому етап прийому вказівки включає в себе прийом повідомлення, що має ідентифікацію, що ідентифікує згаданий цільовий вузол. 3. Спосіб за п. 1, в якому етап прийому вказівки включає в себе прийом пакета даних, що має ідентифікацію повідомлення у полі даних пакета даних, що ідентифікує цільовий вузол. 4. Спосіб за п. 1, в якому етап прийому вказівки включає в себе прийом пакета даних, що має пакет ідентифікації версії/пропускної здатності у полі 2 (19) 1 3 включеної у поле даних пакета даних, що ідентифікує другий вузол. 12. Спосіб за п. 8, в якому етап прийому вказівки включає в себе прийом множини повідомлень запиту на конфігурування LCP (протокол керування каналом) згаданого РРР з другого вузла. 13. Пристрій для підтримки передачі обслуговування для мереж, що мають різні протоколи встановлення каналу зв'язку в системі зв'язку, що містить: засіб для здійснення доступу до обслуговуючого вузла в системі зв'язку за допомогою першого протоколу рівня мережного інтерфейсу; засіб для прийому вказівки на передачу обслуговування; і засіб для здійснення доступу до цільового вузла за допомогою другого протоколу рівня мережного інтерфейсу; при цьому здійснення доступу включає в себе відправлення пристроєм набору варіантів параметрів для аутентифікації, конфігурації каналу зв'язку і доступу до мережі в одному повідомленні запиту. 14. Пристрій за п. 13, в якому вказівка включає в себе ідентифікацію у повідомленні, що ідентифікує цільовий вузол. 15. Пристрій за п. 13, в якому вказівка включає в себе ідентифікацію повідомлення у полі даних пакета даних, що ідентифікує цільовий вузол. 16. Пристрій за п. 13, в якому вказівка включає в себе пакет ідентифікації версії/пропускної здатності у полі даних пакета даних, що ідентифікує цільовий вузол. 17. Пристрій за п. 13, в якому вказівка включає в себе множину повідомлень запиту другого протоколу рівня мережного інтерфейсу з цільового вузла. 18. Пристрій для підтримки передачі обслуговування для мереж, що мають різні протоколи встановлення каналу зв'язку в системі зв'язку, який підтримує IP (протокол Інтернет), що містить: засіб для здійснення доступу до першого вузла за допомогою протоколу рівня мережного інтерфейсу, відмінного від РРР (протокол каналу зв'язку з безпосереднім з'єднанням); засіб для прийому вказівки на передачу обслуговування; і засіб для здійснення доступу до другого вузла за допомогою згаданого РРР; при цьому здійснення доступу включає в себе відправлення пристроєм набору варіантів параметрів для аутентифікації, конфігурації каналу зв'язку і доступу до мережі в одному повідомленні запиту. 19. Пристрій за п. 18, в якому вказівка включає в себе повідомлення, що має ідентифікацію повідомлення, що ідентифікує другий вузол, причому ідентифікацію повідомлення вибирають з групи, що складається з NID (ідентифікація мережі), SID (системна ідентифікація), PZID (ідентифікація зони пакета) і ІД підмережі (ідентифікація підмережі), асоційованих з другим вузлом. 20. Пристрій за п. 18, в якому вказівка включає в себе пакет даних, що має код або ідентифікатор, включений у поле даних пакета даних, що ідентифікує другий вузол. 91519 4 21. Пристрій за п. 18, в якому вказівка включає в себе пакет даних, що має пакет ідентифікації версії/пропускної здатності, включений у поле даних пакета даних, що ідентифікує другий вузол. 22. Пристрій за п. 18, в якому вказівка включає в себе множину повідомлень запиту на конфігурування LCP (протокол керування каналом) згаданого РРР з другого вузла. 23. Пристрій для підтримки передачі обслуговування для мереж, що мають різні протоколи встановлення каналу зв'язку в системі зв'язку, що містить: модуль пам'яті, який включає в себе інструкції, зчитувані комп'ютером, призначені для здійснення доступу до обслуговуючого вузла системи зв'язку за допомогою першого протоколу рівня мережного інтерфейсу, прийому вказівки на передачу обслуговування і здійснення доступу до цільового вузла системи зв'язку за допомогою другого протоколу рівня мережного інтерфейсу; і схему процесора, з'єднану з модулем пам'яті для обробки інструкцій, що зчитуються комп'ютером; при цьому здійснення доступу включає в себе відправлення пристроєм набору варіантів параметрів для аутентифікації, конфігурації каналу зв'язку і доступу до мережі в одному повідомленні запиту. 24. Пристрій за п. 23, в якому вказівка включає в себе повідомлення, що має ідентифікацію, що ідентифікує цільовий вузол. 25. Пристрій за п. 23, в якому вказівка включає в себе пакет даних, що має ідентифікацію повідомлення у полі даних пакета даних, що ідентифікує цільовий вузол. 26. Пристрій за п. 23, в якому вказівка включає в себе пакет даних, що має пакет ідентифікації версії/пропускної здатності у полі даних пакета даних, що ідентифікує згаданий цільовий вузол. 27. Пристрій за п. 23, в якому вказівка включає в себе множину повідомлень запиту другого протоколу рівня мережного інтерфейсу з цільового вузла. 28. Пристрій за п. 23, в якому модуль пам'яті додатково включає в себе інструкції, зчитувані комп'ютером, для обміну даними користувача з обслуговуючим вузлом після здійснення доступу до обслуговуючого вузла і початку передачі обслуговування при прийомі згаданої вказівки під час обміну даними користувача. 29. Пристрій за п. 23, в якому модуль пам'яті додатково включає в себе зчитувані комп'ютером інструкції, призначені для початку передачі обслуговування, тоді як вказівку приймають під час доступу до обслуговуючого вузла за допомогою першого протоколу рівня мережного інтерфейсу. 30. Пристрій за п. 23, в якому модуль пам'яті додатково включає в себе зчитувані комп'ютером інструкції, що надають набір варіантів вибору параметра, для аутентифікації, конфігурування каналу зв'язку і доступу до мережі, у повідомленні, протягом здійснення доступу до обслуговуючого вузла. 31. Пристрій для підтримки передачі обслуговування для мереж, що мають різні протоколи встановлення каналу зв'язку в системі зв'язку, який підтримує IP (протокол Інтернет), що містить: 5 91519 6 модуль пам'яті, що включає в себе зчитувані комп'ютером інструкції, призначені для здійснення доступу до першого вузла за допомогою протоколу рівня мережного інтерфейсу, відмінного від РРР (протокол каналу зв'язку з безпосереднім з'єднанням), прийому вказівки на передачу обслуговування і здійснення доступу до другого вузла за допомогою згаданого РРР; і схему процесора, з'єднану з модулем пам'яті, для обробки інструкцій, що зчитуються комп'ютером; при цьому здійснення доступу включає в себе відправлення пристроєм набору варіантів параметрів для аутентифікації, конфігурації каналу зв'язку і доступу до мережі в одному повідомленні запиту. 32. Пристрій за п. 31, в якому модуль пам'яті додатково включає в себе зчитувані комп'ютером інструкції, призначені для надання другому вузлу набору варіантів вибору параметра для аутентифікації, конфігурування каналу зв'язку і доступу до мережі, в повідомленні запиту, протягом здійснення доступу. 33. Пристрій за п. 31, в якому вказівка включає в себе повідомлення, що має ідентифікацію повідомлення, що ідентифікує другий вузол, причому ідентифікацію повідомлення вибирають з групи, що складається з NID (ідентифікація мережі), SID (системна ідентифікація), PZID (ідентифікація зони пакета) і ІД підмережі (ідентифікація підмережі), асоційованих з другим вузлом. 34. Пристрій за п. 31, в якому вказівка включає в себе пакет даних, що має код або ідентифікатор, включений у поле даних пакета даних, що ідентифікує другий вузол. 35. Пристрій за п. 31, в якому вказівка включає в себе пакет даних, що має пакет ідентифікації версії/пропускної здатності, включений у поле даних пакета даних, що ідентифікує другий вузол. 36. Пристрій за п. 31, в якому вказівка включає в себе множину повідомлень запиту на конфігурування LCP (протокол керування каналом) згаданого РРР з другого вузла. У даній заявці на патент вимагається пріоритет відповідно до попередньої заявки США № 60/614215 під назвою "A Method and Apparatus for Handoff Support Fast Link Establishment Protocol", поданої 28 вересня 2004 p., права на яку належать заявнику даної заявки, і спеціально наведеної тут як посилальний матеріал. Галузь техніки, якої стосується винахід Даний винахід, загалом, стосується пакетної передачі даних і, більш конкретно, підтримки передачі обслуговування для мереж з різними протоколами встановлення каналу зв'язку, виконання якої часто потрібне перед якою-небудь пакетною передачею даних по мережах. Опис попереднього рівня техніки Глобальне взаємне з'єднання мереж дозволяє забезпечити швидкий доступ до інформації, незалежно від географічних відстаней. На фіг. 1 показана спрощена схема глобального з'єднання мереж, що звичайно називають мережею Інтернет, позначеною посилальною позицією 20. Інтернет 20, по суті, являє собою множину мереж з різними рівнями ієрархії, з'єднаних разом. Інтернет 20 працює відповідно до IP (протокол Інтернет), який був опублікований IETF (Цільова група інженерної підтримки Інтернет). Докладний опис протоколу IP можна знайти в RFC (Запит коментарю) 791, опублікованому IETF. До мережі Інтернет 20 підключені різні окремі мережі, які іноді називають ЛОМ (локальні обчислювальні мережі, LAN) або ГОМ (глобальні обчислювальні мережі, WAN) в залежності від розмірів мережі. На фіг. 1 показані деякі з таких мереж 22, 24, 26 і 28. У межах кожної з мереж 22, 24, 26 і 28 можуть бути підключені різні частини обладнання, з'єднані і зв'язані одна з одною. Приклади такого обладнання являють собою комп'ютери, принтери і сервери, крім іншого, які звичайно називаються вузлами. Коли вузол при обміні даними виходить за межі власної мережі через Інтернет 20, цьому вузлу повинна бути призначена IP адреса. Призначення IP адреси може виконуватися вручну або автоматично. Призначення IP адреси вручну може бути виконане, наприклад, мережним адміністратором. Більш часто, IP адресу призначають автоматично, наприклад, за допомогою виділеного сервера у ЛОМ або ГОМ. Розглянемо приклад для ілюстрації. Припустимо, вузол 30 у мережі 22 намагається передати пакет даних в інший вузол 37 у мережі 24. Відповідно до протоколу IP, кожний пакет даних повинен мати адресу джерела і адресу призначення. У цьому випадку адреса джерела являє собою адресу вузла 30 у мережі 22. Адреса призначення являє собою адресу вузла 37 у мережі 24. Часто потрібно забезпечити безпосередній зв'язок між вузлами раніше, ніж буде одержаний доступ до мережі, наприклад, при доступі до інших мереж через Інтернет 20. Розглянемо для ілюстрації ще один приклад. Припустимо, що вузол 30 мережі 22 являє собою переносний комп'ютер. Вузол 30 - переносний комп'ютер не має прямого доступу до мережі 22. Однак вузол 30 - переносний комп'ютер може одержати доступ до NAS (СДМ, сервер доступу до мережі) 32 мережі 22 через деякі інші засоби, наприклад, шляхом додзвонювання через провідний модем по телефонній лінії. У цьому випадку вузол 30 звичайно встановлює сеанс РРР (ПБЗ, протокол каналу зв'язку з безпосереднім з'єднанням) з NAS (сервер доступу до мережі) 32 мережі 22. Пакетна передача даних, встановлена після цього між вузлом 30 і мережею 22, або будь-якими іншими мережами через Інтернет 20, буде проведена через провідний модем і телефонну лінію. Якщо модем передає і приймає сигнали послідовно і асинхронно через телефонну лінію, пакети даних, обмін якими виконується по телефонній лінії, також повинні бути відповідно 7 розбиті на фрейми, для відповідності послідовному і асинхронному модемному каналу зв'язку. Досягнення у технологіях безпровідного зв'язку дозволяють вузлам переміщуватися з мереж їх початкової реєстрації в інші мережі. Наприклад, розглянемо знову фіг. 1, де вузол 30 замість постійного підключення по кабелю до мережі 22 може являти собою безпровідний пристрій, такий як КПК (PDA) (кишеньковий персональний комп'ютер), стільниковий телефон або мобільний комп'ютер. Безпровідний вузол 30 може переміщуватися за межі границі його власної мережі 22. Таким чином, вузол 30 може віддалятися від власної мережі 22 у чужу мережу 28. Для забезпечення доступу до мережі 28 або для підключення до інших мереж через Інтернет 20 вузол 30 також звичайно встановлює сеанс РРР з NAS 33 мережі 28. Обмін даних між вузлом 30 і NAS 33 у цьому випадку виконується через безпровідний канал зв'язку. І знову, пакети даних, обмін якими виконується через безпровідний канал зв'язку, також повинні бути розділені на фрейми для відповідності формату, узгодженому під час сеансу РРР між вузлом 30 і ΝΑS 33. Основна частина РРР описана в RFC 1661 і 1662, опублікованих IETF. РРР, по суті, являє собою сеанс перевірки і узгодження між вузлами, причому під час цього сеансу вузли визначають ресурси один одного у значенні пропускної здатності і доступності і, у результаті, узгоджують набір взаємоприйнятних параметрів до передачі мережного трафіку. Оскільки сеанс РРР часто повинен бути встановлений до одержання доступу до мережі, РРР іноді називають "протоколом рівня мережного інтерфейсу". Однак також звичайно використовують інші аналогічні терміни, включаючи "протокол встановлення каналу зв'язку" і "протокол рівня 2". Нижче терміни "протокол рівня мережного інтерфейсу", "протокол встановлення каналу зв'язку" і "протокол рівня 2" використовуються взаємозамінно. На фіг. 2 показана схема послідовності операцій прикладу сеансу 34 передачі даних РРР, в якому вузол 30 у мережі 28 намагається встановити канал зв'язку з NAS 33 для одержання доступу до Інтернет 20. РРР має множину компонентів протоколу. У прикладі сеансу РРР, показаному на фіг. 2, РРР має LCP (ПКК, протокол керування каналом) 36, CHAP (ПАУВ, протокол аутентифікації з попереднім узгодженням виклику) 38 і ІРСР (КППІ, керуючий протокол для протоколу Інтернет) 40 як компоненти. Спочатку, після встановлення фізичного каналу зв'язку, тобто, наприклад, коли вузол 30 і NAS 33 можуть одержати доступ один до одного на рівні апаратних засобів, існує потреба пройти через LCP 36. LCP 36 призначений для встановлення основного каналу зв'язку між вузлом 30 і NAS 33. Під час LCP 36, вузол 30 і NAS 33 виконують обмін і узгодження істотних параметрів зв'язку один з одним. Варіанти вибору можуть включати в себе максимальний розмір пакету даних, що передається через канал зв'язку, параметри, що стосуються керування якістю, що використовується 91519 8 схемою стиснення поля заголовка HDLC (ВККП, високорівневе керування каналом передачі даних), і чи згодний рівнозначний вузол пройти аутентифікацію. Процеси LCP 36 у більшій або меншій мірі виконуються відповідно до етикету встановлення з'єднання. Спочатку запитуюча сторона пропонує один або більше параметрів, передаючи повідомлення-запит конфігурації. Якщо який-небудь з параметрів не розпізнається приймаючою стороною, приймаюча сторона відповідає повідомленням відхилення конфігурації. Якщо відхилений параметр є фатальним для необхідного каналу зв'язку, запитуюча сторона потім повинна припинити сеанс РРР. З іншого боку, якщо параметр розпізнається, але варіант вибору, пов'язаний з параметром, не є прийнятним, відповідаюча сторона передає назад повідомлення Configure Nak (конфігурація не підтверджена). Запитуюча сторона знову може або припинити сеанс РРР, або передати інше повідомлення запиту конфігурації з іншим варіантом вибору для того ж параметра. Всі параметри з відповідними варіантами вибору повинні бути узгоджені і встановлені так, як описано вище. Може бути потрібно декілька циклів узгодження, як показано на фіг. 2. Якщо запитуюча сторона визначає, що всі необхідні параметри є прийнятними для відповідаючої сторони, запитуюча сторона передає кінцеве повідомлення Configure Ack (підтвердження конфігурації) приймаючій стороні. Після того, як обидві сторони передадуть повідомлення підтвердження конфігурації, вони потім переходять до фази аутентифікації. Для засвідчення того, що обидві сторони є авторизованими, повинна бути виконана аутентифікація. Один зі способів виконання аутентифікації полягає у використанні компонента РРР CHAP 38. Звичайно NAS 33 ініціалізує CHAP 38 для перевірки ідентичності вузла 30. Під час CHAP 38 NAS 33 передає повідомлення, що називається повідомленням-запитом, у вузол 30. Відповідно до CHAP, існує загальний секрет, який використовується разом з повідомленням-запитом для розрахунку повідомлення-відповіді з використанням заздалегідь узгодженого алгоритму, Вузол 30 потім передає повідомлення-відповідь, генероване з використанням секретного алгоритму, у NAS 33. NAS 33 після цього порівнює прийняте повідомленнявідповідь з повідомленням, розрахованим самим NAS 33. Якщо буде визначена відповідність при порівнянні, кажуть, що вузол 30 пройшов CHAP 38, при цьому NAS 33 передає повідомлення CHAP Success (CHAP успішно пройдений) у вузол ЗО. В іншому випадку повідомлення CHAP Failure (CHAP не пройдений) буде передане NAS 33. Як альтернатива, замість CHAP 38 аутентифікація може бути виконана шляхом проходження через РАР (ПАП, протокол аутентифікації паролю). При використанні РАР вузол 30 просто передає у NAS 33 ім'я користувача і пароль для перевірки. У випадку успішної перевірки кажуть, що вузол 30 пройшов РАР. Якщо вузлу 30 потрібний доступ до IP, знову потрібно зробити обмін і узгодження інформації, 9 що стосується IP. Наприклад, крім іншого, може бути потрібно призначити вузлу 30 IP адресу для доступу до Інтернет 20 (фіг. 1) відповідно до IP. З цією метою починається узгодження і обмін варіантами вибору параметрів відповідно до ІРСР 40. У прикладі сеансу 34 РРР вузол 30 спочатку запитує IP адресу 0.0.0.0 у NAS 33. У відповідь NAS 33 передає повідомлення Configure Nak (не підтвердження конфігурації), що передбачає, що вузол 30 використовує IP адресу a.b.c.d. У випадку прийому вузол 30 підтверджує використання IP адреси a.b.c.d, передаючи у NAS 33 інше повідомлення для підтвердження. Нарешті, коли вузол 30 погоджується з усіма параметрами, узгодженими протягом ІРСР 40, вузол 30 передає повідомлення-підтвердження у NAS 33. Після цього виконують обмін даними користувача у ході сеансу доступу до мережі. Пакети даних IP мережного трафіка інкапсулюють у фрейми РРР з параметрами, узгодженими раніше під час LCP 36. У кінці доступу до мережі вузол 30 або NAS 33 можуть передати один одному повідомлення-запит на припинення зв'язку, після чого буде передана відповідь з повідомленням підтвердження припинення зв'язку, і сеанс зв'язку на цьому закінчується. Як можна бачити на фіг. 2 і як описано вище, між вузлом 30 і NAS 33 під час сеансу 34 РРР потрібно зробити обмін досить великою кількістю повідомлень. На це йде значний період часу. Особливо це справедливо у випадку, коли сеанс 34 РРР узгоджують по повільному каналу передачі даних з великою затримкою при передачі даних. Для прискорення процесу первинного встановлення каналу зв'язку між вузлом 30 і NAS 33 були запропоновані різні протоколи, крім РРР. Приклад таких протоколів описаний у заявці № 11/193068 на патент США під назвою "Fast Link Establishment for Network Access", поданій 28 липня 2005 p. (далі заявка на патент " ’068"). Заявка на патент ’068, права на яку належать заявнику даної заявки, спеціально наведена тут повністю як посилальний матеріал. Нижче будь-який протокол встановлення каналу зв'язку, який не є протоколом РРР, називається не-РРР. Однак у системі зв'язку, в якій деякі мережі підтримують не-РРР, у той час як інші не підтримують такий протокол, виникають проблеми. Ці проблеми можуть бути додатково ускладнені, коли мобільні вузли переміщаються по різних мережах з різними протоколами встановлення каналу зв'язку. Для ілюстрації розглянемо інший приклад. Розглянемо знову фіг. 1. Припустимо, що вузол 30 після переміщення у мережу 28 встановлює канал зв'язку з NAS 33 через сеанс не-РРР. Після цього виконується обмін даними користувача між вузлом 30 і NAS 33. Крім того, припустимо, що у ході передачі даних користувача вузол 30 переміщується в іншу мережу, таку як мережа 26. Якщо мережа 26 аналогічна мережі 28 у будь-якому аспекті, відносно фізичного втілення і протоколу, включаючи в себе втілення протоколу рівня мережного інтерфейсу, може бути розроблена спрощена схема 91519 10 передачі обслуговування. Після переходу на територію мережі 26, мережа 28 може передати обов'язки з обробки даних у мережу 26, яка потім приймає на себе функції пакетного обміну даними, що раніше виконувалися мережею 28. Однак мережі 28 і 26 часто мають різні втілення відносно апаратних засобів і рівня каналу зв'язку. Наприклад, припустимо, що мережа 28 підтримує не тільки РРР, але також і інший не-РРР як протоколи рівня мережного інтерфейсу. З іншого боку, мережа 26 підтримує тільки РРР як протокол рівня мережного інтерфейсу і не підтримує інші протоколи. Після переміщення у мережу 26 з мережі 28 і для продовження доступу до мережі вузол 30 повинен спочатку встановити інший сеанс протоколу рівня мережного інтерфейсу з NAS 35 у мережі 26 так, щоб обмін пакетними даними, встановлений після цього, відповідав фізичному каналу зв'язку, встановленому між вузлом 30 і NAS 35 у мережі 26. Якщо вузол 30 не адаптований до запуску без перерви звичайного РРР, необхідного у мережі 26, вузол 30 буде повністю відключений від мережного доступу. Відповідно до цього, існує потреба у забезпеченні надійного процесу передачі обслуговування для вузлів, що переміщуються, для яких потрібно забезпечити мережний доступ у різних мережах, що підтримують різні протоколи рівня мережного інтерфейсу. СУТЬ ВИНАХОДУ У системі зв'язку з множиною мереж вузол, якому потрібно забезпечити доступ до мережі у системі передачі даних, повинен пройти через процес передачі обслуговування при переміщенні з однієї мережі в іншу. Особливі проблеми виникають, коли різні мережі виконані з використанням різних протоколів рівня мережного інтерфейсу. Відповідно до зразкового варіанту виконання винаходу встановлюють схеми передачі обслуговування, використовуючи які вузол може переміщуватися з однієї мережі в іншу з меншою кількістю перерв доступу до мережі. Перед передачею обслуговування вузол приймає вказівку на передачу обслуговування. Ця вказівка може приймати форму зміни SID (СІД, системна ідентифікація), NID (ІДМ, ідентифікація мережі), або PZID (ІДЗП, ідентифікація зони пакету), або їх комбінації. Як альтернатива, вказівка може бути безпосередньо включена у пакет даних, що передається у вузол під час передачі обслуговування. Як інша альтернатива, вказівка може бути виконана у формі структур повідомлення, що передаються у вузол, в якому інші структури повідомлення передають з використанням інших мереж, що підтримують інші протоколи рівня мережного інтерфейсу. Відповідно до одного аспекту винаходу, розкритий спосіб, в якому вузол, для якого потрібно встановити доступ до мережі, проходить через пристрій, який включає в себе етапи встановлення першого протоколу рівня мережного інтерфейсу з обслуговуючим вузлом, прийому вказівки на передачу обслуговування і встановлення другого протоколу рівня мережного інтерфейсу з цільовим вузлом. 11 Відповідно до іншого аспекту винаходу розкритий пристрій, втілений з використанням апаратних засобів, для виконання етапів згаданого вище розкритого способу. Відповідно до ще одного аспекту винаходу розкритий носій інформації, що зчитується комп'ютером, на якому містяться інструкції, що зчитуються комп'ютером для виконання етапів згаданого вище розкритого способу. Ці та інші властивості і переваги будуть очевидні для фахівця у даній галузі техніки з наведеного нижче докладного опису, який потрібно розглядати разом з доданими кресленнями, на яких однаковими посилальними позиціями позначені однакові частини. Короткий опис креслень На фіг. 1 показана схема глобального з'єднання мереж; на фіг. 2 показана схема послідовності зв'язку або сеансу зв'язку для звичайного протоколу рівня мережного інтерфейсу; на фіг. 3 показана схема вузлів і мереж, що використовується у загальному варіанті виконання винаходу; на фіг. 4 показана схема вузлів і мереж, що використовується у зразковому варіанті виконання винаходу, в якому підтримуються безпровідні технології; на фіг. 5 показана схема, що представляє стек протоколів в ієрархічному порядку; на фіг. 6 показана схема послідовності зв'язку сеансу зв'язку для зразкового протоколу рівня мережного інтерфейсу, який відрізняється від звичайного протоколу рівня мережного інтерфейсу, показаного на фіг. 2; на фіг. 7 показана схема послідовності зв'язку, що представляє етапи, які використовуються відповідно до першої схеми передачі обслуговування, що використовується у зразковому варіанті виконання винаходу; на фіг. 8 показана блок-схема послідовності операцій схеми передачі обслуговування для схеми послідовності зв'язку, показаної на фіг. 7; на фіг. 9 показана схема послідовності зв'язку, що представляє етапи, які використовуються відповідно до другої схеми передачі обслуговування, що використовується у зразковому варіанті виконання винаходу; на фіг. 10 показана схема формату фрейму даних, що використовується у протоколах рівня мережного інтерфейсу за фіг. 2 і 6; на фіг 11 показана блок-схема послідовності операцій схеми передачі обслуговування у схемі послідовності зв'язку, поданій на фіг. 9; на фіг. 11А показана блок-схема послідовності операцій варіанту схеми передачі обслуговування для схеми послідовності зв'язку, показаної на фіг. 7; на фіг. 12 показана схема послідовності зв'язку, що представляє етапи, які використовуються відповідно до третьої схеми передачі обслуговування, що використовується у зразковому варіанті виконання винаходу; 91519 12 на фіг, 13 показана блок-схема послідовності операцій схеми передачі обслуговування для схеми послідовності зв'язку, поданої на фіг. 12; на фіг. 14 показана схема частини вузла, якому потрібно встановити доступ до мережі відповідно до зразкового варіанту виконання; на фіг. 15 показана схема послідовності зв'язку, що представляє використовувані етапи, в яких передача обслуговування у цільову мережу відбувається у ході встановлення сеансу по протоколу рівня мережного інтерфейсу в обслуговуючій мережі; і на фіг. 16 показана блок-схема послідовності операцій процесу передачі обслуговування, що ілюструється у схемі послідовності зв'язку, поданій на фіг. 15. ДОКЛАДНИЙ ОПИС ВИНАХОДУ Наведений нижче опис представлений для того, щоб дозволити будь-якому фахівцеві у даній галузі техніки використати винахід. Подробиці наведені у викладеному далі описі з метою пояснення. Потрібно розуміти, що фахівець у даній галузі техніки міг би зрозуміти, що цей винахід можна використати на практиці без використання цих конкретних деталей. В інших випадках добре відомі структури і процеси не описані детально, щоб не ускладнювати опис винаходу непотрібними деталями. Таким чином, даний винахід не треба обмежувати представленими варіантами виконання, але він повинен відповідати найширшому об'єму, що відповідає розкритим тут його принципам і властивостям. На фіг. 3 показана спрощена схема вузлів і мереж, що використовуються в узагальненому варіанті виконання винаходу. Система зв'язку загалом позначена посилальною позицією 42, і включає в себе мережі 45 і 47, з'єднані з базовою мережею 49. Базова мережа 49 може являти собою інтранет або Інтернет. До базової мережі 49 можуть бути підключені інші мережі, але вони не показані на фіг. 3 для ясності та стислості викладення. У мережах 45 і 47 розташовані, відповідно, NAS (сервери мережного доступу) 51 і 53, які, у свою чергу, виконують функцію шлюзів для будьяких вузлів, для 10 яких потрібний доступ до мережі. Припустимо, що у системі 42 є такий вузол 55, якому потрібний доступ до мережі 45 або інших мереж через базову мережу 49. Вузол 55 не має безпосереднього доступу до мережі 45, але може зв'язуватися з NAS 51 через канал 57 передачі даних. Встановлення зв'язку між вузлом 55 і NAS 51 виконуються через процес, що називається "встановленням каналу зв'язку". Припустимо, що вузол 55 не замкнутий у своїй вихідній мережі, такій як мережа 45, але може переміщуватися в інші мережі, такі як мережа 47. У цьому випадку, коли вузол 55 залишає мережу 45 і переміщується у мережу 47, для одержання доступу до мережі вузол 55, аналогічно, повинен встановити інший сеанс встановлення каналу зв'язку з NAS 51 у мережі 47 через ще один канал передачі даних. 13 Канал 57 зв'язку між NAS 51 і вузлом 55 може являти собою канал зв'язку, який може мати різні форми. Наприклад, канал 57 зв'язку може являти собою кабельний канал зв'язку, такий як звичайне телефонне провідне з'єднання, канал зв'язку по коаксіальному кабелю або канал зв'язку по оптичному кабелю, крім інших. Крім того, канал 57 зв'язку може також являти собою безпровідний канал зв'язку, такий як радіоінтерфейс, по якому можна передавати, наприклад, електромагнітні або акустичні сигнали. На фіг. 4 представлений більш конкретний варіант втілення системи 42 зв'язку, яка підтримує безпровідні технології. У цьому випадку вся система, загалом, позначена посилальною позицією 44. Безпровідний зв'язок між вузлами може здійснюватися через канали зв'язку у формі радіоінтерфейсу, такого як канали 58 і 90 радіоінтерфейсу, показані на фіг. 4. У даному варіанті виконання, з метою стислості і ясності викладення, мережа 44 представлена як мережа, що підтримує технології безпровідного зв'язку, такі як стандарти cdma2000, встановлені 3GPP2 (Проект 2 партнерства з розробки системи зв'язку третього покоління), який являє собою консорціум декількох міжнародних органів у галузі стандартизації, включаючи ТІА/ЕІА (Асоціація телекомунікаційної промисловості/Асоціація галузей електронної промисловості) Сполучених Штатів Америки. У системі 44 вузол 56, який може переміщуватися в інші мережі, може бути виконаний у різних формах, таких як КПК (кишеньковий персональний комп'ютер), переносний комп'ютер або стільниковий телефон, крім інших. У мережах 46 втілені PDSN (ВОПД, вузли обслуговування пакетних даних) 60, які виконують функцію NAS 52. Вузол 58 зв'язується з PDSN 60 через RAN (МРД, мережа радіодоступу), яка, загалом, позначена посилальною позицією 62. RAN 62 включає в себе BSC/PCF (контролер базової станції/функція керування пакетними даними) 64, підключений до множини BS (БС, базових станцій) 65А-65N. Аналогічно, у мережі 48 розташовані інші PDSN (вузли обслуговування пакетних даних) 66, які виконують функцію іншого NAS 54. Будь-який вузол, якому потрібно одержати доступ до мережі, зв'язується з PDSN 66 через інший RAN 68. RAN 68 включає в себе BSC/PCF 70, підключений до множини BS 72А-72М. Мережі 46 і 48 можуть обробляти пакети даних, в яких передають голосову інформацію або дані. Докладний опис архітектури мереж 46 і 48, що володіють можливістю безпровідного зв'язку, можна знайти у документі, опублікованому 3GPP2, під назвою "Interoperability Specification (IOS) for CDMA 2000 Access Network Interfaces", TIA-2001-D, Feb. 2005. Перед докладним описом роботи системи 42 зв'язку корисно спочатку пояснити загальну обробку пакету даних під час передачі пакету даних через різні рівні протоколів з різною ієрархією і їх взаємозалежності. У галузі мережного зв'язку для протоколів встановлена ієрархія відповідно до моделі OSI 91519 14 (взаємодія відкритих систем), представленої ISO (ICO, Міжнародна організація зі стандартизації) і в ITU-T (Міжнародний союз електрозв'язку - сектор стандартів у галузі телекомунікацій). Мета полягає у забезпеченні взаємної працездатності обладнання, що постачається різними постачальниками. Таким чином, кожний рівень ієрархії протоколу має свою власну специфікацію. При цьому, якщо тільки задовольняються специфікації на визначеному рівні ієрархії, забезпечується сумісність при розробці продуктів на цьому рівні з іншими продуктами на інших рівнях. Припустимо, що система 44. показана на фіг. 4, підтримує IP (протокол Інтернет). На фіг. 5 схематично представлений стек протоколів в ієрархічному порядку, що звичайно називається "стеком протоколу", і який, загалом, позначений посилальною позицією 74. Стек 74 протоколу IP має структуру, що відповідає моделі IETF (Цільова група інженерної підтримки Інтернет), яка аналогічна, але не є точно такою ж, як модель OSI. Відповідно до моделі IETF, стек 74 протоколу IP має п'ять рівнів, починаючи з рівня 1 до рівня 5. Таким чином, пакет даних, що передається одним вузлом, таким як один з вузлів 56, 60 і 66, як показано на фіг. 4, повинен бути оброблений через стек 74 протоколу. Стек 74 протоколу побудований у вузлі у формі програмних або апаратних засобів, або з використанням їх комбінації. Аналогічно, пакет даних, що приймається тим самим вузлом, повинен бути оброблений з використанням того ж стеку 74 протоколу, але у зворотному порядку. Для ілюстрації розглянемо приклад. Припустимо, що пакет даних обробляють для передачі обслуговування, наприклад, вузла 56 (фіг. 4), при цьому пакет даних спочатку формують відповідно до одного з протоколів на прикладному рівні, тобто, рівні 5. Рівень 5 включає в себе HTTP (протокол передачі гіпертексту), SMTP (простий протокол пересилання пошти), FTP (протокол передачі файлів) і RTP (ТПР, транспортний протокол реального часу). Крім того, припустимо, що пакет даних являє собою продукт сеансу VoIP (протокол передачі мови через Інтернет). Пакет даних, таким чином, повинен бути відформатований відповідно до ІІТР на рівні 5. Пакети даних, які чутливі до часу, такі як пакети даних, одержані внаслідок виконання RTP на рівні 5, повинні бути оброблені у режимі реального часу. Зокрема, дефектні пакети звичайно не передають повторно, а просто відкидають, щоб не ускладнювати передачу інших пакетів даних, що надходять. Пакети даних RTP, тому, звичайно переносять, використовуючи UDP (ПДК, протокол пакету даних користувача) на рівні 4, рівні транспорту. Відповідно до цього, пакет даних з RTP на рівні 5 повинен бути додатково сформульований відповідно до UDP на рівні 4. З іншого боку, якщо пакет даних був сформований з використанням інших протоколів на рівні 5, таких як FTP, такий пакет даних звичайно передають через TCP (протокол керування передачею) на рівні 4. Відповідно до TCP. точна доставка пакету даних має першорядне значення. При цьому дефектні пакети завжди повторно передають, не 15 зважаючи на можливе уповільнення загального процесу передачі даних. До пакетів даних після пропускання їх через цей рівень передачі, рівень 4, додають інформацію, таку як номери портів джерела і призначення. Пакети даних після пропускання їх через рівень передачі, рівень 4, потім передають у мережний рівень, рівень 3, для обробки. У цьому конкретному випадку, одержані у результаті пакети даних з рівня 4 повинні бути відформатовані знову відповідно до IP, наприклад, з доданням адрес джерела і призначення пакету даних. Потрібно зазначити, що скорочено на фіг. 5 показаний тільки IP на рівні 3. На рівні 3 є інші протоколи, які виконують допоміжні функції відносно протоколу IP. Наприклад, ІСМР (протокол керуючих повідомлень мережі Інтернет), який призначений для передачі повідомлень про помилку для пакетів даних, які не можуть бути доставлені. Після цього пакет даних повинен бути розбитий на фрейми так, щоб він відповідав протоколу, що застосовується на рівні каналу зв'язку, рівні 2. РРР (протокол каналу зв'язку з безпосереднім з'єднанням), описаний вище, класифікований як протокол рівня 2. Як вказано вище, існують інші не-РРР протоколи, що використовуються мережами для заміни РРР як протоколу рівня мережного інтерфейсу. Найнижчий рівень стека 74 протоколу на фіг. 5 являє собою фізичний рівень, рівень 1, який працює з фізичним втіленням передачі пакету даних. Наприклад, на фіг. З, якщо рівень 57 зв'язку являє собою звичайне провідне з'єднання, фізичний рівень, рівень 1, стосується апаратних засобів обох вузлів 55 і 51, і передає сигнали через електричні проводи, які складають канал 57 зв'язку. Як інший приклад, як показано на фіг. 4, канал 58 зв'язку являє собою радіоінтерфейс, при цьому фізичний рівень, рівень 1, стосується ефірного простору і апаратних ланцюгів RAN 62. що передають сигнали через ефірний простір. Розглянемо знову фіг. 4. При прийомі пакету даних зразковим вузлом 56, такий пакет даних повинен бути оброблений з використанням того ж стеку 72 протоколу (фіг. 5), але у зворотному порядку, тобто, від рівня 1 до рівня 5. Припустимо у цьому прикладі, що вузол 56 спочатку повинен одержати доступ до мережі через PDSN 60. Далі припустимо, що вузол 56 не має безпосереднього доступу до мережі 46. Звичайно вузол 56 може почати процес доступу до мережі шляхом встановлення спочатку сеансу РРР з PDSN 60. Однак, як пояснювалося вище, для спрощення процесу встановлення зв'язку перед одержанням доступу до мережі були запропоновані інші протоколи рівня мережного інтерфейсу. Один з таких протоколів описаний у патентній заявці '068, також згаданій вище. У наведеному далі описі, для спрощення пояснень, протокол, розкритий у патентній заявці ’068, представлений разом з описом роботи зразкового варіанту виконання. Однак потрібно зазначити, що практика винаходу не потребує такого обмеження і не повинна бути обмежена таким чином. При цьому цілком можуть бути застосовні інші 91519 16 протоколи рівня мережного інтерфейсу, крім протоколу, описаного у патентній заявці ’068. Повертаючись знову до фіг. 4, перед обміном повідомленнями, фізичний канал 58 зв'язку повинен бути готовий до передачі сигналів. Іншими словами, фізичний рівень, рівень 1, вузла 56 і BS 65A повинен, передусім, фізично бути присутнім і повинен бути встановлений. Після того, як фізичний рівень буде встановлений, тобто, після того як вузол 56 і PDSN 60 детектують взаємну фізичну присутність один одного через RAN 62, PDSN 60 негайно передає перше повідомлення у вузол 56. На фіг, 6 показана блок-схема послідовності операцій, шо представляє послідовність передачі повідомлень між вузлом 56 і PDSN 60. Обробка потоку, загалом, позначена посилальною позицією 75. Обробка 75 потоку описана детально у заявці ’068, але коротко наведена нижче. PDSN 60 приймає мережний доступ тільки від авторизованих вузлів. Перше повідомлення передає PDSN 60, яке називається повідомленням синхронізації, яке позначене посилальною позицією 76. Повідомлення 76 синхронізації включає в себе всі можливі варіанти аутентифікації, вибір серед яких здійснюється вузлом 56. Ці варіанти вибору можуть містити повідомлення-запит відповідно до CHAP (протокол взаємної аутентифікації) і запит на одержання паролю та імені користувача, необхідних РАР (протокол аутентифікації за паролем), і будь-яких інших застосовних протоколів аутентифікації. Після одержання повідомлення 76 синхронізації вузол 56 відповідає повідомленням 78 запиту, як показано на фіг. 6. У повідомлення 78 запиту вузол 56 включає необхідну інформацію аутентифікації у відповідь на запити, представлені у повідомленні 76 синхронізації. Крім того, вузол 56 також включає у повідомлення 78 запиту всі можливі варіанти вибору параметра, необхідні для встановлення каналу зв'язку для вузла 56, для подальшого доступу до мережі через PDSN 60. При цьому не має значення, чи будуть параметри з відповідними варіантами вибору стосуватися конфігурації каналу зв'язку аутентифікації або керування доступом до мережі. Таким чином, замість класифікації параметрів відповідно до функцій компонентів протоколу, таких як LCP (протокол керування каналом), CHAP (протокол взаємної аутентифікації) і ІРСР (протокол керування протоколом Інтернет), як описано вище відносно РРР, у повідомленні 78 запиту, всі параметри з варіантами вибору включені незалежно від функцій. Більш конкретно, параметри з варіантами вибору у повідомленні 78 запиту можуть включати в себе відповідь на повідомлення-запит, або ім'я користувача і пароль, якщо застосовно, параметри конфігурації каналу зв'язку для каналу зв'язку 58, такі як розмір датаграми і схема стиснення поля заголовка HDLC (високорівневе керування каналом передачі даних), а також параметри для мережного доступу, такі як IP адреса, конфігурація DNS (доменна система іменування), і протокол стиснення заголовка IP, якщо застосовно, і т.д. 17 Повідомлення 78 запиту, у принципі, відформатоване з використанням навмисної надмірності відносно варіантів вибору, що дозволяє PDSN 60 вибирати варіанти, які підтримуються обома вузлами 56 і 60, що дозволяє обом вузлам 56 і 60 швидко закінчувати спільний процес встановлення каналу зв'язку на рівні 2 каналу. Серед множини варіантів вибору PDSN 60 може вибірково вибирати параметри з асоційованими варіантами вибору, які очевидно підтримуються з метою підвищення шансу успішного встановлення каналу зв'язку, скорочуючи, таким чином, загальний час підтримки каналу зв'язку. У відповідь на повідомлення 78 запиту, як показано на фіг, 6, PDSN 60 передає повідомлення 80 відповідь. У повідомленні 80 відповіді, PDSN 60 вибирає варіанти вибору з різних варіантів вибору. Повідомлення 80 відповідь включає в себе вибрані варіанти параметра з асоційованими з ними значеннями конфігурації. Дуже часто повідомлення 80 відповідь являє собою останнє повідомлення, необхідне до початку передачі мережного трафіку у формі даних 82 користувача вузлом 56. Під час закінчення доступу до мережі один з вузла 56 або PDSN 60 може відправити повідомлення 84 запит на припинення в інший вузол, який після цього відповідає повідомленням 86 підтвердження закінчення і завершує сеанс зв'язку. Як можна бачити, на відміну від інших протоколів, таких як протокол РРР, описаних вище, процес 75 встановлення каналу зв'язку включає, по суті, меншу кількість повідомлень, обмін якими здійснюється до початку передачі даних 82 користувача. Відповідно до цього, встановлення каналу зв'язку на рівні каналу зв'язку, тобто, на рівні 2, у результаті, може бути виконане швидше. Припустимо у цьому прикладі, що у ході обміну даними 82 користувача з PDSN 60 у мережі 46 вузол 56 починає переміщуватися в іншу мережу, таку як мережа 48. Шлях переміщення позначений посилальною позицією 88, як показано на фіг. 4. Відповідно до цього сценарію, вузол 56, у принципі, проходить через процес, що загалом називається "передачею обслуговування". Більш конкретно, вузол 56 перемикає сторону зв'язку з PDSN 60 через RAN 62 у мережі 46 на PDSN 66 через RAN 68 у мережі 48. Відповідно до даного варіанту виконання, перед передачею обслуговування вузол 56 спочатку повинен одержати вказівку на передачу обслуговування. Вказівки на передачу обслуговування можуть бути виражені у різних формах, втілених у різних схемах. На фіг. 7 показана одна така схема, загалом, позначена посилальною позицією 92. Розглянемо фіг. 7 разом з фіг. 4. Перед передачею обслуговування припустимо, що вузол 56 спочатку виконує сеанс 94 зв'язку не-РРР з PDSN 60 через RAN 62 до одержання якого-небудь доступу до мережі. Сеанс 94 може являти собою процес 75 встановлення каналу зв'язку, як показано і описано на фіг. 6. Сеанс 94 встановлення каналу зв'язку не-РРР продовжується, наприклад, у періоди часу tl-t4. Потрібно зазначити, що у середині сеансу встановлення каналу зв'язку не-РРР у період часу 91519 18 t2, PDSN 60 передає повідомлення 96 запиту на конфігурування LCP, яке являє собою повідомлення РРР. Причина цього полягає у тому, що PDSN 60 спочатку не має інформації про те, чи підтримує вузол 56 звичайний РРР або не-РРР, Для підвищення шансу зв'язку з вузлом 56 передають як повідомлення 76 синхронізації відповідно до процесу 75 встановлення каналу зв'язку (фіг. 6), так і повідомлення 96 запиту на конфігурування LCP відповідно до РРР. У цьому випадку вузол 56 підтримує процес 75 встановлення каналу зв'язку. При цьому сеанс 94 протоколу рівня мережного інтерфейсу виконується відповідно до процесу 75 встановлення каналу зв'язку. Після успішного встановлення сеансу 94 протоколу рівня мережного інтерфейсу може бути здійснений обмін даними 82 користувача у період часу t5. Припустимо, що у цей момент часу вузол 56 починає переміщуватися з мережі 46 у напрямі мережі 48. Відповідно до стандартів cdma2000, мережі, що володіють можливістю безпровідної передачі даних, такі як мережі 46 і 48, постійно передають повідомлення у режимі широкомовної передачі для позначення своєї ідентичності. Повідомлення широкомовної передачі може бути виконане у формі "Повідомлення системного параметра" і/або іноді у формі "Повідомлення розширеного системного параметра", що виконується по F-BCCH (Канал керування прямою широкомовною передачею), який являє собою один з каналів керування прямою передачею у мережі. При цьому вузол, такий як вузол 56, завжди може визначити своє місцеположення, детектуючи повідомлення широкомовної передачі з мереж. У повідомленні системного параметра, крім іншого, міститься SID (системна ідентифікація) і NID (ідентифікація мережі). SID являє собою число, яке призначене визначеному оператору безпровідного зв'язку у мережі, такій як мережа 46 або 48. З іншого боку, NID являє собою номер, який унікально ідентифікує конкретну мережу у системі передачі даних, такій як система 44. У повідомлення розширеного системного параметра включена PZID (ідентифікація пакетної зони), яка ідентифікує область зони обслуговування PCF, таку як BSC/PCF 64 або 70, як показано на фіг. 4. Якщо система передачі даних, така як система 44, підтримує HRPD (ВШПП, високошвидкісну пакетну передачу даних), звичайно відому як 1xEV-DO, яка являє собою технологію безпровідної передачі даних, що базується на CDMA (МДКР, багатостанційний доступ з кодовим розділенням каналів), у масці підмережі ID сектора може бути присутньою ID (ідентифікація) підмережі замість PZID в іншому повідомленні широкомовної передачі, що називається "повідомленням параметра сектора". Розглянемо тепер фіг. 4 і 7, припустимо, що коли вузол 56 досягає території мережі 48, вузол 56 приймає повідомлення широкомовної передачі з мережі 48. З повідомлення широкомовної передачі, крім іншого, одержують новий NID. Новий NID відрізняється від попереднього його аналога. При зміні NID вузол 56 знає, що він перемістився в ін 19 шу мережу. Припустимо, у цьому випадку, що мережа 48 не підтримує якої-небудь з не-РРР як свій протокол рівня 2. При цьому PDSN 66 у мережі 48 передає повідомлення 98 запиту на конфігурування LCP. Вузол 56 відповідає у цей раз на повідомлення 98 запиту на конфігурування LCP. Причина цього полягає у тому, що вузол 56 може обґрунтовано припустити про свій вхід у нову мережу на основі зміни NID, хоча було прийняте повідомлення не-РРР, таке як повідомлення 76 синхронізації. Замість цього було прийняте повідомлення 98 запиту на конфігурування LCP, яке являло собою повідомлення РРР. Вузол 56 відразу визначає, що мережа, в яку він прибув, така як мережа 48, не підтримує якого-небудь незвичайного протоколу рівня 2. Вузол 56, таким чином, швидко орієнтується відносно узгодження з PDSN 66 через сеанс 100 узгодження РРР у період часу t8. У випадку успішного узгодження, після цього, у момент часу t9, виконується передача даних 102 користувача, як показано на фіг. 7. Потрібно зазначити, що вузол 56 відповідає на повідомлення 98 запиту на конфігурування LCP з мережі 48 у період часу t7, але не на повідомлення 96 запиту на конфігурування LCP з мережі 46 у період часу t2. Як вказано вище, це відбувається через те, що вузол 56 одержав інформацію про зміну SID, NID або PZID у момент часу t6 перед моментом часу t7. Після успішного виконання сеансу 100 узгодження РРР може бути встановлена передача даних 102 користувача. Після закінчення передачі даних 102 користувача вузол 30 або NAS 33 може передати повідомлення 104 запиту на припинення в інший вузол, який після цього відповідає повідомленням 106 підтвердження припинення у періоди часу t10 і t11, відповідно, і закінчує сеанс 92 зв'язку. Відповідні етапи першої схеми передачі обслуговування відповідно до даного варіанту виконання представлені у блок-схемі послідовності операцій, що показана на фіг. 8. На фіг. 9 показана друга схема, загалом, позначена посилальною позицією 108. Тепер розглядається фіг. 4 разом з фіг. 9. Як і у попередньому прикладі, вузол 56 спочатку проходить через сеанс 94 протоколу зв'язку перед одержанням доступу до мережі через обслуговуючий PDSN 60.1 знову, для забезпечення кращого шансу підключення вузла 56, повідомлення 96 запиту на конфігурування LCP також передається PDSN 60 у період часу t2 під час сеансу 94, як описане вище. Після успішного виконання сеансу 94 протоколу рівня мережного інтерфейсу не-РРР, виконується обмін даними 82 користувача у період t4 часу, як показано на фіг. 9. І знову припустимо, що у середині передачі даних 82 користувача вузол 56 починає переміщуватися з мережі 46 у напрямі мережі 48. У цьому прикладі вузол 56 приймає вказівку на передачу обслуговування, причому ця вказівка відрізняється від вказівки у попередньому прикладі. Зокрема, коли вузол 56 досягає території мережі 48, вузол 56 приймає інше повідомлення 110 запиту на конфігурування LCP, у період t5 часу, як 91519 20 показано на фіг. 9. У цей час вузол 56 може відрізнити місце походження повідомлення 110 запиту на конфігурування LCP у період часу t5 від повідомлення 96 запиту на конфігурування LCP у період часу t2 на основі різних ID (ІД, ідентифікацій) повідомлення у повідомленнях ПО і 96, як описано нижче. У цей перехідний момент корисно зробити відступ для пояснення формату фрейму даних повідомлення РРР. На фіг. 10 представлений формат фрейму даних, що має HDLC (високорівневе керування каналом передачі даних) - як фрейм, що використовується у РРР. Шаблон фрейму для пакету даних, загалом, позначений посилальною позицією 112 і являє собою, у принципі, шаблон пакету відповідно до специфікації RFC 1662 для РРР. Більш конкретно, фрейм 112 даних включає в себе поле 114 прапора, поле 116 адреси, поле 118 керування, поле 120 номера протоколу, поле 122 даних і поле 124 FCS (ПКФ, послідовність контролю фрейму). Для забезпечення зворотної сумісності з РРР, більшість протоколів рівня мережного інтерфейсу, призначені для заміни РРР, також сконструйовані з форматом фрейму, більш або менш подібним до формату 112 фрейму для РРР Наприклад, у протоколі 75 каналу зв'язку, розкритому у патентній заявці ’068, показаній на фіг. 6, використовується формат фрейму, аналогічний формату фрейму РРР. Розглянемо тепер фіг. 10. Поле 114 прапора має довжину один байт і означає початок фрейму пакету даних. Поле 114 прапора завжди має шістнадцяткове значення 7Е, і це значення є тим самим значенням, яке використовується у процесі 54 каналу зв'язку і РРР, відповідно до вимог RFC 1662. Поле 116 адреси також являє собою поле довжиною один байт і у ньому завжди встановлене шістнадцяткове значення FF, також відповідно до RFC 1662. Поле 118 керування має довжину один байт і є фіксованим і має шістнадцяткове значення 03, відповідно до вимог RFC 1662. У полі 120 номера протоколу, значення поля означає, що собою являє пакет 112 даних. Область 120 номера протоколу має довжину два байти. Наприклад, як визначено у RFC 1661 і 1662, кожне з повідомлень LCP, таке як повідомлення запиту на конфігурування LCP (фіг. 2), має шістнадцяткове значення С021. Для того, щоб можна було відрізняти одне повідомлення РРР від іншого повідомлення, такого як повідомлення запиту на конфігурування LCP, і повідомлення не підтвердження конфігурації LCP (фіг. 2), різні ІД повідомлення включені у поле 122 даних, як пояснюється нижче. Що стосується інших протоколів каналу зв'язку, розроблених для заміни РРР, таких як протокол 75, розкритий у заявці Ό68, поданий на фіг. 6, у них використовуються інші номери 120 протоколу для того, щоб можна було відрізнити їх від інших повідомлень РРР. Наприклад, у процесі 75 встановлення каналу зв'язку, показаному на фіг. 6, повідомлення 76 синхронізації, повідомлен 21 ня 78 запиту або повідомлення 80 відповіді, що використовуються у процесі 75 встановлення каналу зв'язку (фіг. 6) мають унікальне значення протоколу, відмінне від будь-якого зі значень протоколу, що використовуються у РРР. Це дозволяє легко відрізняти, є пакет 112 даних пакетом РРР або пакетом не-РРР. Поле 122 даних має довжину у діапазоні від нуля до більшої кількості байт корисної інформації, ніж містить або інформація даних або керування. Наприклад, якщо значення у полі 120 номера протоколу має значення, яке означає, що пакет 112 даних являє собою повідомлення 96 або 110 запиту на конфігурування LCP (фіг. 9), поле 122 даних включає в себе всі істотні варіанти вибору параметрів зв'язку при встановленні каналу 58 або 90 зв'язку, відповідно. Як інший приклад, якщо значення у полі 120 номера протоколу має значення, яке означає, що пакет 112 даних являє собою дані 82 або 100 користувача (фіг. 9), пакет даних IP, що генерується з рівня З, буде повністю інкапсульований у полі 122 даних. Поле 124 FCS має довжину у діапазоні від двох до чотирьох байт і містить коди, такі як CRC (ЦНК, циклічний надмірний код) фрейму 112, призначений для забезпечення основного захисту від помилок під час передачі. Знову розглянемо фіг. 9. Як вказано вище, поле 122 даних включає в себе ІД повідомлення, що називається "кодом" відповідно до RFC 1661, який дозволяє відрізнити один тип повідомлення РРР від іншого, наприклад, дозволяє відрізняти повідомлення запиту на конфігурування LCP і повідомлення підтвердження конфігурування LCP (фіг. 2). Іншу відмінність можна також забезпечити в ІД повідомлення у межах одного типу повідомлення, наприклад, шляхом приєднання допоміжного ІД, що називається "ідентифікатором" у RFC 1661. Наприклад, повідомлення 96 запиту на конфігурування LCP і повідомлення LCP 110 запиту на конфігурування LCP у процесі 108, показаному на фіг. 9, може бути сформоване з різними кодами, або як альтернатива, з однаковим кодом, але різними ідентифікаторами, характерними для мереж. При цьому мережі 48 і 46 можуть бути розроблені так, що вони будуть передавати різні повідомлення 96 і 110 конфігурування LCP, відповідно, шляхом включення різних кодів або ідентифікаторів, введених у поле 122 даних пакету 112 даних (фіг. 10). Отже, у даному прикладі, коли вузол 56 переміщується з мережі 46 у мережу 48, завдяки розпізнаванню повідомлення запиту на конфігурування LCP, ідентифікатор якого відрізняється від ідентифікатора у мережі 48, вузол 56 знає, що він знаходиться на території мережі 48. Знаходячись у мережі 48, вузол 56 не приймає повідомлення не-РРР, але замість цього приймає повідомлення 110 запиту на конфігурування LCP, яке являє собою повідомлення РРР і яке має інший ідентифікатор, відмінний від ідентифікатора повідомлення 96 запиту на конфігурування LCP, при цьому вузол 56 визначає, що мережа 48 не підтримує якого-небудь протоколу не-РРР як свого протоколу встановлення каналу зв'язку. Вузол 56 швидко орієнтується і відповідає на повідомлення 91519 22 110 запиту на конфігурування LCP. Після цього виконується узгодження 100 РРР, як показано на фіг. 9. Інша частина процесу 108. по суті, аналогічна процесу 92, представленому з посиланням на фіг. 7 і описаному вище, і більше не повторюється. Відповідні етапи другої схеми передачі обслуговування відповідно до даного варіанту виконання представлені у блок-схемі послідовності операцій, показаній на фіг. 11. Як альтернатива, пакет ідентифікації версії/пропускної здатності може бути вставлений у поле 122 даних пакету 112 даних. Відповідно до стандарту cdma2000, оголошеного 3GPP2, пакет ідентифікації версії/пропускної здатності може бути включений, як визначено у документі 3GPP2, під назвою "Wireless IP Network Standard", TIA835D. Пакет ідентифікації версії/пропускної здатності, у принципі, являє собою пакет, специфічний для постачальника, як можна бачити по його назві, який ідентифікує відповідну інформацію визначеного постачальника вузла, такого як вузол 56 або PDSN 60 або 66, показаний на фіг. 4. Спочатку, під час фази LCP сеансу РРР, виконують обмін пакетами ідентифікації версії/пропускної здатності. Мета цього обміну пакетами ідентифікації версії/пропускної здатності полягає у тому, щоб виключити непотрібні етапи узгодження під час сеансу РРР відносно властивостей, що не підтримуються кожним з вузлів, після того як вузли, що проводять узгодження, вказують свої версії і пропускні здатності на ранньому етапі у процесі узгодження. Як приклад, припустимо, що вузол 56 на фіг. 9 у період часу t2 приймає повідомлення 96 запит на конфігурування LCP з пакетом ідентифікації версії/пропускної здатності, який не виключає використання якого-небудь з не-РРР, при цьому вузол 56 у період часу t3, таким чином, не переходить безпосередньо до використання РРР для встановлення каналу зв'язку. Замість цього, вузол 56 продовжує процес 94 встановлення каналу зв'язку неРРР у період часу t3. З іншого боку, якщо вузол 56 у період часу t5 приймає повідомлення ПО запиту на конфігурування LCP з пакетом ідентифікації версії/пропускної здатності, що має інформацію, яка дозволяє використовувати тільки РРР, тоді вузол 56 вмить орієнтується і проводить узгодження з цільовим вузлом 66 через РРР у період часу t6. Як альтернатива, окремий пакет ідентифікації версії/пропускної здатності може бути переданий перед повідомленням 96 або 110 запиту на конфігурування LCP, Таким чином, наприклад, у період часу t5, два повідомлення можуть бути передані цільовим PDSN 66. Перше повідомлення являє собою пакет ідентифікації версії/пропускної здатності з інформацією, специфічною для постачальника, включеною у поле 122 даних пакету 112 даних (фіг. 10), як описано вище. Друге повідомлення може являти собою звичайне повідомлення запиту на конфігурування LCP, таке як перше повідомлення запиту на конфігурування LCP, під час фази 36 узгодження LCP сеансу 34 РРР, як показано на фіг. 2. 23 Відповідні етапи схеми передачі обслуговування, описані безпосередньо вище, представлені у блок-схемі послідовності операцій, показаній на фіг. ПА. На фіг. 12 показана ще одна схема передачі обслуговування, загалом, позначена посилальною позицією 130. Розглянемо тепер фіг. 12 разом з фіг. 4. Як і у попередній схемі, знаходячись у мережі 46, вузол 56 повинен пройти через сеанс 94 встановлення каналу зв'язку з PDSN 60 перед одержанням доступу до мережі. І знову, для забезпечення кращого шансу підключення вузла 56, повідомлення 96 запиту на конфігурування LCP також передається обслуговуючим PDSN 60 у мережі 46 у період часу t2 під час сеансу 94, як також пояснювалося вище. Потрібно зазначити, що у цей час повідомлення 96 запиту на конфігурування LCP передають під час передачі інших повідомлень не-РРР у сеансі 94 встановлення каналу зв'язку. Після успішного виконання сеансу 94 протоколу рівня мережного інтерфейсу не-РРР, виконують обмін даними 82 користувача у період часу t4, аналогічно тому, як було описано вище і подано на фіг. 12. І знову припустимо, що у середині обміну даними 82 користувача вузол 56 починає переміщуватися з мережі 46 у напрямі мережі 48. Коли вузол 56 досягає території мережі 48, у цей час вузол 56 приймає множину повідомлень 132A-132N запиту на конфігурування LCP, у період часу t7, як показано на фіг. 12. У цьому прикладі вузол 56 може відрізняти місце походження повідомлення 96 запиту на конфігурування LCP з мережі 46 у період часу 12 від повідомлення 132A132N запиту на конфігурування LCP з мережі 48 у період часу t7, на основі структури передачі повідомлення. Більш конкретно, у період часу t2 вузол 56 приймає одне повідомлення 96 конфігурування LCP під час передачі інших повідомлень не-РРР у сеансі 94 встановлення каналу зв'язку. На відміну від цього, у період часу XI вузол 56 приймає множину повідомлень 132А-132N конфігурування LCP. Таким чином, базуючись на структурі прийому повідомлень запиту на конфігурування LCP, вузол 56 визначає, підтримує мережний вузол 56 у цей час протокол не-РРР чи ні. Наприклад, вузол 56 може бути запрограмований так, що він буде відповідати тільки на друге послідовне повідомлення запиту на конфігурування LCP. Таким чином, у цьому випадку у період часу t2, коли вузол 56 приймає повідомлення 96 запиту на конфігурування LCP, вузол 56 чекає надходження наступного повідомлення. Якщо наступне повідомлення, що надійшло, не являє собою повторення повідомлення 96 запиту на конфігурування LCP, вузол 56 визначає, що мережа 46 підтримує інші протоколи не-РРР, крім РРР, і просто ігнорує повідомлення 96 запиту на конфігурування LCP у період часу t2, і продовжує сеанс 94 каналу зв'язку не-РРР, як описано вище. З іншого боку, якщо вузол 56 приймає більше, ніж одне послідовне повідомлення 132A-132N запиту на конфігурування LCP, наприклад, під час періоду часу t7, вузли 56 знають, що мережа, що передає повідомлення, мережа 48 у цьому випадку, підтримує тільки РРР і не підтримує інші прото 91519 24 коли рівня мережного інтерфейсу. Вузол 56 негайно переходить на зв'язок з цільовим PDSN 66 через RAN 68 у мережі 48, використовуючи протокол РРР, як показано на фіг. 12. Інша частина процесу 130, по суті, аналогічна процесам 92 і 108, показаним відповідно на фіг. 7 і фіг. 9, описаним вище, і, таким чином, більше не повторюється. Потрібно зазначити, що кількість повідомлень 132A-132N запиту на конфігурування LCP, на які відповідає вузол 56, повинна бути такою, що конфігурується. Наприклад, замість початку узгодження 100 РРР з цільовим PDSN 66, після другого повідомлення 132В запиту на конфігурування LCP, як описано у наведеному вище прикладі, вузол 56 цілком може почати узгодження 100 РРР, після і-ого повідомлення 132І запиту на конфігурування LCP, де і знаходиться у діапазоні від 2 до N, причому N являє собою ціле число, більше 2. Відповідні етапи третьої схеми передачі обслуговування відповідно до даного варіанту виконання показані у блок-схемі послідовності операцій, поданій на фіг. 13. На фіг. 14 схематично представлена частина втілення апаратних засобів пристрою, такого як вузол 56, поданий на фіг. 4, позначеного посилальною позицією 140 відповідно до зразкового варіанту виконання винаходу. Пристрій 140 може бути побудований і може бути реалізований у різних формах, наприклад у вигляді переносного комп'ютера, КПК або стільникового телефону, крім інших варіантів. Пристрій 140 містить центральну шину 142 передачі даних, що з'єднує декілька схем разом. Схеми включають в себе ЦПП (центральний процесорний пристрій) або контролер 144, схему 146 приймача, схему 148 передавача і модуль 150 пам'яті. Якщо пристрій 140 являє собою частину пристрою безпровідного зв'язку, схеми 146 і 148 прийому і передачі можуть бути підключені до РЧ (радіочастотної) схеми, але це не показано на кресленні. Схема 146 прийому обробляє і вміщує у буфер сигнали, що приймаються перед передачею їх у шину 142 передачі даних. З іншого боку, схема 148 передачі обробляє і вміщує у буфер дані з шини 142 передачі даних перед передачею їх з пристрою 140. ЦПП/контролер 144 виконує функцію керування даними у шині 142 передачі даних і, крім того, виконує функцію загальної обробки даних, що включає в себе виконання вмісту інструкцій у модулі 140 пам'яті. Замість використання окремого компонування, як показано на фіг. 14, як альтернатива, схема 148 передавача і схема 146 приймача може являти собою частину ЦПП/контролера 144. Модуль 150 пам'яті включає в себе набір інструкцій, загалом, позначений посилальною позицією 152. У даному варіанті виконання інструкції включають в себе, крім іншого, такі ділянки, як функція 154 стеку протоколу, клієнт 156 встановлення каналу зв'язку, функція 158 передачі обслуговування каналу зв'язку і функція 160 РРР. Функція 154 стеку протоколу забезпечує роботу стеку протоколу, аналогічного стеку 74, як показано і описано вище з посиланням на фіг. 5. Клієнт 156 25 встановлення каналу зв'язку включає в себе набори інструкцій, призначені для встановлення одного або більше процесів каналу зв'язку, крім процесу каналу зв'язку РРР, таких як процес 94, як показано на фіг. 7, 9 і 12, описаних вище. Функція 160 РРР включає в себе набори інструкцій, що забезпечують можливість виконання пристроєм 140 процесу РРР. Функція 158 передачі обслуговування каналу зв'язку включає в себе набори інструкцій, призначених для виконання процесу передачі обслуговування, такого як процес 92, 108 і 130, описані і показані на відповідних кресленнях на фіг. 7-13. Функція 160 РРР може використовуватися незалежно для мережі, яка підтримує процес каналу зв'язку РРР або не-РРР. або як відступ, у випадку, коли мережа не підтримує процеси каналу зв'язку відповідно до інших не-РРР, як також описано вище. У даному варіанті виконання модуль 150 пам'яті являє собою схему ОЗП (оперативний запам'ятовуючий пристрій). Приклади ділянок 154, 156, 158 і 160 інструкцій являють собою програмні процедури або модулі. Модуль 150 пам'яті може бути зв'язаний з іншою схемою пам'яті (не показана), яка може бути енергозалежного або енергонезалежного типу. Як альтернатива, модуль 150 пам'яті може бути побудований на основі інших типів схеми, таких як EEPROM (ППЗПЕС, програмований постійний запам'ятовуючий пристрій, що електрично стирається), EPROM (ППЗПС, програмований постійний запам'ятовуючий пристрій, що стирається), ПЗП (постійний запам'ятовуючий пристрій), ASIC (спеціалізована інтегральна мікросхема), магнітний диск, оптичний диск та інші пристрої, добре відомі у даній галузі техніки. Крім того, потрібно зазначити, що процеси 92, 108 і 130, як описано вище і подано на фіг. 7-13, 15 і 16, також можуть бути кодовані у вигляді інструкцій, що зчитуються комп'ютером, записаних на будь-якому носії інформації, що зчитується комп'ютером, відомому у даній галузі техніки. У даному описі і доданій формулі винаходу термін "носій інформації, що зчитується комп'ютером" стосується будь-якого носія інформації, який бере участь у наданні інструкцій для будь-якого процесора, такого як ЦПП/контролер 144, показаного і описаного на фіг. 14, для їх виконання. Такий носій інформації може бути носієм типу накопичувача і може бути виконаний у формі енергозалежного або енергонезалежного носія інформації, як також описано вище, наприклад, при описі модуля 150 пам'яті, з посиланням на фіг. 14. Такий носій інформації також може бути носієм передавального типу і може включати в себе коаксіальний кабель, мідний провід, оптичний кабель і радіоінтерфейс, по якому передають акустичні або електромагнітні 91519 26 хвилі, і який дозволяє передавати сигнали, що зчитуються машинами або комп'ютерами. Нарешті, як описано у варіанті виконання, процедури передачі обслуговування представлені як такі, що виконуються у ході обміну даними 82 користувача (наприклад, див. фіг. 7, 9 і 12). Однак ця умова не є обов'язковою. Можливо також виконувати процедуру передачі обслуговування, коли вузол 56 знаходиться у процесі встановлення сеансу 94 протоколу рівня мережного інтерфейсу. На фіг. 15 показаний такий сценарій, в якому виділений процес 92 встановлення каналу зв'язку, як показано і описано на фіг. 7, і деякі відповідні етапи повторюються з метою ілюстрації. Як показано на кресленні, у період t4 часу, перед закінченням процесу 94 встановлення каналу зв'язку, вузол 56 знаходиться у процесі переміщення у мережу 48 і додатково визначає зміну SID, NID, PZID або ID підмережі у період часу t4. При цьому вузол 56 не обов'язково може приймати повідомлення 80 відповіді з PDSN 60 у мережі 46 під час переміщення. Однак, коли вузол 56 приймає повідомлення 98 запиту на конфігурування LCP у період часу t5, вузол 56 визначає, що він знаходиться на території мережі 48 і може негайно почати процес 100 узгодження РРР аналогічно до того, як описано вище. Крім того, це ж справедливо для процесів 108 і 130, представлених і описаних на фіг. 9 і 12, відповідно. Таким чином, процес передачі обслуговування відповідно до зразкового варіанту виконання винаходу необов'язково повинен відбуватися тільки під час обміну даними користувача. Крім того, система 44 була описана як така, що підтримує стандарти cdma2000. Інші стандарти також, очевидно, можуть бути застосовані. Приклад інших стандартів являє собою WCDMA (широкосмуговий багатостанційний доступ з кодовим розділенням каналів), оголошений 3GPP (Проект партнерства з розробки системи зв'язку третього покоління). Крім того, у зразковому варіанті виконання протокол рівня 3 описаний як протокол IP. IP може мати іншу версію, таку як IPv4 (протокол Інтернет версії 4) і IPv6 (протокол Інтернет версії 6). Крім того, потрібно зазначити, що у рівній мірі застосовні інші протоколи рівня 3. Наприклад, протокол рівня З може являти собою IPX (Протокол міжмережного пакетного обміну), Apple-Talk і різні інші мережні протоколи інших версій. Крім того, будь-які логічні блоки, схеми і етапи алгоритму, описані спільно з варіантом виконання, можуть бути втілені у вигляді апаратних засобів, програмних засобів, вбудованого програмного забезпечення або їх комбінацій. Для фахівця у даній галузі техніки буде зрозуміло. що ці та інші зміни у формі і деталях можуть бути виконані без відходу від об'єму і суті винаходу. 27 91519 28 29 91519 30 31 91519 32 33 Комп’ютерна верстка І.Скворцова 91519 Підписне 34 Тираж 26 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601