RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 1924032 (96) Data i numer zgłoszenia patentu europejskiego: 10.01.2007 07702029.5 (13) (51) T3 Int.Cl. H04L 12/46 (2006.01) H04M 3/42 (2006.01) Urząd Patentowy Rzeczypospolitej Polskiej (97) O udzieleniu patentu europejskiego ogłoszono: 18.05.2011 Europejski Biuletyn Patentowy 2011/20 EP 1924032 B1 (54) Tytuł wynalazku: SPOSÓB, URZĄDZENIE I SYSTEM DO ŁĄCZENIA SIĘ Z WYWOŁYWANYM UŻYTKOWNIKIEM (30) Pierwszeństwo: 10.01.2006 CN 200610000279 (43) Zgłoszenie ogłoszono: 21.05.2008 w Europejskim Biuletynie Patentowym nr 2008/21 (45) O złożeniu tłumaczenia patentu ogłoszono: 30.11.2011 Wiadomości Urzędu Patentowego 2011/11 (73) Uprawniony z patentu: Huawei Technologies Co., Ltd., Shenzhen, CN (72) Twórca(y) wynalazku: PL/EP 1924032 T3 DONGMING ZHU, Shenzhen, CN XIAOQIN DUAN, Shenzhen, CN (74) Pełnomocnik: rzecz. pat. Dorota Rzążewska JAN WIERZCHOŃ & PARTNERZY BIURO PATENTÓW I ZNAKÓW TOWAROWYCH ul. Żurawia 47/49 00-680 Warszawa Uwaga: W ciągu dziewięciu miesięcy od publikacji informacji o udzieleniu patentu europejskiego, każda osoba może wnieść do Europejskiego Urzędu Patentowego sprzeciw dotyczący udzielonego patentu europejskiego. Sprzeciw wnosi się w formie uzasadnionego na piśmie oświadczenia. Uważa się go za wniesiony dopiero z chwilą wniesienia opłaty za sprzeciw (Art. 99 (1) Konwencji o udzielaniu patentów europejskich).
12474/11/P-RO/DR/JM EP 1 924 032 SPOSÓB, URZĄDZENIE I SYSTEM DO ŁĄCZENIA SIĘ Z WYWOŁYWANYM UŻYTKOWNIKIEM Dziedzina Techniki [0001] Niniejszy wynalazek odnosi się do technologii komunikacyjnych, a w szczególności do sposobu, urządzenia i systemu sieciowego do dostarczania zapytania o usługę. Tło Wynalazku [0002] Od Wydania 5 (Release 5, R5) Projektu Partnerstwa 3-ej Generacji (3 rd Generation Partnership Project, 3GPP), sieć szkieletowa Uniwersalnego Systemu Telekomunikacji Ruchomej (Universal Mobile Telecommunications System, UMTS) została podzielona na trzy podsystemy: domenę komutacji łączy (Circuit Switched, CS), domenę komutacji pakietów (Packet Switched, PS) i Podsystem IP Multimediów (IP Multimedia Subsystem, IMS). [0003] Domenę CS wykorzystuje się do zapewniania użytkownikom połączeń usługi komutacji łączy. Domena CS obejmuje: Mobilne Centrum Komutacji (Mobile Switching Center, MSC) (które może być ponadto podzielone na serwer MSC i CS - Media Gateway Function (CS - MGW)) przeprowadzające komutację i funkcje kontroli sygnalizacji w usługach komutacji łączy; Węzłowe Mobilne Centrum Komutacji (Gateway Mobile Switching Center, GMSC), które jest MSC stosowanym do routingu i adresowania w sieci i może być zintegrowane z MSC lub być niezależnym urządzeniem; oraz InterWorking Function, która jest ściśle połączone z MSC i stosowana do współdziałania pomiędzy siecią Public Land Mobile Network (PLMN) a siecią Integrated Service Digital Network
2 (ISDN), publiczną komutowaną siecią telefoniczną (Public Switched Telephone Network, PSTN) lub publiczną siecią danych (Public Data Network, PDN) i to głównie w celu konwertowania sygnału: określone funkcje IWF zmieniają się w zależności od różnych usług i sieci. [0004] Domenę PS wykorzystuje się do zapewniania użytkownikom połączeń usługi komutacji pakietów. Domena PS obejmuje: węzeł wsparcia GPRS (General Packet Radio Service) GSN (GPRS Support Node) (obejmujący Serwerowy GSN (Serving GSN, SGSN) i Bramkowy GSN (Gateway GSN, GGSN)) oraz Węzeł Brzegowy (Border Gateway, BG). [0005] SGSN i GGSN wykorzystuje się do transmisji pakietów danych dla użytkowników usługi komutacji pakietów; usługa GSN (SGSN) zapewnia połączenie między Siecią Szkieletową a Systemem Dostępu Radiowego takim jak system stacji bazowych (Base Station Subsystem, BSS) lub system sieci radiowych (Radio Network Subsystem, RNS), pełni funkcje zarządzania mobilnością i zarządzania sesją w usługach danych komutacji pakietów oraz zarządza mobilnością i usługami komunikacyjnymi Stacji Mobilnej (Mobile Station, MS) w sieci bezprzewodowej; GGSN działa jak interfejs między systemem komunikacji mobilnej i innymi PDN, a dodatkowo pełni funkcję informowania o zapytaniach o położenie; zarówno SGSN, jak i GGSN mogą dostarczać informacje taryfikacyjne. [0006] Węzeł Brzegowy (BG) stosuje się do celów współdziałania między dwiema sieciami GPRS i zapewniania bezpieczeństwa współdziałania sieci. [0007] Dodatkowo, wspólne jednostki funkcjonalne dzielone przez domenę CS i domenę PS obejmują: Rejestr Abonentów Macierzystych/Centrum Uwierzytelniania (Home Location Register/Authentication Center, HLR/AuC). HLR stosuje się do zarządzania danymi o abonamencie i informacji o położeniu. Dane o abonamencie obejmują co najmniej jedno spośród: Międzynarodowego Numeru ISDN Stacji Mobilnej (Mobile Station International ISDN Number, MSISDN), Międzynarodowej Tożsamości Mobilnego Abonenta (International Mobile Subscriber Identity, IMSI), Adres Protokołu Danych Pakietowych (Packet Data Protocol Address, PDP ADDRESS), abonowane usługi telefoniczne, dodatkowe usługi i tak dalej. Informacja o położeniu może obejmować: numer Mobilnego Centrum Komutacji/Rejestru Położenia Odwiedzających (MSCNLR) lub adres Węzłowego Mobilnego Centrum Komutacji (GMLC). AuC wykorzystuje się do przechowywania algorytmu autoryzacji i klucza użytkownika.
3 [0008] Wspólne jednostki funkcjonalne dzielone przez zarówno domenę CS, jak i domenę PS obejmują także Rejestr Położenia Odwiedzających (Visitor Location Register, VLR) do obsługi rozmaitych danych abonentów odwiedzanych w danym momencie, Rejestr Tożsamości Wyposażenia (Equipment Identity Register, EIR) do przechowywania tożsamości wyposażenia użytkownika, taki jak Międzynarodowa Tożsamość Wyposażenia Stacji Mobilnej (International Mobile station Equipment Identity, IMEI) i Węzłowe MSC Usługi Krótkich Wiadomości (Short Message Service Gateway MSC, SMSGMSC/SMS IMSC). [0009] IMS jest podsystemem dodanym w 3GPP R5 na bazie istniejącej domeny PS. IMS wykorzystuje domenę PS jako kanał B dla transmisji swojej sygnalizacji kontrolnej górnego poziomu i danych o mediach, jako protokół kontroli usługi IMS stosuje Protokół Inicjacji Sesji (Session Initiation Protocol, SIP) i zapewnia abonentom obfite usługi multimedialne poprzez oddzielanie kontroli usługi od kontroli abonenta i poprzez wykorzystanie właściwości SIP, tj. prostej, rozszerzalnej i dogodnej dla mediów kombinacji. Główne jednostki funkcjonalne IMS obejmują: Funkcję Kontroli Sesji Połączenia (Call Session Control Function, CSCF) do kontroli rejestracji abonenta oraz kontroli sesji, Serwer Aplikacji (AS) do różnych rodzajów kontroli logicznej usługi, Domowy Serwer Abonenta (Home Subscriber Server, HSS) do zarządzania abonamentem abonenta w sposób scentralizowany oraz Funkcję Kontroli Węzła Mediów (Media Gateway Control Function, MGCF) oraz Węzeł Mediów IMS (IMS Media Gateway, IM- MGW) do współdziałania między IMS a domeną CS. Abonent może łączyć się z IMS poprzez proxy CSCF (P-CSCF) w odwiedzanej sieci, a kontrola sesji, kontrola wywołania usługi i oddziaływanie AS z kontrolą usługi są następnie przeprowadzane przez obsługujący CSCF (serving CSCF, S-CSCF) sieci domowej. HSS w IMS, którego funkcjonalności obejmują funkcjonalności HLR, jest nadrzędnym zbiorem wobec HLR. Jednakże ze względu na czynnik procesów sieciowych i tym podobne, HSS w IMS i HLR w domenie CS/PS mogą być rozwinięte jako jednostki niezależne od siebie w praktycznych projektach sieciowych. [0010] Architektura IMS wyznaczona przez 3GPP rozwiązuje wszystkie kluczowe problemy operacyjności usługi multimedialnej przez IP, takie jak taryfikacja za roaming, QoS i bezpieczeństwo. Zatem ta architektura i odpowiadająca jej idea są uznane przez przemysł. Zarówno 3GPP2, jak i TISPAN wyznaczają odpowiednią architekturę sieci
4 multimedialnej IP i systemy usług według modelu 3GPP i w odniesieniu do modelu 3GPP. W tym samym czasie 3GPP rozpoczęło badania nad współdziałaniem dostępu WLAN z systemem 3GPP (I-WLAN), Stałym Szerokopasmowym dostępem do IMS (Fixed Broadband IMS, FBI) i siecią all-ip (AIPN), która obsługuje wiele technologii dostępu. Abonent może łączyć się z IMS zgodnie z abonamentem abonenta poprzez sieci dostępu różnych technologii dostępu z jednym multimodalnym termninalem lub terminalami różnych rodzajów, aby otrzymać ujednolicone usługi multimedialne, w tym usługi VoIP. Istnieje jednostka pracy Voice Call Continuity (VCC) prowadząca badania nad ciągłością usług między połączeniem w domenie CS i usługą VoIP zapewnioną poprzez dostęp do IMS poprzez WLAN i proponowane są rozwiązania mające na celu rozwiązanie tych problemów, w tym wybór końcowej domeny sieciowej spośród domeny CS i IMS, gdy użytkownik funkcjonuje jako użytkownik wywołany, oraz transfer domeny między domeną CS i IMS wskutek przeniesienia terminalu, aby zapewnić ciągłość usługi i wyjść na przeciw zapotrzebowaniu sieci i rozwoju usługi. [0011] W przypadku, gdy użytkownik, który abonował usługę VCC, funkcjonuje jako użytkownik wywołany, wymagane jest w jednostce pracy VCC, aby końcowa domena sieciowa, tj. domena sieciowa stosowana do dostarczania przychodzącego połączenia głosowego, była wybrana poprzez wykonanie syntetycznego określenia w oparciu o czynniki związane z wyborem domeny sieciowej, tak aby zapewnić lepsze doświadczenie usługi, takie jak zapewnienie wyższej stopy sukcesu w łączeniu z wywoływanym użytkownikiem i wybranie sposobu o lepszej jakości lub niższych stawkach. Czynniki związane z wyborem domeny sieciowej obejmują co najmniej jeden spośród: statusu rejestracji użytkownika w domenie CS, statusu rejestracji użytkownika w IMS, danych o usłudze i abonamencie, zasad lub preferencji wyboru sieci ustanowionych przez operatora użytkownika, przypadku, czy jest już trwające połączenie w jednej domenie, oraz zdolności IP Connectivity Access Network (IPCAN), przez którą zachodzi dostęp do IMS. [0012] Z drugiej strony wraz z rozwojem badań jednostki pracy VCC wybrane zostały statyczne kotwiczenie i scentralizowane wokół IMS rozwiązanie wykonywania dwukierunkowego transferu domen CS-IMS. Podstawową ideą rozwiązania jest to, że Serwer Aplikacji (AS) jest przypisany do użytkownika jako Funkcja Kontroli Ciągłości Połączenia (Call Continuity Control Function, CCCF) w domowym IMS użytkownika, a wszystkie sygnalizacje kontrolne połączenia w domenie CS oraz sesja IMS powiązana z
5 użytkownikiem są zakotwiczone w AS. CCCF kontroluje połączenie między użytkownikiem VCC a użytkownikiem po przeciwnej stronie w sposób Kontroli Połączenia z Osobami Trzecimi (3PCC) i implementuje transfer domeny wymagany przez użytkownika VCC. Jak pokazano na Figurze 1A, połączenie między użytkownikiem VCC a użytkownikiem po przeciwnej stronie jest podzielone na dwa segmenty, jak w AS, tj. CCCF. Użytkownik VCC ustanawia nowe połączenie z AS w domeną przyjmującą transfer, gdy wymagany jest transfer domeny. Gdy nowe połączenie zostanie pomyślnie nawiązane, AS przeprowadza ponowną negocjację połączenia między AS a użytkownikiem po przeciwnej stronie, tak aby użytkownikowi po przeciwnej stronie oraz użytkownikowi VCC wykonanie interakcji głosowej poprzez nowe połączenie. CCCF kontroluje zastąpienie dwóch segmentów sesji użytkownikiem VCC odpowiednio w domenie przyjmującej transfer i oddającej transfer w trakcie procesu transferu domeny. [0013] Zatem połączenie przychodzące przeznaczone dla użytkownika, który zaabonował usługę "VCC", przekierowuje się najpierw do IMS, aby wykonać powyższe kotwiczenie w celu kontrolowania możliwego transferu domen w dalszych procesach łączenia, a następnie funkcja Wyboru Domeny Sieciowej (Network Domain Selection) zaimplementowana w IMS (IMS-NeDS) wybiera domenę do dostarczania połączenia przychodzącego do terminala VCC w oparciu o powyższe czynniki związane z wyborem domeny sieciowej, tj. bezpośrednio dostarczając połączenie przychodzące do IMS lub dostarczając połączenie przychodzące do domeny CS, jak pokazano na Figurze 1B. [0014] Użytkownik często traci przejściowo połączenie sieciowe z powodu wejścia w dziurę zasięgu lub martwy kąt podczas łączenia się z siecią poprzez sieci dostępu różnych technologii dostępu bezprzewodowego. Na przykład podczas chwilowego wejścia do windy lub piwnicy użytkownik może stracić dostęp do sieci WCDMA, GSM, CDMA lub CDMA2000, której celem projektowym jest szeroki zasięg, i przez to użytkownik nie może się połączyć z domeną CS. W takim przypadku użytkownik może być nieosiągalny w pewnej domenie sieciowej (np. domenie CS), ale osiągalny w innej domenie sieciowej (np. IMS), ponieważ IMS jest siecią szkieletową zorientowaną na technologie wielokrotnego dostępu i zasięg hot spotów zapewniony przez WLAN, jak również technologie dostępu bezprzewodowego do łączenia się z IMS mogą pokryć taką dziurę zasięgu. Ponieważ taka tymczasowa utrata połączenia nie wpływa na status rejestracji użytkownika w odpowiadającej domenie sieciowej, na podstawie której NeDS dokonuje
6 wyboru końcowej domeny sieciowej, końcową domeną sieciową wyznaczoną zgodnie z powyższymi różnymi czynnikami związanymi z wyborem domeny sieciowej może być domena sieciowa, w której użytkownik jest w danym momencie nieosiągalny. Zachodzi zatem sytuacja, że nie można się połączyć z użytkownikiem, podczas gdy jest zasadniczo możliwe pomyślne połączenie z użytkownikiem. Innymi słowy, ponieważ obsługa powyższej sytuacji nie została wzięta pod uwagę w rozwiązaniu zakańczania wyboru końcowej domeny sieciowej omawianym obecnie w jednostce pracy VCC, w szczególnej sytuacji wspomnianej powyżej funkcja wyboru końcowej domeny sieciowej dodana przez jednostkę pracy VCC nie może zrealizować oryginalnego zamiaru zapewniania lepszego doświadczenia usług, takiego jak zapewnianie wyższej stopy sukcesu w łączeniu wywołanego użytkownika, a przeciwnie, może dodatkowo zmniejszyć prawdopodobieństwo pomyślnego połączenia z użytkownikiem, co wpływa na doświadczenie usługi użytkownika. [0015] "Urządzenie do zaawansowanego ekranowania połączeń" (US 2005/0041787 A1) zapewnia interfejs sieciowy do obsługi połączeń telefonicznych. Kontroler urządzenia analizuje zasady kontroli dostępu i albo kieruje połączenie przychodzące od pierwszego interfejsu komunikacyjnego do drugiego interfejsu komunikacyjnego lub zapobiega dotarciu przychodzącego połączenia telefonicznego do drugiego interfejsu komunikacyjnego. [0016] "Sposób przekierowania połączeń IP-telefonicznych na telefon komórkowy" (EP 1596566 A1) opisuje sposób kierowania połączenia telefonicznego od strony dzwoniącej do wybranego odbiorcy (intended recipient, IR) powiązanego z co najmniej jednym Telefonem Internetowym zgodnie z procedurą routingu (routing routine, RR). Według sposobu, najpierw stwierdza się, czy Telefon Internetowy IR jest osiągalny, jeśli IR jest osiągalny, połączenie jest kierowane do IR; jeśli IR jest nieosiągalny za pośrednictwem telefonu IP, połączenie jest kierowane na telefon komórkowy IR. Streszczenie Wynalazku [0017] Przykłady wykonania niniejszego wynalazku zapewniają sposób, urządzenie i system sieciowy do dostarczania zapytania o usługę, tak aby zwiększyć stopę sukcesu w łączeniu z wywoływanym użytkownikiem.
7 [0018] Sposób dostarczania zapytania o usługę zastosowany do systemu sieciowego obejmującego dwie końcowe domeny sieciowe: sieć Komutacji Łączy (CS) i Podsystem Multimediów Protokołu Internetowego IP (IMS), obejmuje: uzyskanie, poprzez jednostkę zapytania o wybór domeny sieciowej w systemie sieciowym, stwierdzenie wyboru końcowej domeny sieciowej przez jednostkę wyboru domeny sieciowej (NeDS) po otrzymaniu zapytania o usługę przeznaczoną dla obsługiwanego wywoływanego użytkownika, oraz dostarczenie zapytania o usługę w pierwszej końcowej domenie sieciowej spośród dwóch końcowych domen sieciowych określonych poprzez stwierdzenie wyboru końcowych domen sieciowych w celu połączenia wywoływanego użytkownika; oraz ponowienie próby dostarczenia zapytania o usługę w drugiej końcowej domenie sieciowej spośród dwóch końcowych domen sieciowych w celu połączenia z wywoływanym użytkownikiem, gdy wywoływany użytkownik jest nieosiągalny w pierwszej końcowej domenie sieciowej. [0019] Urządzenie komunikacyjne obejmuje: moduł zdolny do odbierania zapytania w celu wysyłania zapytań o stwierdzenie wyboru końcowych domen sieciowych; moduł zdolny do stwierdzenia wyboru końcowych domen sieciowych zgodnie z zapytaniem i wybierania drugiej końcowej domeny sieciowej w celu ponawiania próby dostarczenia zapytania o usługę połączenia z wywoływanym użytkownikiem, gdy wywoływany użytkownik jest nieosiągalny w pierwszej końcowej domenie sieciowej określonej przez stwierdzenie wyboru końcowych domen sieciowych; oraz moduł zdolny do wysyłania stwierdzenia wyboru końcowych domen sieciowych w odpowiedzi na zapytanie. [0020] System sieciowy obejmuje: jednostkę zapytania o wybór domen sieciowych zdolną do wysyłania zapytań o stwierdzenie wyboru końcowych domen sieciowych w momencie otrzymania zapytania o usługę Podsystemu Multimediów Protokołu Internetowego (IMS) przeznaczonego dla obsługiwanego wywoływanego użytkownika, oraz do przeprowadzania następującego po tym dostarczenia zapytania o usługę IMS według stwierdzenia wyboru końcowej domeny sieciowej; oraz jednostkę Wyboru Domeny Sieciowej (NeDS) zdolną do zapewnienia jednostce zapytania o wybór
8 domen sieciowych stwierdzenia wyboru końcowych domen sieciowych oraz wysyłania wskazania stwierdzenia nowego wyboru końcowych domen sieciowych do jednostki zapytania o wybór domen sieciowych i/lub wstępnego ustawiania danych o Przekazywaniu Połączenia gdy Mobilny Abonent Nie Jest Dostępny (Call Forwarding on Mobile Subscriber Not Reachable, CFNRc) w sieci komutacji łączy (CS), gdy wywoływany użytkownik jest nieosiągalny w pierwszej końcowej domenie sieciowej określonej przez stwierdzenie wyboru końcowych domen sieciowych, tak aby dostarczyć zapytanie o usługę IMS do drugiej końcowej domeny sieciowej w celu ponownej próby dostarczenia zapytania o usługę połączenia a obsługiwanym wywoływanym użytkownikiem. [0021] W przykładzie wykonania niniejszego wynalazku NeDS w sieci ponawia próby dostarczenia połączenia w celu połączenia z użytkownikiem w innej końcowej domenie sieciowej, gdy jest to stwierdzone, że wywoływany użytkownik jest nieosiągalny w obecnie wyznaczonej końcowej domenie sieciowej. Zatem oprócz zapewniania zdolności do elastycznego wykonania wyboru końcowej domeny sieciowej według zasad lub preferencji ustalonych przez operatora i dostarczanych użytkownikowi, zapewnia się także połączenie z użytkownikiem w przypadku, gdy użytkownik jest nieosiągalny w pewnej domenie sieciowej (takiej jak domena CS), podczas gdy użytkownik jest osiągalny w innej domenie sieciowej (takiej jak IMS). [0022] Dodatkowo w innym przykładzie wykonania niniejszego wynalazku informację o przekierowaniu niesioną w zapytaniu o usługę obsługiwanym w danym momencie sprawdza NeDS, GMSC lub Mobilne Centrum Komutacji Odwiedzającego (VMSC) do obsługi CFNRc w domenie CS, aby uniknąć problemu (zapętlenie połączeń), że zapytanie o usługę jest przekierowywane w kółko między dwiema domenami sieciowymi wskutek powyższej obsługi kompensacyjnej przyjętej zarówno w domenie IMS, jak i CS. Zatem powyższa obsługa kompensacyjna jest udoskonalona, a doświadczenie usługi strony dzwoniącej i strony wywoływanej jest ulepszone. Krótki Opis Rysunków [0023] Figura 1A pokazuje schematyczny diagram ilustrujący implementację VCC w istniejącym systemie komunikacyjnym;
9 Figura 1B pokazuje schematyczny diagram ilustrujący wybór końcowej domeny sieciowej w stanie techniki; Figury. 2A i 2B pokazują schematyczne diagramy ilustrujące łączenie użytkownika w IMS, gdy użytkownik jest nieosiągalny w domenie CS z przykładem wykonania niniejszego wynalazku; Figura 3 pokazuje diagram przepływu procesów obsługi, gdy końcowa domena sieciowa stwierdzona po raz pierwszy przez NeDS jest domeną CS, podczas gdy użytkownik jest nieosiągalny w domenie CS według przykładu wykonania niniejszego wynalazku; Figura 4 pokazuje diagram przepływu procesów obsługi, gdy końcowa domena sieciowa stwierdzona po raz pierwszy przez NeDS jest IMS, podczas gdy użytkownik jest nieosiągalny w domenie CS według przykładu wykonania niniejszego wynalazku; Figura 5 pokazuje diagram przepływu procesów zapobiegania temu, by zapytanie o usługę było przekazywane w kółko, gdy końcowa domena sieciowa stwierdzona po raz pierwszy przez NeDS jest IMS, podczas gdy użytkownik jest nieosiągalny zarówno w IMS, jak i w domenie CS według przykładu wykonania niniejszego wynalazku; oraz Figura 6 pokazuje schematyczny diagram ilustrujący strukturę NeDS według przykładu wykonania niniejszego wynalazku. Przykłady Wykonania Wynalazku [0024] Zgodnie z przykładem wykonania niniejszego wynalazku, w przypadku gdy użytkownik okresowo traci połączenie z siecią, zapytanie o usługę dostarcza się innej końcowej domenie sieciowej do łączenia z użytkownikiem podczas stwierdzania w końcowej domenie sieciowej, że użytkownik jest nieosiągalny, tak aby oprócz zapewniania zdolności do elastycznego wykonania wyboru końcowych domen sieciowych zgodnie z zasadami lub preferencjami ustawionymi przez operatora lub wywoływanego użytkownika zwiększyć stopę sukcesu łączenia użytkownika. [0025] Jednostka zapytania o wybór domen sieciowych w IMS wysyła zapytanie do NeDS o stwierdzenie bieżącego wyboru końcowych domen sieciowych po otrzymaniu zapytania o usługę IMS przeznaczonego dla obsługiwanego wywoływanego użytkownika i dostarcza zapytanie o usługę IMS w końcowej domenie sieciowej określonej poprzez stwierdzenie wyboru końcowych domen sieciowych. NeDS dokonuje wyboru końcowej domeny sieciowej zgodnie z czynnikami związanymi z wyborem domeny sieciowej i zapewnia
10 jednostce zapytania o wybór domen sieciowych stwierdzenie wyboru końcowych domen sieciowych. Jak pokazano na Figurze 2A, NeDS ustawia wstępnie dane o CFNRc w domenie CS, a następnie w przypadku, gdy końcową domeną sieciową jest domena CS, umożliwia się GMSC lub VMSC do obsługi CFNRc w domenie CS wywoływanie CFNRc w momencie stwierdzenia, że wywoływany użytkownik A jest nieosiągalny w procesie dostarczania zapytania o usługę w domenie CS, tak aby skierować zapytanie o usługę z powrotem do IMS aby ponownie spróbować dostarczyć zapytanie o usługę w IMS. Lub jak pokazano na Figurze 2B, przy stwierdzaniu, że wywoływany użytkownik A jest nieosiągalny w końcowej domenie sieciowej (takiej jak IMS), NeDS wysyła wskazanie nowego stwierdzania wyboru końcowych domen sieciowych do jednostki zapytania o wybór domen sieciowych oraz kontroluje jednostkę zapytania o wybór domen sieciowych w jej kierowaniu zapytania o usługę do innej końcowej domeny sieciowej (takiej jak domena CS), aby ponownie spróbować dostarczyć zapytanie o usługę w celu połączenia z wywoływanym użytkownikiem A. [0026] Jednostką wyboru domen sieciowych może być S-CSCF przypisany w IMF do wywoływanego użytkownika. S-CSCF wysyła zapytanie do NeDS poprzez interfejs Kontroli Usług Multimedialnych IP (IP multimedia Service Control, ISC) zdefiniowany w standardzie IMS. S-CSCF jest odtąd traktowany jako przykład w niniejszym przykładzie wykonania. [0027] Aby stwierdzić, że wywoływany użytkownik jest nieosiągalny w bieżącej końcowej domenie sieciowej, NeDS może po wysłaniu stwierdzenia wyboru końcowych domen sieciowych do jednostki zapytania o wybór domen sieci uruchomić licznik i zatrzymać licznik po otrzymaniu odpowiedniej wiadomości SIP przekazanej do NeDS poprzez jednostkę zapytania o wybór domen sieci, gdy jednostka zapytania o wybór domen sieci otrzyma wiadomość z odpowiedzią od wywoływanego użytkownika lub gdy jednostka zapytania o wybór domen sieci stwierdzi, że zapytanie o usługę zostało pomyślnie dostarczone, lub gdy jednostka zapytania o wybór domen sieci stwierdzi, że dzwoniący użytkownik zdecydował się zrezygnować z zapytania o usługę. Zatem NeDS może stwierdzić, że wywoływany użytkownik jest nieosiągalny w bieżącej końcowej domenie sieciowej, gdy licznik przekroczy wyznaczony czas, i podobnie NeDS może nakazać jednostce zapytania o wybór domen sieciowych przekazywanie zapytania o usługę do innej końcowej domeny sieciowej w celu ponownego próbowania dostarczenia zapytania o
11 usługę w celu ponownego połączenia z wywoływanym użytkownikiem. Ten sposób stosuje się do obu przypadków, gdy zapytanie o usługę kieruje się do IMS, gdy wywoływany użytkownik jest nieosiągalny w domenie CS i gdy zapytanie o usługę jest kierowane do domeny CS, gdy wywoływany użytkownik jest nieosiągalny w IMS. [0028] Czas licznika może być ustawiany, modyfikowany i sprawdzany za pomocą interfejsu Ut zdefiniowanego w standardzie IMS lub poprzez interfejs Systemu Wspomagania Operacji (Operation Support System, OSS). Operator może ustawić zależność między czasem licznika i czasem innych liczników, takich jak licznik Przekazywania Połączenia przy Braku Odpowiedzi (Call Forwarding on No Reply, CFNRy) i licznik Przekazywania Połączenia gdy Mobilny Abonent Nie Jest Dostępny (Call Forwarding on Mobile Subscriber Not Reachable, CFNRc) i kontrolować, czy usługę przekierowywania, którą zaabonował i aktywował użytkownik, można wywołać zanim zapytanie o usługę zostanie przekazane do innej końcowej domeny sieciowej w celu ponowienia próby dostarczenia. Innymi słowy, jeśli usługę przekazywania połączeń można wywołać, czas licznika jest ustawiony jako dłuższy niż czas innych liczników, takich jak licznik CFNRy i licznik CFNRc, a odpowiadającą usługę przekazywania połączeń można wywołać wskutek wyczerpania się czasu licznika CFNRy lub licznika CFNRc zanim wyczerpie się czas licznika ustawiony w NeDS, a licznik ustawiony w NeDS zatrzymuje się, gdy uda się pomyślnie połączyć z wywoływanym użytkownikiem po przekazywaniu połączeń. W przeciwnym wypadku czas licznika ustawia się jako krótszy niż czas innych liczników, takich jak licznik CFNRy i licznik CFNRc i zapytanie o usługę kontroluje się tak, by zostało dostarczone do innej końcowej domeny sieciowej, aby ponownie spróbować dostarczenia zapytania o usługę wskutek wyczerpania czasu licznika ustawionego w NeDS zanim odpowiednia usługa przekazywania połączeń zostanie wywołana wskutek wyczerpania czasów innych liczników, takich jak licznik CFNRy i licznik CFNRc. [0029] Proces instruowania przez NeDS jednostki zapytania o wybór domen sieciowych, aby ponownie próbowała dostarczyć zapytanie o usługę w innej końcowej domenie sieciowej w momencie stwierdzania, że wywoływany użytkownik jest nieosiągalny w bieżącej końcowej domenie sieciowej obejmuje: wysyłanie wiadomości w celu anulowania dostarczania tego zapytania o usługę do strony końcowej, do której próbuje się dostarczyć zapytanie o usługę; oraz instruowanie jednostki zapytania o wybór domen sieciowych, aby
12 dostarczały zapytanie o usługę do innej końcowej domeny sieciowej w celu połączenia się z wywoływanym użytkownikiem. Instruowanie jest nowym zapytaniem o usługę niosącym ze sobą informację kierującą wymaganą do dostarczenia zapytania o usługę w innej końcowej domenie sieciowej. [0030] Dla użytkownika w domenie CS, NeDS może także wstępnie ustawić dane CFNRc dla użytkownika w domenie CS, wówczas w przypadku, gdy użytkownik jest nieosiągalny w domenie CS, zapytanie o usługę może być przekierowane z powrotem do IMS poprzez wywołanie CFNRc. Dane CFNRc można automatycznie ustawić w domenie CS poprzez interfejs OSS, zmieniając odpowiednie dane w HLR, do którego należy wywoływany użytkownik. Jeśli wywoływany użytkownik zakończył aktualizację położenia w domenie CS przed ustawieniem, HLR w dalszym ciągu wprowadza nade do VLR, w którym jest obecnie zlokalizowany wywoływany użytkownik, zgodnie ze standardowym sposobem aktualizacji danych abonenta. [0031] GMSC lub VMSC do obsługi CFNRc początkowo w domenie CS wywołuje CFNRc tak, aby skierować połączenie z powrotem do IMS, gdy dla połączenia zostanie odebrane zapytanie o ustanowienie połączenia, tj. zapytanie o usługę, i zostanie stwierdzone, że wywoływany użytkownik jest nieosiągalny w domenie CS. Zapytaniem o ustanowienie połączenia może być zapytanie o ustanowienie połączenia, które jest kierowane do domeny CS, ponieważ pierwszą końcową domeną sieciową wyznaczoną przez NeDS jest domena CS, lub zapytanie o ustanowienie połączenia, które jest kierowane do domeny CS, aby ponownie spróbować dostarczyć zapytanie o usługę, ponieważ pierwszą końcową domeną sieciową wyznaczoną przez NeDS jest IMS i stwierdzono, że wywoływany użytkownik jest nieosiągalny w IMS. [0032] Ponadto aby uniknąć zapętlenia połączeń między różnymi domenami sieciowymi w przypadku, gdy wywoływany użytkownik jest nieosiągalny zarówno w IMS, jak i w domenie CS, zapytanie o usługę skierowane z domeny CS z powrotem do IMS niesie informację o przekierowaniu, a poprzez ścieżkę, na której połączenie jest kierowane z domeny CS z powrotem do IMS, MGCF może przekonwertować informację o przekierowaniu w zapytaniu o ustanowienie połączenia CS na informację o przekierowaniu w zapytaniu o ustanowienie sesji IMS. Wówczas gdy jednostka zapytania o wybór domen sieciowych przekazuje zapytanie o ustanowienie sesji IMS do NeDS w celu zapytania o bieżące stwierdzenie wyboru końcowej domeny sieciowej, NeDS stwierdza, zgodnie z
13 informacją o przekierowaniu niesioną przez zapytanie o usługę, tj. zapytanie o ustanowienie sesji IMS, że powodem przekierowania jest CFNRc, a numer przekierowania jest numerem użytkownika obsługiwanego wywoływanego użytkownika w domenie CS, a NeDS decyduje, aby nie wybierać ponownie domeny CS do dostarczania zapytania o usługę. [0033] Procesy, których NeDS nie wybiera do domeny CS w celu ponownego dostarczania zapytania o usługę, obejmują: nie wybieranie domeny CS jako końcowej domeny sieciowej przy przeprowadzaniu wyboru końcowych domen sieciowych następnym razem i/lub nie instruowanie jednostki zapytania o wybór domen sieciowych, by ponownie próbowała dostarczyć zapytanie o usługę w innej końcowej domenie sieciowej (tj. w domenie CS) w przypadku, gdy zostanie stwierdzone, że wywoływany użytkownik jest nieosiągalny także w IMS. [0034] Alternatywnie, aby uniknąć zapętlania połączeń między różnymi domenami sieciowymi w przypadku, gdy użytkownik jest nieosiągalny zarówno w IMS, jak i w domenie CS, informację o przekierowaniu może także nieść zapytanie o ustanowienie sesji IMS, tj. zapytanie o usługę przekazane przez S-CSCF do domeny CS w przypadku, gdy pierwszą końcową domeną sieciową wyznaczoną przez NeDS jest IMS, a wywoływany użytkownik jest nieosiągalny w IMS. MGCF jest ścieżką, na której połączenie jest kierowane z IMS do domeny CS, może przekonwertować informację o przekierowaniu w zapytaniu o ustanowienie sesji IMS w informację o przekierowaniu w zapytaniu o ustanowienie domeny CS. Zatem GMSC lub VMSC początkowo do obsługi CFNRc w domenie CS nie wywołuje CFNRc ponownie i bezpośrednio uwalnia połączenie zgodnie z informacją o przekierowaniu, gdy stwierdza się, że wywoływany użytkownik ponownie jest nieosiągalny w domenie CS. [0035] Informacja o przekierowaniu zawiera co najmniej bieżący skumulowany czas przekazywania i przyczynę ostatniego przekierowania. Sposób nie wywoływania CFNRc w domenie CS zgodnie z informacją o przekierowaniu niesioną w zapytaniu o usługę skierowanym z IMS do domeny CS w przypadku, gdy stwierdza się, że wywoływany użytkownik jest nieosiągalny w domenie CS obejmuje: ocenę przez GMSC i VMSC początkowo do obsługi CFNRc w domenie CS, czy ten CFNRc ma być wywołany zgodnie z bieżącym skumulowanym czasem przekierowania i maksymalnym czasem, jaki jest ustawiony jako dozwolony na przekierowanie w domenie CS; lub ocenę przez GMSC i
14 VMSC początkowo do obsługi CFNRc w domenie CS, czy ten CFNRc ma być wywołany przez połączenie bieżących skumulowanych czasów przekierowania, przyczyny ostatniego przekierowania i maksymalnego czasu, jaki jest ustawiony jako dozwolony w domenie CS do przekazywania z tego samego powodu. [0036] Z drugiej strony, jako zapytanie o ustanowienie sesji IMS dla przychodzącej sesji IMS, tj. zapytanie o usługę odebrane w IMS, może nie być odpowiednie, aby być dostarczone bezpośrednio do domeny CD do dostarczania (np. zapytanie o ustanowienie sesji IMS w celu ustanowienia interakcji multimedialnej). Zatem, aby uniknąć rezerwy awaryjnej systemu lub nawet awarii systemu, którą może spowodować ewentualne skierowanie przychodzącej sesji IMS do domeny CS, w przypadku, gdy NeDS stwierdza, że wywoływany użytkownik jest nieosiągalny w IMS, NeDS może ponadto osądzić zgodnie z nazwą sposobu zapytania o usługę IMS obsługiwanego w danym momencie i/lub opis Protokołu Opisu Sesji (Session Description Protocol, SDP) niesiony przez zapytanie o usługę IMS lub o identyfikator usługi komunikacyjnej niesiony w zapytaniu o usługę IMS, czy kategoria usługi obsługiwana w danym momencie jest odpowiednia, aby zostać dostarczona do domeny CS do dostarczenia, przed poinstruowaniem jednostki zapytania o wybór domen sieciowych, aby podjęła ponowną próbę dostarczenia zapytania o usługę w innej końcowej domenie sieciowej. Jeśli kategoria usług zapytania o usługę obsługiwanego w danym momencie jest odpowiednia, aby ją dostarczyć do sieci CS, NeDS instruuje jednostkę zapytania o wybór domen sieciowych, aby podjęła próbę dostarczenia zapytania o usługę w domenie CS; w przeciwnym wypadku NeDS może nie przeprowadzić żadnej obsługi i czeka na zwolnienie sesji z procesu przekroczenia czasu lub strona inicjująca rezygnuje z ustanawiania sesji. [0037] Następujący opis podano rozpatrując odpowiednio przypadki, że pierwszą końcową domeną sieciową jest domena CS lub że pierwszą końcową domeną sieciową jest IMS jako przykład. [0038] Jak pokazano na Figurze 3, niniejszym opisano procesy dostarczania zapytania o usługę do sieci innej końcowej domeny w celu podjęcia ponownej próby dostarczenia zapytania o usługę w sposobie wstępnego ustawiania danych o przekierowaniu w domenie CS w przypadku, gdy pierwszą końcową domeną sieciową stwierdzoną przez NeDS jest domena CS, a wywoływany użytkownik jest nieosiągalny w domenie CS.
15 [0039] Etap 300: NeDS ustawia wstępnie dane CFNRc domeny CS w HSS/HLR poprzez interfejs OSS. Numerem do przekierowania jest w danych wirtualny numer roamingowy przeznaczony do IMS (IMRN) (składowy IMRN powinien posiadać określony odpowiedni związek z publicznym identyfikatorem użytkownika wywoływanego użytkownika w IMS, tak aby umożliwić normalny routing w IMS, gdy sesję kieruje się następnie z powrotem do IMS). [0040] Dane są w dalszym ciągu aktualizowane przez HSS/HLR do MSC/VLR, w którym wywoływany użytkownik się aktualnie znajduje zgodnie ze standardowym procesem wprowadzania danych abonenta, jeśli użytkownik zarejestrował się w domenie CS. [0041] Etap 310: I-CSCF odbiera zapytanie o usługę IMS, przeprowadza oddziaływanie zapytania routingowego z HSS i przekazuje zapytanie o usługę IMS do S-CSCF przypisanego do wywoływanego użytkownika według informacji zwróconej przez HSS. [0042] Etap 320: S-CSCF przeprowadza ocenę wstępnych Kryteriów Filtracji (initial Filtration Criteria, ifc) według danych abonamentowych abonenta i S-CSCF, jako jednostka zapytania o wybór domen sieciowych, przekazuje zapytanie o usługę IMS do NeDS, jako AS, według dobranych ifc, aby zapytać o bieżące wyznaczenie wyboru końcowych domen sieciowych. [0043] Etap 330: NeDS dokonuje wyboru końcowej domeny sieciowej i zwraca bieżące wyznaczenie wyboru końcowej domeny sieciowej do SCSCF w zapytaniu o usługę (w tym przykładzie wykonania NeDS decyduje, aby dostarczyć zapytanie o usługę poprzez domenę CS). [0044] Etap 340: S-CSCF przekazuje zapytanie o usługę IMS do MGCF zgodnie z URI- Zapytaniem w zapytaniu o usługę IMS zwróconą przez NeDS, a MGCF przeprowadza następnie procesy kierowania, aż przekonwertowane zapytanie o ustanowienie połączenia CS jest skierowane do MSC/VLR, w którym znajduje się obecnie wywoływany użytkownik. [0045] MGCF musi przeprowadzić procesy współdziałania CS-IMS zdefiniowane w standardach. Dodatkowo, jeśli w URI-Zapytaniu w zapytaniu o usługę zwróconym do S- CSCF wypełniony przez NeDS jest wirtualny numer roamingowy przeznaczony do domeny CS (CSRN), MGCF musi ponadto przywrócić numer użytkownika wywoływanego użytkownika w domenie CS, a następnie kolejne procesy, takie jak
16 zdobycie numeru roamingowego w domenie CS, jest przekazywane zgodnie z istniejącymi procedurami standardowymi; alternatywnie, jeśli w URI-Zapytaniu w zapytaniu o usługę zwróconym do S-CSCF wypełniony przez NeDS jest numer roamingowy wywoływanego użytkownika w domenie CS, MGCF i inne elementy sieciowe w domenie CS mogą bezpośrednio kierować przekonwertowane zapytanie o ustanowienie połączenia CS do MSC/VLR obsługującego użytkownika zgodnie z numerem roamingowym. [0046] Etap 350: W tym przykładzie wykonania CFNRc jest wywoływany zgodnie ze standardową procedurą, ponieważ wywoływany użytkownik tymczasowo traci połączenie radiowe, a MSC/VLR, w którym użytkownik znajduje się w danym momencie, nie może uzyskać odpowiedzi przywoławczej od wywoływanego użytkownika. Przekierowane zapytanie o ustanowienie połączenia CS niesie informację o przekierowaniu i jest kierowane do MGCF zgodnie z IMRN jako numer do przekierowania i przeznaczane do IMS. Ten MGCF może być tym samym, co ten w Etapie 340 lub innym od tego w Etapie 340, co nie wpływa na tę procedurę. [0047] Etap 360: MGCF wykonuje obsługę współdziałania CS-IMS i przywraca IMRN. Obsługa współdziałania CS0IMS w tym etapie obejmuje: konwersję informacji o przekierowaniu w domenie CS na informację o przekierowaniu w IMS zgodnie z powiązanymi specyfikacjami w TISPAN oraz wysyłanie przekonwertowanego zapytania o usługę do I-CSCF. [0048] Etap 370: Procesy po tym, jak I-CSCF odbiera zapytanie o usługę IMS, aż S-CSCF ponownie przekaże zapytanie o usługę IMS do NeDS zgodnie z ifc, są takie same, jak w Etapach 310-320. [0049] Etap 380: NeDS decyduje, by nie wybierać domeny CS do dostarczenia zapytania o usługę zgodnie z informacją o przekierowaniu (stwierdzając, że powodem przekierowania jest CFNRc i że początkowym numerem wywoływanego użytkownika, tj. numerem przekierowania, jest numer użytkownika wywoływanego użytkownika w domenie CS) i nie zmienia URI-Zapytania w zapytaniu o usługę IMS zwróconym do S-CSCF. [0050] Etap 390: S-CSCF przekazuje zapytanie o usługę IMS do P-CSCF zgodnie z URI- Zapytania w otrzymanym zapytaniu o usługę IMS, a zapytanie o usługę IMS jest dostarczane poprzez IMS w celu połączenia z wywoływanym użytkownikiem.
17 [0051] Jak pokazano na Figurze 4, poniżej opisano procesy stwierdzania przeprowadzane przez NeDS i instruowania jednostki zapytania o wybór domen sieci o dostarczeniu zapytania o usługę do innej sieci w celu połączenia z wywoływanym użytkownikiem w przypadku, gdy pierwszą końcową domeną sieciową jest IMS, a wywoływany użytkownik jest nieosiągalny w IMS. [0052] Etap 400: Po otrzymaniu zapytania o usługę IMSI-CSCF przekierowuje zapytanie o usługę IMS do NeDS jako AS poprzez jednostkę zapytania o wybór domen sieci, tj. S- CSCF. Obsługa w tym etapie jest taka sama, jak w Etapach 310 i 320. [0053] Etap 410: NeDS przeprowadza wybór końcowej domeny sieciowej, zwraca bieżące wyznaczenie wyboru końcowej domeny sieciowej do S-CSCF i uruchamia licznik czasu. W tym przykładzie wykonania NeDS decyduje, aby dostarczyć zapytanie o usługę poprzez IMS w celu połączenia z wywoływanym użytkownikiem, a zatem NeDS nie zmienia URI- Zapytania w zapytaniu o usługę IMS, które ma być skierowane z powrotem do S-CSCF. [0054] Etap 420: S-CSCF przekazuje zapytanie o usługę IMS do P-CSCF zgodnie z URI- Zapytania w otrzymanym zapytaniu o usługę IMS, a następnie PCSCF łączy się z wywoływanym użytkownikiem w IMS. [0055] Etap 430: Jeśli NeDS nie otrzymuje odpowiedzi od końcowej strony z wyjątkiem odpowiedzi 100 (odpowiedź 100 jest zwracana "skok za skokiem" i nie może wskazać, że pomyślnie połączono się z wywoływanym użytkownikiem) lub nie otrzymuje ewentualnej odpowiedzi wskazującej sukces, aż licznik czasu ustawiony przez NeDS wyczerpie się, NeDS decyduje, by zacząć obsługę próby dostarczenia w innej domenie sieciowej po stwierdzeniu, że zapytanie o obsługiwaną usługę jest odpowiednie, aby je dostarczyć do sieci CS w celu dostarczenia zgodnie z kategorią usługi zapytania o usługę, które jest obecnie obsługiwane. Innymi słowy, jeśli NeDS otrzymuje serię tymczasowych odpowiedzi od wywoływanego użytkownika, wówczas wywoływany użytkownik traci połączenie sieciowe i sesja nie zostaje ustanowiona pomyślnie, NeDS może próbować dostarczenia zapytania o usługę w innej końcowej domenie sieciowej; ten określający warunek zatrzymania licznika czasu może być ustawiony zgodnie z odpowiednimi zasadami ustawionymi przez operatora. [0056] Etap 440: NeDS najpierw wysyła zapytanie anulujące usługę do strony końcowej w poprzedniej sesji i kończy połączenie sesji ustanowione w IMS między NeDS a wywoływanym użytkownikiem po otrzymaniu potwierdzenia.
18 [0057] Etap 450: NeDS wysyła nowe zapytanie o usługę do S-CSCF. Powtórny wybór, tj. dostarczanie zapytania o usługę przez domenę CS, wskazuje zmodyfikowane URI- Zapytanie w nowym zapytaniu o usługę. Podobnie do poprzedniego sposobu wykonania, zmodyfikowanym URI-Zapytaniem może być CSRN lub numer roamingowy przypisany w domenie CS do wywoływanego użytkownika w formacie Tel Uniform Resource Identifier (Tel-URI). [0058] S-CSCF przekazuje zapytanie o usługę IMS do MGCF zgodnie z URI-Zapytaniem w zapytaniu o usługę IMS zwróconą przez NeDS, a MGCF przeprowadza obsługę współdziałania IMS-CS i następnie kierowania oraz kieruje przekonwertowane zapytanie o ustanowienie połączenia CS do MSC/VLR, w którym znajduje się obecnie wywoływany użytkownik, i w końcu łączy z wywoływanym użytkownikiem w domenie CS. [0059] Warto zauważyć, że ten przykład wykonania opisano biorąc następujący przykład: obsługa instruowania S-CSCF o dostarczeniu zapytania o usługę do domeny CS w celu połączenia z wywoływanym użytkownikiem w przypadku, gdy pierwszą końcową domeną sieciową jest IMS, a wywoływany użytkownik jest nieosiągalny w IMS. Jednakże przy stwierdzaniu, że pierwszą końcową domeną sieciową jest domena CS, NeDS może także zwrócić zapytanie o usługę do S-CSCF w celu przeprowadzenia dalszej kontroli routingowej i w związku z tym można ją także zaimplementować przez użycie tego samego sposobu obsługi w celu poinstruowania S-CSCF, aby dostarczył zapytanie o usługę poprzez IMS w celu połączenia z wywoływanym użytkownikiem w przypadku, gdy pierwszą końcową domeną sieciową jest domena CS, a wywoływany użytkownik jest nieosiągalny w domenie CS. [0060] Niniejszym opisano wraz z przykładem wykonania różne sposoby obsługi do zapobiegania zapętlenia połączeń zapytań o usługę między dwiema domenami sieciowymi według niniejszego wynalazku. [0061] Jak pokazano na Figurze 5, poniżej opisano obsługę mającą na celu unikanie zapętlania połączeń w przypadku, gdy pierwszą końcową domeną sieciową stwierdzoną przez NeDS jest IMS, a wywoływany użytkownik jest nieosiągalny zarówno w IMS, jak i w domenie CS. (Ten przykład wykonania można uważać za kombinację przykładów pokazanych odpowiednio na Fig. 3 i 4.) [0062] Etap 500: Podobnie jak w Etapie 300 pokazanym na Figurze 3, NeDS ustawia wstępnie dane CFNRc w domenie CS, a HSS/HLR wprowadza zaktualizowane dane do
19 MSC/VLR, w którym obecnie znajduje się wywoływany użytkownik w przypadku, gdy użytkownik zarejestrował się w domenie CS. [0063] Etap 510: Procesy od etapu "I-CSCF odbiera zapytanie o usługę IMS" do etapu "NeDS stwierdza, że zapytanie o usługę ma być najpierw dostarczone do IMS" są takie same, jak w Etapach 400, 410 i 420 i nie zostaną tu opisane. [0064] Etap 520: NeDS stwierdza, że wywoływany użytkownik jest obecnie nieosiągalny w IMS i poleca, aby zapytanie o usługę było dostarczone do domeny CS w celu połączenia z wywoływanym użytkownikiem. Szczegółową obsługę tego etapu opisano w Etapach 430, 440 i 450. [0065] Aby uniknąć w dalszej części zapętlenia połączeń, NeDS wysyła nowe zapytanie o usługę, które niesie informację o przekierowaniu CFNRc w sposób zdefiniowany w TISPAN w S-CSCF. [0066] Etap 530: S-CSCF przekazuje zapytanie o usługę IMS do MGCF zgodnie z URI- Zapytaniem w zapytaniu o usługę IMS zwróconą przez NeDS, a MGCF przeprowadza obsługę współdziałania IMS-CS i następnie obsługę kierowania, aby skierować przekonwertowane zapytanie o ustanowienie połączenia CS do MSC/VLR, w którym znajduje się obecnie wywoływany użytkownik. [0067] W tym etapie obsługa współdziałania IMS-CS przeprowadzana przez MGCF obejmuje konwersję informacji o przekierowaniu w IMS na informację o przekierowaniu w domenie CS według specyfikacji w TISPAN, jeśli nowe zapytanie o usługę IMS niesie informację o przekierowaniu. [0068] Etap 540: MSC/VLR, w którym znajduje się obecnie wywoływany użytkownik, odbiera zapytanie o ustanowienie połączenia CS, przywołuje wywoływanego użytkownika, ale nie udaje mu się otrzymać odpowiedzi przywoławczej od wywoływanego użytkownika i wówczas MSC/VLR jest gotowe, aby wywołać CFNRc. [0069] Etap 550-1: Jeśli nowe zapytanie o usługę wysłane do S-CSCF przez NeDS w Etapie 520 niesie informację o przekierowaniu CFNRc, zapytanie o ustanowienie połączenia CS niesie informację o przekierowaniu co najmniej jednego CFNRc, a MSC/VLR nie wysyła już nowego zapytania o ustanowienie połączenia z użyciem numeru do przekierowania ustawionego w Etapie 500, ale zwraca bezpośrednio wiadomość o niepowodzeniu ustanowienia połączenia zgodnie z maksymalnymi czasami dozwolonymi
20 na przekierowanie lub maksymalnymi czasami dozwolonymi na przekierowanie z tego samego powodu ustawionego przez sieć. Wiadomość o niepowodzeniu ustanowienia połączenia jest zwracana oryginalną drogą i MGCF przeprowadza obsługę współdziałania CS-IMS, aby zwrócić odpowiedź o niepowodzeniu usługi IMS dzwoniącemu użytkownikowi w IMS i kończy procedurę obsługi usługi. [0070] Jeśli CFNRc w domenie CS z różnych powodów (takich jak długie maksymalne czasy dozwolone na przekierowanie lub maksymalne czasy dozwolone na przekierowanie z tego samego powodu ustawione w istniejącej sieci) nie może być zniesione w MSC/VLR, obsługę w takim wypadku podano w Etapie 550-2. [0071] Etap 550-2: Połączenie jest przekierowane ponownie i zwrócone do IMS poprzez współdziałanie wykonywane przez MGCF, a następnie połączenie jest przekierowywane do SCSCF poprzez I-CSCF. S-CSCF wysyła zapytanie do NeDS zgodnie z ifc. Przekierowane zapytanie o ustanowienie połączenia CS niesie informację o przekierowaniu, a NeDS decyduje, by zrezygnować z obsługi ustanawiania tej sesji zgodnie z informacją o przekierowaniu w domenie CS i zwraca odpowiedź o niepowodzeniu usługi IMS do strony początkowej poprzez S-CSCF. Ponieważ ta sesja przeszła już długą drogę, odpowiedź o niepowodzeniu usługi IMS zwrócona stronie początkowej przekazuje się z powrotem ustanowioną drogą i w końcu przekazuje do dzwoniącego użytkownika. [0072] Jak widać w Etapie 550-2, nawet jeśli MSC/VLR nie może znieść CFNRc w domenie CS, a połączenie jest ponownie dostarczane z powrotem do IMS, NeDS może przeprowadzić obsługę lub unikanie zapętlenia połączeń zgodnie tylko z informacją o przekierowaniu w domenie CS. Zatem, jeśli zostanie stwierdzone, że MSC/VLR nie może znieść CFNRc w domenie CS (na przykład maksymalny czas dozwolony na przekierowanie w istniejącej sieci jest długi) lub aby uniknąć wpływu na usługi w istniejącej sieci, zapytanie o usługi przekierowane z IMS do domeny CS w Etapie 520 może nie nieść informacji o przekierowaniu. [0073] W końcu, jeśli NeDS kontroluje obsługę dostarczania zapytania o usługę do innej końcowej domeny sieciowej w celu podjęcia próby połączenia z wywoływanym użytkownikiem z użyciem sposobu stwierdzania, że użytkownik jest nieosiągalny przez samo NeDS i wysyłanie stwierdzenia wyboru nowej końcowej domeny sieciowej do S- CSCF od początku, niezależnie czy nową końcową domeną sieciową jest domena CS, czy
21 IMS, NeDS, jako scentralizowany punkt kontroli może przeprowadzić obsługę lub uniknąć zapętlenia połączeń przy pomocy lokalnego rejestru obsługi. W szczególności NeDS przechowuje rejestr obsługi tego zapytania o usługę i nie instruuje S-CSCF, aby podjęło ponowną próbę dostarczenia zapytania o usługę, ale zwraca odpowiedź o niepowodzeniu usługi IMS do strony początkowej poprzez SCSCF, gdy zostanie stwierdzone zgodnie z rejestrem, że próbowano dostarczyć zapytanie o usługę zarówno w domenie CS, jak i IMS. [0074] Jak pokazano na Figurze 6, NeDS w tym przykładzie wykonania obejmuje moduł odbierający 600, moduł wyboru 601 i moduł wysyłający 602. Moduł odbierający 600 odbiera zapytanie w celu wysyłania zapytania o stwierdzenie wyboru końcowej domeny sieciowej. Moduł wyboru 601 dokonuje wyboru końcowej domeny sieciowej zgodnie z zapytaniem i wybiera inną domenę sieciową do dostarczania zapytania o usługę w przypadku, gdy wywoływany użytkownik jest nieosiągalny w wybranej końcowej domenie sieciowej. Moduł wysyłający 602 w odpowiedzi na zapytanie wysyła stwierdzenie wyboru końcowej domeny sieciowej. Jest oczywiste, że fachowiec może wykonać liczne modyfikacje i zmiany w niniejszym wynalazku bez wykraczania poza zakres niniejszego wynalazku. Sporządziła i zweryfikowała Dorota Rzążewska Rzecznik patentowy
22 Zastrzeżenia 1. Sposób dostarczania zapytania o usługę zastosowany do systemu sieciowego zawierającego dwie końcowe domeny sieciowe: sieć Komutacji Łączy CS i Podsystem Multimediów Protokołu Internetowego IP, IMS, obejmujący: uzyskanie, poprzez jednostkę zapytania o wybór domeny sieciowej w systemie sieciowym, stwierdzenia wyboru końcowej domeny sieciowej przez jednostkę wyboru domeny sieciowej NeDS po otrzymaniu zapytania o usługę przeznaczoną dla obsługiwanego wywoływanego użytkownika, oraz znamienny dostarczaniem zapytania o usługę w pierwszej końcowej domenie sieciowej spośród dwóch końcowych domen sieciowych określonych poprzez stwierdzenie wyboru końcowych domen sieciowych w celu połączenia z wywoływanym użytkownikiem; ponawianiem próby dostarczenia zapytania o usługę w drugiej końcowej domenie sieciowej spośród dwóch końcowych domen sieciowych w celu połączenia z wywoływanym użytkownikiem, gdy wywoływany użytkownik jest nieosiągalny w pierwszej końcowej domenie sieciowej. 2. Sposób według zastrzeżenia 1, w którym NeDS instruuje jednostkę zapytania o wybór domeny sieci, aby ponowiła próbę dostarczenia zapytania o usługę w drugiej końcowej domenie sieciowej po stwierdzeniu, że wywoływany użytkownik jest nieosiągalny w pierwszej końcowej domenie sieciowej. 3. Sposób według zastrzeżenia 2, w którym pierwszą końcową domeną sieciową jest IMS, NeDS ocenia, czy zapytanie o usługę jest odpowiednie, aby je dostarczyć do sieci CS zgodnie z kategorią usługi zapytania o usługę, instruuje jednostkę zapytania o wybór domeny sieci, aby ponowiła próbę dostarczenia zapytania o usługę w sieci CS, jeśli