Зміна доступу для ремаршрутизації з’єднання

Реферат: Запропоновано спосіб і відповідні пристрої, які дозволяють перехід з комутації пакетів у домені зв'язку до комутації каналів зв'язку. Коли користувацьке обладнання як термінальний пункт з'єднання приймає повідомлення з ініціалізацією з'єднання з медіапотоком, наприклад, аудіопотоком, який не може бути доставлений з комутацією пакетів, воно надсилає спеціальну відповідь, що відхиляє з'єднання з доступом через комутацію пакетів, до прикладного сервера забезпечення централізації і безперервності сервісу. У цьому сервері здійснюється перевірка, чи виконано декілька умов, для визначення можливості зміни з'єднання зв'язку, що включає цей медіапотік, на домен комутації каналів зв'язку. Якщо це можливо, з'єднання зв'язку змінюється з домену комутації пакетів на домен з комутацією каналів зв'язку. UA 101880 C2 (12) UA 101880 C2 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 60 Винахід стосується механізму зміни доступу або домену з'єднання зв'язку для ремаршрутизації з'єднання, зокрема, механізму зміни конкретного першого домену зв'язку, наприклад, домену комутації пакетів (PS), на другий домен зв'язку, наприклад, домен комутації каналів зв'язку (CS) у встановлювальній процедурі завершення створення сеансу зв'язку. В останні роки у світі знайшло широке застосування розширення можливостей мереж зв'язку, наприклад, провідні мережі зв'язку, наприклад, Інтегральна Сервісна Цифрова Мережа (ISDN), або безпровідні мережі зв'язку, наприклад, система cdma2000 (множинний доступ з кодовим розділенням), стільникові мережі зв'язку 3-го покоління (3G), наприклад, Універсальні Мобільні Телекомунікаційні Системи (UMTS), стільникові мережі зв'язку 2-го покоління (2G), наприклад, GSM, Загальна Пакетна Радіосистема (GPRS), Удосконалені швидкості передачі даних для глобального розгортання (EDGE), або інші безпровідні системи зв'язку, наприклад, Безпровідна Локальна Мереж (WLAN) або Світова інтероперабільність для Мікрохвильового доступу. Такі організації, як Співтовариський Проект 3-го покоління (3GPP), Об'єднані Сервіси і Протоколи Телекому і Інтернету для Удосконалених Мереж (TISPAN), Міжнародний Телекомунікаційний Союз (ITU), Співтовариський Проект 3-го покоління - 2 (3GPP2), Робоча Технічна Група Інтернету (IETF), IEEE (Інститут Електро- і радіоінженерів), WiMax Forum тощо розробляють стандарти для мереж зв'язку і доступу. Взагалі для належного встановлення і обслуговування з'єднання зв'язку між мережевими елементами, наприклад, користувацьким обладнанням (UE) і іншим зв'язковим обладнанням або користувацьким обладнанням, базою даних, сервером тощо використовуються один або більш проміжних мережевих елементів, наприклад, елементи контролю, підтримки вузлів або сервісних вузлів. Одним важливим застосуванням є мультимедійні сервіси зв'язку. Мультимедійним сеансом є зв'язок, де, наприклад, текстова, зображувальна аудіо- (голос) і відеоінфрмація використовуються одночасно. Мультимедійні сеанси взагалі потребують передачі декількох різних типів даних (відео, аудіо тощо) паралельно, і ці дані мають бути прийняті і приймаються різними типами зв'язкового обладнання або мережевими елементами, і це потребує узгодження багатьох протоколів зв'язку і належної корекції параметрів зв'язку. Поточною технологією злиття Інтернету з стільниковими системами зв'язку є Мультимедійна Підсистема Інтернет-Протоколу (IP) IMS. IMS є стандартизованою архітектурою операторів, що мають забезпечувати мобільне і фіксоване мультимедійне обслуговування. IMS Голосове використання IP (VoIP) базується на стандартизованому 3GPP застосуванні Протоколу Ініціації Сеансу (SIP) і здійснюється через стандартний Інтернет-Протокол (IP). Підтримуються системи зв'язку як з PS, так і з CS. Як механізм сигналізації між IMS і користувацьким обладнанням використовується Протокол Ініціації Сеансу (SIP). Деталі структури і процедур IMS описані у відповідних стандартах і є добре відомими, і тому їх опис тут є зайвим. Однак, необхідно забезпечити взаємодію між системами з CS і з PS, щоб не погіршити умови на кінці користувача. IMS надає декілька послуг, наприклад, Централізовані Сервіси (ICS) IMS. ICS надає обслуговування зв'язку таким чином, що усі сервіси і контроль сервісу базуються на механізмах IMS, які надають сервіси IMS, використовуючи доступ з CS до медіаносія. З ICS користувацьке обслуговування надається IMS. Користувацькі сеанси контролюються у IMS через доступ з PS або з CS. При використанні доступу з CS або доступу з PS до мережі, які не підтримують повнодуплексний мовний компонент сервісу IMS, базована на CS мережа використовується для встановлення схемного носія як медіа для сеансів IMS. З іншого боку, якщо доступ з PS до мережі підтримує, наприклад, повнодуплексний мовний компонент сервісу IMS, то можуть бути використані стандартні процедури сеансу IMS. Як було відзначено, ICS надає механізми підтримки використання медіаносія з CS для сеансів IMS. З ICS сеанси IMS, що використовують медіа з CS, розглядаються як стандартні сеанси IMS для забезпечення контролю сервісу і безперервності сервісу. ICS також визначає механізм сигналізації між UE і IMS для транспортування інформації, потрібної безперервності сервісу при використанні доступу з CS для транспортування медіа. IMS згідно з 3GPP підтримує у з'єднанні з ICS так звану Безперервність Голосового Радіосеансу (SR-VCC), де передача зв'язку до доступу з CS ініціюється і контролюється ICS. Для належної зміни доступу до або домену зв'язку, наприклад, з домену PS на домен CS необхідно брати до уваги декілька вимог. Одною з них є обрання домену з підтримкою UE для вимоги завершення. У цих випадках у стандартах ICS визначено встановлювальну процедуру завершення створення сеансу зв'язку. У цій процедурі припускається, що наступний сеанс забезпечується, наприклад, базовою точкою Gm (сигнального інтерфейсу між UE і IMS, 1 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 базованого на протоколах SIP і SDP) з використанням лише PS, і UE вирішує використовувати домен CS. Отже, сеанс має бути встановлений з використанням домену CS. Це може статись, наприклад, коли UE виявляє, що домен PS є непридатним для мови, тобто відповідний (аудіо) медіапот не може бути доставлений, і UE вирішує використати домен CS. Згідно з стандартом ICS, встановлювальна процедура завершення створення сеансу включає такі операції. На боці закінчення і Сервер Забезпечення Централізації і Безперервності Сервісу (SCC AS) приймає повідомлення ініціалізації з'єднання (повідомлення INVITE SIP) від викликаючого UE через Службову Функцію Контролю виклику Сеансу (S-CSCF). SCC AS вирішує надіслати виклик через доступ з PS (домен PS). Коли вузол завершення, тобто той, що викликає UE, приймає повідомлення INVITE і виявляє, що домен PS не є голосовим (наприклад, коли він розташований у Мережі Радіодоступу (GERAN) GSM EDGE), UE відхиляє INVITE. У стандарті ICS визначено також, що потім SCC AS встановлює INVITE у напрямку CSRN (маршрутний номер CS, базований на тому, який новий виклик буде спрямований до домену CS доступу UE), який потім взаємодіє з Функцією Контролю Медіашлюзу викликаного UE (B-MGCF) у CS SETUP до UE. Однак, в існуючому стандарті, встановлювальна процедура завершення створення сеансу не є оптимізованою. Наприклад, UE може вказати SCC-AS, чому саме цю проблему не вирішено і виклик має буди спрямований до домену CS того ж UE. Одним з можливих рішень є, наприклад, дозволити UE відповісти повідомленням про потребу іншого сервісу, відповіддю SIP 380, яка включає індикацію у формі індикації мовою XML. Однак, такий підхід вимагає додаткової стандартизації. Отже, задачею винаходу є створення удосконаленого механізму зміни доступу або домен з'єднання зв'язку для ремаршрутизації з'єднання. Вирішення цієї задачі визначено у Формулі винаходу. Зокрема, згідно з одним прикладом аспекту цього рішення, запропоновано, наприклад, пристрій, який включає: - передавач, конфігурований передавати повідомлення-вимогу ініціалізаці з'єднання для вузла, що завершує створення з'єднання зв'язку, для ініціалізації з'єднання зв'язку у першому домені зв'язку, - приймач конфігурований приймати відповідь на повідомлення-вимогу ініціалізації з'єднання і відповідь, що вказує відхилення типу медіапотоку цього з'єднання зв'язку у першому домені зв'язку і містить індикацію заздалегідь визначеної частини, - процесор, конфігурований обробляти прийняту відповідь, а також конфігурований перевіряти, чи виконано заздалегідь визначені умови, і, якщо так, викликати передачу іншого повідомлення-вимоги ініціалізації з'єднання для вузла, що завершує створення з'єднання зв'язку, для ініціалізації з'єднання зв'язку у другому домені зв'язку з відхиленим типом медіапотоку у з'єднанні зв'язку. Згідно з іншим прикладом аспекту рішення, запропоновано, наприклад, спосіб, який включає: - передачу повідомлення-вимоги ініціалізації з'єднання для вузла, що завершує створення з'єднання зв'язку, для ініціалізації з'єднання зв'язку у першому домені зв'язку, - прийом відповіді на повідомлення-вимогу ініціалізації з'єднання і відповіді, що вказує відхилення типу медіапотоку цього з'єднання зв'язку у першому домені зв'язку і містить індикацію заздалегідь визначеної частини, - обробку прийнятої відповіді і перевірку, чи виконано заздалегідь визначені умови, і, якщо так, - передачу іншого повідомлення-вимоги ініціалізації з'єднання для вузла, що завершує створення з'єднання зв'язку, для ініціалізації з'єднання зв'язку у другому домені зв'язку з відхиленим тиром медіапотоку у з'єднанні зв'язку. Згідно з подальшими уточненнями, ці приклади можуть включати один або більше таких деталей: - процесор або обробка можуть бути додатково конфігуровані, якщо заздалегідь визначені умови не виконано, викликати передачу повідомлення, яке вказує відхилення з'єднання зв'язку для вузла-ініціатора; - заздалегідь визначена індикативна частина може включати інформацію про тимчасову зміну контактної адреси вузла, що завершує створення з'єднання зв'язку; причому заздалегідь визначена індикативна частина може додатково включати адресну інформацію, включену у повідомлення-вимогу ініціалізації з'єднання, після чого процесор або обробка можуть бути додатково конфігуровані визначати, базуючись на адресній інформації, що з'єднання зв'язку 2 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 має бути ремаршрутизоване до того вузла, що завершує створення з'єднання зв'язку, у другому домені зв'язку; - в іншому варіанті заздалегідь визначена індикативна частин може включати інформацію про те, що спроба створення з'єднання зв'язку не є прийнятною тут; - заздалегідь визначені умови можуть включати щонайменшеодну з таких умов: - умову, що повідомлення-вимога ініціалізації з'єднання має включати параметр, який вказує останній відхилений тип медіапотоку з'єднання зв'язку, - умову, що повідомлення-відповідь має вказувати неуспіх доставки до вузла, що завершує створення з'єднання зв'язку, - умову, що повідомлення-відповідь не вказує, що користувацький вузол, який завершує створення з'єднання зв'язку, виконав операцію неприйняття з'єднання зв'язку, або що вузол, який завершує створення з'єднання зв'язку, є зайнятий, - умову, що повідомлення-відповідь не вказує конкретної дії іншого сервісу, - умову, що локальна конфігурація викликаного вузла, який завершує створення з'єднання зв'язку, є у пристрої, що дозволяє ремаршрутизацію до другого домену зв'язку, і - умову, що частина мережі зв'язку, яка веде до вузла, що завершує створення з'єднання зв'язку, вважається здатною надіслати тип медіапотоку вузла, що завершує створення з'єднання зв'язку у другому домені зв'язку; - перший домен зв'язку може бути базований на комутації переданих пакетів, а другий домен зв'язку може бути базований на комутації каналів зв'язку передач; - конкретним типом медіапотоку може бути аудіопотік; - пристрій або спосіб можуть бути частиною прикладного серверу для забезпечення централізації і безперервності сервісу. Згідно з іншим прикладом аспекту рішення, наприклад, запропоновано: - пристрій, що включає приймач, конфігурований приймати повідомлення-вимогу ініціалізації з'єднання, надіслане до вузла, що завершує створення з'єднання зв'язку, для ініціалізації з'єднання зв'язку у першому домені зв'язку, - процесор конфігурований обробляти повідомлення-вимогу ініціалізації з'єднання і додатково конфігурований визначати, чи є припустимим тип медіапотоку з'єднання зв'язку у першому домені зв'язку для вузла, що завершує створення з'єднання зв'язку, і, якщо він не є припустимим, процесор конфігурується викликати передачу передавачем відповіді на повідомлення-вимогу ініціалізації з'єднання, відповіді, що вказує відхилення цього тип медіапотоку для з'єднання зв'язку у першому домені зв'язку і включає заздалегідь визначену індикативну частину індикації вимоги ремаршрутизаці з'єднання зв'язку до другого домену зв'язку. Згідно з іншим прикладом аспекту рішення, запропоновано, наприклад, спосіб, що включає прийом повідомлення-вимоги ініціалізації з'єднання, надісланого до вузла, що завершує створення з'єднання зв'язку, для ініціалізації з'єднання зв'язку у першому домені зв'язку, обробку повідомлення-вимоги ініціалізації з'єднання, що визначає чи є тип медіапотоку з'єднання зв'язку у першому домені зв'язку, прийнятним для вузла, що завершує створення з'єднання зв'язку, і, якщо він не є прийнятним, передачу відповіді на і повідомлення-вимогу ніціалізації з'єднання, відповідь, що вказує відхилення типу медіапотоку з'єднання зв'язку у першому домені зв'язку і включає заздалегідь визначену індикативну частину індикації вимоги ремаршрутизації з'єднання зв'язку до другого домену зв'язку. Згідно з додатковими уточненнями, ці приклади можуть включати одну або більше таких деталей: - заздалегідь визначена індикативна частина може включати інформацію про тимчасову зміну контактної адреси вузла, що завершує створення з'єднання зв'язку; причому заздалегідь визначена індикативна частина може додатково включати адресну інформацію, включену у повідомлення-вимогу ініціалізації з'єднання; - в іншому варіанті заздалегідь визначена індикативна частин може включати інформацію, що спроба створення з'єднання зв'язку не є прийнятною тут; - перший домен зв'язку може бути базований на комутації пакетів передач, а другий домен зв'язку може бути базований на комутації каналів зв'язку передач; - конкретним типом медіапотоку може бути аудіопотік; - пристрій або спосіб можуть бути частиною вузла, що завершує створення з'єднання зв'язку, включаючи користувацьке обладнання; в іншому варіанті пристрій або спосіб можуть бути пов'язані з вузлом-посередником, з'єднаним з вузлом, що завершує створення з'єднання зв'язку. 3 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 60 Описані вище рішення дозволяють запропонувати спосіб і відповідний пристрій, які надають механізм зміни доступу до або домену з'єднання зв'язку для ремаршрутизації з'єднання, яке може бути базоване на існуючих протоколах сигналізації, наприклад, на таких елементах існуючого протоколу SIP, як SIP 302 або SIP 488. Це уможливлює реалізацію запропонованого механізму в існуючих елементах мережі, наприклад, UE або SCC AS, і не потребує складних змін у стандарті або нових розширень протоколу. Наприклад, у випадку SCC AS лише відповідні точка ініціації мають бути введені у маршрут до домену CS (CSRN). На інші елементи мережі запропонований механізм не впливає. Описані вище і інші об'єкти, деталі і переваги винаходу розглядаються у наведеному далі описі з посиланнями на креслення, в яких: фіг. 1 - схема сигналiзації у встановлювальній процедурі завершення створення сеансу зв'язку згідно з прикладом втілення винаходу, фіг. 2 - схема сигналiзації у встановлювальній процедурі завершення створення сеансу зв'язку згідно з альтернативним прикладом втілення винаходу, фіг. 3 - блок-схема прикладного серверу забезпечення централізації і безперервності сервісу згідно з прикладом втілення винаходу, фіг. 4 - блок-схема операцій встановлювальної процедури завершення створення сеансу згідно з прикладом втілення винаходу, фіг. 5 - блок-схема вузла, що завершує створення з'єднання зв'язку згідно з прикладом втілення винаходу і фіг. 6 - блок-схема операцій встановлювальної процедури завершення створення сеансу згідно з прикладом втілення винаходу. Далі розглядаються приклади і втілень винаходу з посиланнями на креслення. Для ілюстрації винаходу, приклади і втілення описано у сполученні з системою 3GPP, де з'єднання зв'язку або виклик вузла, що завершує створення з'єднання зв'язку, наприклад, UE з мережею IMS, встановлено або модифіковано. Однак, слід зауважити, що винахід не обмежується застосуванням таких систем або довкілля, але може бути використаний і в інших мережевих системах, типах з'єднань тощо, наприклад, у мережах згідно з специфікаціями 3GPP2. Базова системна архітектура мережі зв'язку 20, де може бути використаний винахід, може включати відому архітектуру мережі IMS, що підтримує ICS. Така мережева архітектура включає декілька вузлів контролю або CSCF, які є серверуми SIP або посередниками, що виконують декілька ролей (наприклад, опросна CSCF (I-CSCF), Посередник CSCF (P-CSCF), Сервісна CSCF (S-SCSF)) і використовуються для обробки сигнальних пакетів SIP у IMS. Крім того, MGCF, SCC AS тощо є частиною архітектури. Загальні функції і з'єднання цих елементів є відомими фахівцям, описані у документації, і тому не потребують опису. Однак, слід зауважити, що тут можуть бути додані декілька додаткових мережевих елементів і каналів сигналізації для з'єднань зв'язку, описаних нижче. Базова архітектура мережі зв'язку може включати відому архітектуру мережевої підсистеми провідного або безпровідного доступу. Така архітектура включає один або більш мережевих вузлів контролю доступу, мережеві елементи радіодоступу, шлюзи доступу до сервісу мережі або базової трансіверної станції, з якими можуть мати зв'язок мобільні станції або термінальні пристрої як абонентські користувацькі пристрої через один або більше каналів передачі декількох типів даних. Загальні функції і з'єднання цих елементів є відомими фахівцям, описані у документації, і тому не потребують опису. Однак, слід зауважити, що тут можуть бути додані декілька додаткових мережевих елементів і каналів сигналізації для з'єднань зв'язку викликів між кінцевими терміналами і/або серверуми. Мережеві елементи і їх функції, описані тут, можуть бути реалізовані програмно, наприклад, комп'ютерним програмним продуктом для комп'ютера, або схемно. У будь-якому випадку для виконання відповідних функцій використані пристрої, наприклад, UE або SCC AS, включають декілька засобів і компонентів (не показаних), необхідних для контролю, обробки і функцій зв'язку/сигналiзації. Такі засоби можуть включати, наприклад, процесорний вузол для виконання інструкцій програм і для обробки даних, засоби пам'яті для зберігання цих інструкцій і даних і для забезпечення робочої пам'яті для процесора тощо (наприклад ROM, RAM, EEPROM тощо), засоби вводу для введення даних і інструкцій програмою (наприклад, дискети, CD-ROM, EEPROM тощо), засоби користувацького інтерфейсу для моніторингу і маніпуляцій користувачем (наприклад, екран, клавіатура тощо), інтерфейсні засоби для встановлення зв'язків і/або з'єднань під контролем процесорного вузла (наприклад, провідні і безпровідні інтерфейсні засоби, антена тощо). Фіг. 1 містить схему сигналізації у встановлювальній процедурі завершення створення сеансу згідно з прикладом втілення винаходу. У цій процедурі використовуються наведені далі 4 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 мережеві елементи, але слід зазначити, що додаткові частини мережі використовуються також для встановлення сеансу як такого. Однак, для спрощення показано лише ті мережеві елементи, описані вище, функції яких є важливими для виконання запропонованої встановлювальної процедури завершення створення сеансу. Показано такі мережеві елементи: - вузол-ініціатор з'єднання зв'язку, наприклад, UE A, - викликаний вузол, що завершує створення з'єднання зв'язку, наприклад, UE B, - MGCF у мережі викликаного UE B (B-MGCF), - прикладний сервер для забезпечення централізації і безперервності сервісу, наприклад, SCC AS. Загальні функції і з'єднання цих елементів є відомими фахівцям, описані у документації, і тому не потребують опису. У встановлювальній процедурі завершення створення сеансу згідно з даним прикладом втілення винаходу, коли викликаючий вузол (UE A на фіг. 1) бажає, наприклад, мати з'єднання зв'язку з конкретним типом медіапотоку, наприклад, аудіо для мовної передачі, він надсилає відповідне повідомлення з ініціалізацією з'єднання зв'язку (Mil) до бажаного викликаного вузла, тобто вузла, що завершує створення з'єднання зв'язку (UE B на фіг. 1). Коли використовується IMS, повідомленням з ініціалізацією з'єднання зв'язку є, наприклад, повідомлення SIP INVITE. Завершуючий вузол - прикладний сервер забезпечення централізації і безперервності сервісу (B-SCC AS) приймає повідомлення з ініціалізацією з'єднання (повідомлення SIP INVITE) від UE B через інші мережеві елементи, наприклад S-CSCF (не показані). B-SCC AS може вирішити спрямувати виклик через доступ з PS (домен PS, перший домен) до викликаного UE B (повідомлення M12). У випадку прийому повідомлення INVITE, завершуюче UE B визначає, базуючись на інформації, включеній у повідомлення INVITE, наприклад, параметри з'єднання, індикатори медіапотоку, домен доступу тощо, і перевіряє, чи є доступ з PS, обраний SCC AS, придатним для голосової передачі (аудіопотоку). В іншому варіанті або додатково UE B перевіряє, чи може UE B визначати тип медіапотоку, наприклад, VoIP. У випадку визначення у UE B здатності до з'єднання зв'язку при зазначених параметрах є позитивним, тобто з'єднання зв'язку може бути встановлене з UE B через доступ з PS, встановлення сеансу може бути завершене у звичайний спосіб, визначений у декількох стандартах. Однак, у випадку негативного визначення, тобто непридатності доступу з PS для аудіо або нездатності UE створити потрібне з'єднання, UE B надсилає спеціальну негативну відповідь (M13) до джерела виклику B-SCC AS для відхилення вимоги ініціалізації поточного з'єднання зв'язку. Згідно з даним прикладом втілення винаходу, наприклад, спеціальна негативна відповідь включає спеціальний відповідний код SIP, який вказує, що контактну адресу UE B (викликаного вузла, що завершує створення з'єднання зв'язку) тимчасово змінено, тобто включає повідомлення SIP 302. У повідомленні SIP 302 у заголовку контактної адреси додатково зазначено, що було прийнято у заголовку вимоги INVITE (ID викликаного вузла). Це означає, що UE B інструктує мережу переспрямувати виклик до того ж призначення. Отже, завдяки такій "петлі" SCC AS може ремаршрутувати виклик до домену CS (другий домен) того ж абоненту, як це описано нижче. Після прийому (негативного) повідомлення-відповіді від UE B B-SCC AS обробляє контенти повідомлення M13 і перевіряє заздалегідь визначену групу умов. Інакше кажучи, B-SCC AS визначає, дотримано таких умов: - повідомлення-вимога ініціалізації з'єднання включає параметр, що вказує останній відхилений тип медіапотоку з'єднання зв'язку, тобто, наприклад, первісне повідомлення SIP INVITE включає параметр SDP, що вказує аудіо, тобто m=аудіо; - повідомлення-відповідь вказує неуспіх доставки вузла, що завершує створення з'єднання зв'язку, наприклад, повідомлення SIP 302 (або інше повідомлення SIP, описане далі) яке вказує неуспіх доставки до UE B; - повідомлення-відповідь не вказує, що користувач вузла, що завершує створення з'єднання зв'язку виконав операцію неприйняття з'єднання зв'язку (наприклад, кінцевий користувацький UE не хоче приймати виклик і виконує у UE відповідну операцію відхилення сеансу), або що вузол, який завершує створення з'єднання зв'язку є зайнятим, тобто повідомлення-відповідь SIP не має коду типу SIP 603 (відхилено) або SIP 486 (зайнято); - повідомлення-відповідь не вказує іншого конкретного сервісу, наприклад, індикації різних адрес призначення для ремаршрутизації виклику, або іншого кодеку для аудіокомпоненту 5 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 60 медіапотоку (наприклад, іншого призначення ремаршрутизації у відповіді SIP, наприклад, SIP 302 і SIP 301 (змінено), або альтернативного голосового кодеку у повідомленні SIP 488); - є локальна конфігурація викликаного вузла, що завершує створення з'єднання зв'язку, яка дозволяє ремаршрутизацію до іншого домену зв'язку, тобто B-SCC AS має локальну конфігурацію для користувацького UE B, яке у випадку відхилення виклику має бути ремаршрутизоване до домену CS; - вважається, що частина мережі зв'язку, яка веде до вузла, що завершує створення з'єднання зв'язку (UE B), може доставляти певний тип медіапотоку (тут аудіо) до вузла, що завершує створення з'єднання зв'язку UE B, у другий домен зв'язку (домен CS), тобто B-SCC AS не має інформації про те, що, наприклад, B-MGCF не може доставляти виклики з CS, наприклад, що відсутні будь-які вимоги, яких не може виконати B-MGCF. Згідно з даним прикладом втілення винаходу, для отримання позитивного результату перевірки, вважається, що всі перелічені вище умови мають бути виконані, тобто існує зв'язок між цими умовами. В іншому варіанті можливим є також випадок (у ще одному прикладі втілення винаходу), коли одна або більше зазначених вище умов можуть бути відкинуті або коли може бути встановлений зв'язок між щонайменше деякими з цих умов. Слід зазначити, що наведений вище перелік не є вичерпним, тобто можуть існувати і інші умови, замість або у додаток до описаних умов, наприклад, умови заряджання тощо. Залежно від результату перевірки умов, B-SCC AS може проводити різні додаткові обробки, тобто у випадку позитивного результату перевірки, тобто виконання усіх умов, SCC AS переспрямовує з'єднання зв'язку до другого (CS) домену і готує відповідну вимогу INVITE до CSRN (Номер роумінгу у Комутації каналів зв'язку) UE B. Для цього SCC AS спрямовує повідомлення SIP INVITE з CSRN до B-MGCW (повідомлення M14), яке виконує процедуру встановлення CS з UE B (повідомлення M15). Якщо результат перевірки негативний, B-SCC AS повертає негативну (відхилення) відповідь від UE B назад до вузла виклику (UE А) (не показано на фіг. 1). Внаслідок цього, наприклад, прикладний сервер або вузол виклику UE A може виконувати відповідне обслуговування (наприклад CFNR (Мобільний Абонент Недоступний для пересилання виклику), CFB у TAS (Зайнято для Пересилання виклику Телефонному Прикладному Серверу)) Інший приклад втілення описано з посиланнями на фіг. 2, яка додатково містить схему сигналізації для іншого прикладу встановлювальної процедур завершення створення сеансу. У цій процедурі мережеві елементи і функції є еквівалентними описаним на фіг. 1, але для UE B опис повідомлення M13a з описом еквівалентних елементів і частин є відсутнім для спрощення. Згідно з прикладом, ілюстрованим фіг. 2, після прийому повідомлення з ініціалізацією з'єднання зв'язку (повідомлення M12), коли UE B вирішує, що доступ з PS є неприйнятним для аудіо або UE не може виконати потрібне з'єднання, UE B надсилає іншу спеціальну негативну відповідь (M13a) до B-SCC AS для відхилення вимоги ініціалізації поточного з'єднання зв'язку. У цьому прикладі така негативна відповідь включає спеціальний код відповіді SIP Відповідь з індикацією того, що спроба створення з'єднання зв'язку до UE B (викликаний вузол, що завершує створення з'єднання зв'язку) не є прийнятною, є, наприклад відповіддю SIP 488 (Неприйнятно тут). Це повідомлення M13a не включає тіло SDP з індикацією типу медіапотоку, тобто m-line індикацією аудіо. Це означає, що B-SCC AS визнає, що потрібні ресурси PS для аудіо не можуть бути надані, і тому B-SCC AS має ремаршрутувати до домену CS. Структура і функція мережевого елементу, відповідного до прикладного серверу забезпечення централізації і безперервності сервісу (B-SCC AS) описано нижче (фіг. 3 і 4). Фіг. 3 містить блок-схему прикладного серверу забезпечення централізації і безперервності сервісу 2, наприклад B-SCC AS з фіг. 1, згідно з прикладом втілення винаходу. Слід зазначити, що прикладний сервер забезпечення централізації і безперервності сервісу може включати декілька додаткових елементів або функцій окрім описаних на фіг. 3, які не розглядаються, оскільки є несуттєвими для винаходу. Прикладний сервер забезпечення централізації і безперервності сервісу 2 (далі - SCC AS) згідно з фіг. 3 включає функцію обробки або процесор 21, наприклад, CPU тощо, який виконує інструкції програми для обробки, показаної на фіг. 4 (описаної нижче). Процесор 21 використовується для обробки інформації з повідомлень Mil і M13/M13a і для формування повідомлень M12 і M14 (фіг. 1 і 2). Вузли 22 і 23 входу/виходу приєднано до процесора 21.Вузол 22 може бути використаний для зв'язку з мережею (наприклад, з мережевими елементами, з'єднаними з вузлом UE A виклику, де може бути прийняте повідомлення INVITE Mil). Вузол 23 може бути використаний для зв'язку з UE B (або проміжним посередником для UE B), наприклад, через B-MGCF (повідомлення INVITE M12 і M14 можуть бути прийняті через цей 6 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 вузол, як і повідомлення-відповідь M13/M13a). Вузли 22 і 23 входу/виходу можуть бути об'єднані в один елемент, наприклад, трансіверний вузол тощо. Пам'ять 24 може бути використана, наприклад, для зберігання даних і програм, що мають бути виконані процесор 21, і/або як робоча пам'ять процесора 21. Перевірна частина 25 перевіряє виконання умов для визначення, чи виконано заздалегідь визначені. Негативна відповідь приймається від, наприклад, UE B. Частина 26 зміни домену у відповідь на результат перевірки виконання умов 25 і інформацію, отриману від первісного повідомлення INVITE Mil, адаптована визначати до якого домену має бути виконана ремаршрутизація зв'язку (тут описано зміну на домен CS). Фіг. 4 містить блок-схему операцій способу, який реалізовано пристроєм, що включає елементи і функції прикладного серверу забезпечення централізації і безперервності сервісу (фіг. 3) у встановлювальній процедурі завершення створення сеансу згідно з прикладом втілення винаходу. Операцією S10 після прийому відповідного повідомлення-вимоги ініціалізації з'єднання від вузла виклику, наприклад, через вузол 22 входу/виходу, повідомлення-вимога ініціалізації з'єднання (SIP INVITE) приймається для створення з'єднання зв'язку з вузлом, що його завершує (UE B), наприклад, через вузол 23 входу/виходу. Операцією S20 приймається відповідь на повідомлення-вимогу ініціалізації з'єднання, наприклад через вузол 23 входу/виходу. Процесор 21 визначає, що ця відповідь вказує відхилення з'єднання зв'язку, тобто тип медіапотоку (наприклад, аудіо), у першому домені зв'язку (домен PS). Крім того, він визначає, що відповідь включає заздалегідь визначену індикативну частину, наприклад, частину SIP 302 або SIP 488, як було описано вище. Після додаткової обробки прийнятої відповіді (опер. S30), процесор перевіряє (перевірна частина 25), чи виконано заздалегідь визначені умови, як це описано вище. Якщо заздалегідь визначені умови виконано (опер. S40, ТАК), процесор 21 ініціює операцією S50 передачу іншого повідомлення-вимоги ініціалізації з'єднання до вузла, що завершує створення з'єднання зв'язку (UE B) через вузол 23 входу/виходу для ініціалізації з'єднання зв'язку у другому домені зв'язку (домен CS, вибраний частиною 26 зміни домену) з відхиленням типу медіапотоку (аудіо). У випадку, коли перевірка операціями S30, S40 дає негативний результат (опер. S40, НІ), тобто якщо заздалегідь визначені умови не виконано, процесор ініціює передачу повідомлення, яке вказує відхилення з'єднання зв'язку, до вузла виклику, тобто вузла-ініціатора UE A з'єднання зв'язку. Далі розглядаються структура і функції мережевого елемента, що відповідає вузлу, який завершує створення з'єднання зв'язку (UE B) (фіг. 5 і 6). Фіг. 5 містить блок-схему вузла 1, що завершує створення з'єднання зв'язку, наприклад UE B (фіг. 1), згідно з прикладом втілення винаходу. Слід відзначити, що такий вузол може включати декілька додаткових елементів або функцій окрім описаних, але вони не описані, оскільки не є суттєвими для винаходу. Вузол 1, що завершує створення з'єднання зв'язку (далі - UE B) згідно з фіг. 5 включає функцію обробки або процесор 11, наприклад, CPU тощо, який виконує інструкції програми для обробки, показаної на фіг. 6 (і описаної далі). Процесор 11, зокрема, використовується для обробки інформації, наданої повідомленнями M12 і M15, і для формування повідомлень M13/M13a згідно з фіг. 1 і 2. Вузол 12 (входу/виходу), приєднаний до процесора 11, може бути використаний для зв'язку з мережею (наприклад, з прикладним сервером забезпечення централізації і безперервності сервісу (SCC AS) або MGCW). Пам'ять 13 використовується для, наприклад, зберігання даних і програм, що мають виконуватись процесором 11 і/або як робоча пам'ять процесора 11. Частина 14 перевірки медіапотоку визначає, чи є потік у з'єднанні зв'язку таким, як потрібно, зокрема, вказаного типу, тобто чи може бути виконане з'єднання через спеціальний домен зв'язку, наприклад, домен PS. Частину 15 формування відповіді на результат перевірки медіапотоку частиною 14 і на інформацію, отриману з первісного повідомлення INVITE M12, адаптовано формувати відповідь на повідомлення-вимогу ініціалізації з'єднання, вказуючи відхилення з'єднання зв'язку, тобто типу медіапотоку (наприклад, аудіо) у першому домені зв'язку (домен PS), і включати заздалегідь визначену індикативну частину, наприклад, повідомлення SIP 302 або SIP 488. Фіг. 6 містить блок-схему операцій способу, що реалізується пристроєм, який включає елементи і функції UE B (фіг. 5) у встановлювальній процедурі завершення створення сеансу згідно з прикладом втілення винаходу. Операцією S110 приймається повідомлення-вимога ініціалізації з'єднання від вузла виклику (тобто SCC AS), наприклад, через вузол 12 входу/виходу. 7 UA 101880 C2 5 10 15 20 25 30 35 40 45 50 55 Операцією S120 повідомлення-вимога ініціалізації з'єднання обробляється процесором 11, який визначає, чи є відповідає потік з'єднання зв'язку вимогам. Як описано вище, наприклад, частина 14 перевірки медіапотоку перевіряє, чи може UE B забезпечити потрібний тип з'єднання і/або чи є доступ з PS придатним для цього з'єднання або для потрібного типу медіапотоку (наприклад, аудіо). Відповідь на повідомлення-вимогу ініціалізації з'єднання приймається, наприклад, через вузол 23 входу/виходу. Процесор 21 визначає, що відповідь містить відхилення з'єднання зв'язку, тобто типу медіапотоку (наприклад, аудіо), у першому домені зв'язку (домен PS). Якщо визначено, що з'єднання зв'язку згідно з вимогою, є можливим (опер. S130: ТАК), операцією S150 виконується стандартна процедура встановлення з'єднання зв'язку. В іншому разі, тобто у разі неможливості забезпечення з'єднання зв'язку згідно з вимогою (опер. S130: НІ), частина 15 формує негативну відповідь для відхилення такого з'єднання зв'язку (наприклад, для аудіопотоку) у першому (PS) домені. Ця відповідь включає заздалегідь визначену індикативну частин, наприклад, повідомлення SIP 302 або SIP 488, як описано вище, для виконання ремаршрутизації виклику до другого (CS) домену. Слід зазначити, що в описаних прикладах визначення неможливості створення потрібного з'єднання зв'язку і передача відповідної негативної відповіді, наприклад, у формі повідомлення SIP 302 або SIP 488, виконується самим UE B. Однак, винахід припускає і інші конфігурації. Наприклад, визначення прийнятності або неприйнятності доступу з PS для потрібного з'єднання зв'язку може бути також виконане перед вузлом, що завершує сеанс (UE B) у мереж, наприклад, у проміжному посереднику типу P-CSCF, який, наприклад, не прийняти вимоги, і тоді цей проміжний посередник повертає негативну відповідь. Додатково обробка у SCC AS, наприклад, є еквівалентною описаній для фіг. 1 або фіг. 3 і 4, опис функції і конструкції проміжного посередника ілюструється фіг. 5 і 6 (стосовно UE B). Слід зауважити, що спосіб доступу може бути будь-яким способом, яким користувацьке обладнання може отримати доступ до мережі (наприклад, через базову станцію або вузол загального доступу). Для цього можуть бути використані будь-які існуючі або майбутні технології, наприклад, WLAN (Локальна Мережа Безпровідного Доступу), WiMAX (Світова Інтеропрабільність для Мікрохвильового Доступу), BlueTooth, Infrared тощо; хоча описані вище технологі є технологіями безпровідного доступу, наприклад, у різних радіоспектрах, винахід включає також технології провідного зв'язку, наприклад, базовані на ІР технології доступу для кабельних мереж або стаціонарних ліній, а також технології з комутацією каналів зв'язку; технології доступу можуть бути розділені на щонайменше дві категорії або домени доступу, наприклад, з комутацією пакетів і комутацією каналів зв'язку, але наявність більш, ніж двох доменів доступу також є прийнятною для винаходу. При цьому: - доступ до мереж може забезпечувати будь-як пристрій, вузол або засіб, якими станція, вузол або інше користувацьке обладнання може приєднуватись до сервісу і/або використовувати сервіси, запропоновані мережею; такі сервіси включають, проміж іншим, дані і/або (аудіо-)відео зв'язок, завантаження даних тощо; - користувацьким обладнанням (або мобільною станцією) може бути будь-який пристрій, вузол або засіб, якими користувач системи може отримувати обслуговування від мереж доступу, наприклад, мобільний телефон, персональний цифровий секретар (PDA) або комп'ютер; - операції, які можуть бути застосовані як частини програмного коду і використані процесором у мережевому елементі або терміналі (наприклад, його пристроях і/або модулях, або, наприклад, у вузлах, що включають відповідні пристрої і/або модулі), є незалежними від програмного коду і можуть бути конкретизовані для будь-якого відомої або майбутньої мови програмування з збереженням функцій, передбачених цими операціями; - взагалі будь-які операції можуть бути реалізовані програмно або схемно без відхилення від функціональних концепцій винаходу; - операції і/або пристрої, вузли або засоби бажано реалізувати як схемні компоненти у терміналі або мережевому елементі, або будь-яких їх модулях, з використанням будь-якої відомої або майбутньої схемної технології або будь-яких їх гібридів, наприклад, MOS (Металооксидні Напівпровідники), CMOS (Комплементарні MOS), BiMOS (Біполярні MOS), BiCMOS (Біполярні CMOS), ECL (Емітерна логіка), TTL (Транзистор-транзисторна Логіка) тощо, з використанням, наприклад, компонентів ASIC (Прикладна Спеціалізована IC (Інтегральна Схема)), компонентів FPGA (Програмовані Вентильні Матриці), компонентів CPLD (Комплексни Програмований Логічний Пристрій) або компонентів DSP (Процесор Цифрових Сигналів); крім того, операції і/або пристрої, вузли або засоби можуть бути реалізовані як програмні 8 UA 101880 C2 5 10 15 20 компоненти, базовані на будь-якій безпечній архітектурі, наприклад, з захищеними аутентифікацією, авторизацією, використанням ключів і/або трафіком; - пристрої, вузли або засоби можуть бути виконані як індивідуальні пристрої, вузли або засоби, але це не виключає іх розподілення у системі за умови збереження функцій цих пристроїв, вузлів або засобів; - пристрій може бути виконаний як напівпровідникова інтегральна схема, або (схемний) модуль, що включає такі схеми або набори схем, однак, не виключається можливість реалізації функцій пристроїв або модулів не схемно, а програмно як програмних модулів, наприклад, комп'ютерних програм або комп'ютерного програмного продукту, який включає виконавчі частини програмного коду, що виконуються процесором; - пристрій можна розглядати як пристрій або як вузол з декількох пристроїв, з функціональністю, зумовленою їх кооперацією один з одним або функціональної незалежністю один від одного в одному модулі. Отже, запропоновано спосіб і відповідні пристрої, що дозволяють перехід від домену комутації пакетів зв'язку до домену комутації каналів зв'язку. Коли користувацьке обладнання, пов'язане з термінальним пунктом визначає прийом повідомлення з ініціалізацією з'єднання для медіапотоку, наприклад, аудіо, яке не може бути забезпечене доступом з комутацією пакетів, воно надсилає відповідь, якою відхиляє з'єднання через доступ з комутацією пакетів до прикладного серверу забезпечення централізації і безперервності сервісу. У прикладному сервері здійснюється перевірка виконання декількох умов для визначення, чи дозволяє з'єднання зв'язку, яке включає медіапотік, перехід на доступ з комутацією каналів. Якщо так, з'єднання зв'язку змінюється з домену комутації пакетів на домен з комутацією каналів зв'язку. Винахід був описаний на прикладах окремих втілень, але винахід не обмежується ними і припускає різні модифікації. 25 ФОРМУЛА ВИНАХОДУ 30 35 40 45 50 55 1. Мобільна станція, яка включає: - приймальний засіб для прийому повідомлення-вимоги ініціалізації з'єднання, надісланого до мобільної станції для ініціалізації з'єднання зв'язку у першому домені зв'язку, - обробний засіб для обробки повідомлення-вимоги ініціалізації з'єднання, додатково конфігурований визначати, чи є можливим тип медіапотоку з'єднання зв'язку у першому домені зв'язку для мобільної станції і, якщо тип медіапотоку з'єднання зв'язку у першому домені зв'язку для мобільної станції не є можливим, обробний засіб конфігурований - викликати передачу передавальним засобом відповіді на повідомлення-вимогу ініціалізації з'єднання, яка містить індикацію відхилення цього типу медіапотоку з′єднання зв′язку у першому домені зв′язку і включає заздалегідь визначену індикативну частину, яка містить вимогу ремаршрутизації з'єднання зв'язку до другого домену зв'язку. 2. Мобільна станція за п. 1, в якій заздалегідь визначена індикативна частина містить інформацію, що контактна адреса вузла, який завершує створення з'єднання зв'язку, тимчасово змінена. 3. Мобільна станція за п. 2, в якій заздалегідь визначена індикативна частина додатково включає адресну інформацію, включену у повідомлення-вимогу ініціалізації з'єднання. 4. Мобільна станція за п. 1, в якій заздалегідь визначена індикативна частина містить інформацію, що спроба з'єднання зв'язку не є прийнятною тут. 5. Мобільна станція за п. 1, в якій перший домен зв'язку базований на комутації пакетів передач, а другий домен зв'язку базований на комутації каналів зв'язку для передач. 6. Мобільна станція за п. 5, в якій конкретним типом медіапотоку є медіапотік типу аудіо. 7. Мобільна станція за п. 1, в якій додатково введено прокси-сервер. 8. Мобільна станція за будь-яким одним з пп. 1-4, в якій повідомлення-вимога ініціалізації зв′язку включає повідомлення INVITE, яке мобільна станція одержує з серверу централізованого обслуговування і цілісності прикладних програм. 9. Мобільна станція за будь-яким одним з пп. 1-5, в якій передавальний засіб забезпечує передавання запиту з мобільної станції до терміналу серверу централізованого обслуговування і цілісності прикладних програм. 10. Мобільна станція за будь-яким одним з пп. 1-6, яку конфігуровано для застосування протоколу ініціалізації сесії, SIP, при звертанні до підсистеми мультимедійного інтернетпротоколу. 11. Спосіб зв′язку, який включає: 9 UA 101880 C2 5 10 15 20 25 30 - прийом в мобільній стації повідомлення-вимоги ініціалізації з'єднання, надісланого до мобільної станції для ініціалізації з'єднання у першому домені зв'язку, - обробку повідомлення-вимоги ініціалізації з'єднання в мобільній станції, - визначення в мобільній станції, чи є можливим тип медіапотоку з'єднання зв'язку у першому домені зв'язку для мобільної станції і, якщо тип медіапотоку з'єднання зв'язку у першому домені зв'язку для мобільної станції не є можливим, - передавання з мобільної станції відповіді на повідомлення-вимогу ініціалізації з'єднання, яка містить індикацію відхилення цього типу медіапотоку з'єднання зв'язку у першому домені зв'язку і включає заздалегідь визначену індикативну частину, яка містить вимогу ремаршрутизації з'єднання зв'язку до другого домену зв'язку. 12. Спосіб за п. 11, в якому заздалегідь визначена індикативна частина містить інформацію, що контактна адреса вузла, що завершує створення з'єднання зв'язку, тимчасово змінена. 13. Спосіб за п. 12, в якому заздалегідь визначена індикативна частина додатково включає адресну інформацію, включену у повідомлення-вимогу ініціалізації з'єднання. 14. Спосіб за п. 11, в якому заздалегідь визначена індикативна частина містить інформацію, що спроба з'єднання зв'язку не є прийнятною тут. 15. Спосіб за п. 11, в якому перший домен зв'язку базований на комутації пакетів передач, а другий домен зв'язку базований на комутації каналів зв'язку для передач. 16. Спосіб за п. 11, в якому конкретним типом медіапотоку є медіапотік типу аудіо. 17. Спосіб за п. 11, який здійснюють в прокси-вузлі, що підключений до вузла, що завершує створення з′єднання зв′язку. 18. Спосіб за будь-яким одним з пп. 11-14, в якому одержання повідомлення-вимоги ініціалізації зв′язку включає повідомлення INVITE з вхідної сторони серверу централізованого обслуговування і цілісності прикладних програм. 19. Спосіб за будь-яким одним з пп. 11-15, в якому передавання включає передавання запиту до вхідної сторони серверу централізованого обслуговування і цілісності прикладних програм. 20. Спосіб за будь-яким одним з пп. 11-16, який додатково включає використання в мобільній станції протоколу ініціалізації сесії, SIP, при звертанні до підсистеми мультимедійного інтернетпротоколу. 21. Машинозчитувальний носій інформації, який містить програмні кодові частини для здійснення в комп′ютері операцій способу за будь-яким з пп. 11-20. 10 UA 101880 C2 11 UA 101880 C2 12 UA 101880 C2 13 UA 101880 C2 14 UA 101880 C2 15 UA 101880 C2 Комп’ютерна верстка Л. Бурлак Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 16