JP5853112B2

JP5853112B2 - 無線通信システムにおいて音声サービス支援方法及び装置

Info

Publication number: JP5853112B2
Application number: JP2014557576A
Authority: JP
Inventors: レヨンキム，; ジェヒュンキム，; テヒョンキム，; ヒョンソクキム，
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2012-02-22
Filing date: 2013-02-22
Publication date: 2016-02-09
Anticipated expiration: 2033-02-22
Also published as: US20160198336A1; US9294906B2; US9807587B2; CN104137582B; EP2819441A4; US20150056986A1; EP2819441B1; EP2819441A1; KR102034588B1; JP2015510735A; WO2013125896A1; CN110099052A; KR20140143156A; CN104137582A; CN110099052B

Description

以下の説明は、無線通信システムに関し、特に、音声サービス支援方法及び装置に関する。

無線通信システムが音声やデータなどのような種々の通信サービスを提供するために広範囲に展開されている。一般に、無線通信システムは可用のシステムリソース（帯域幅、送信電力など）を共有して複数ユーザとの通信を支援できる多元接続（ｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システムとなっている。多元接続システムの例には、ＣＤＭＡ（ｃｏｄｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＴＤＭＡ（ｔｉｍｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅｃａｒｒｉｅｒｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＭＣ−ＦＤＭＡ（ｍｕｌｔｉｃａｒｒｉｅｒｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システムなどがある。

本発明は、無線通信システムにおいて着信音声呼（ｔｅｒｍｉｎａｔｉｎｇｖｏｉｃｅｃａｌｌ）を正確に伝達することを技術的課題とする。

本発明で達成しようとする技術的課題は、以上に言及した技術的課題に制限されず、言及していない他の技術的課題は、下の記載から、本発明の属する技術の分野における通常の知識を有する者には明確に理解されるであろう。

本発明の第１技術的な側面は、無線通信システムにおいてネットワークの端末に対する音声サービス支援方法であって、サービングノードがＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ、ＵＬＲ）メッセージを送信すること、を含み、前記サービングノードが前記端末のためのＰＳセッションでのＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）ボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値を評価できなかった場合に、前記ＵＬＲは、ＰＳセッションでのＩＭＳボイスの同種支援情報を含まない、音声サービス支援方法である。

本発明の第２技術的な側面は、無線通信システムにおけるサービングノード装置であって、送受信モジュールと、プロセッサと、を備え、前記プロセッサは、ＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ、ＵＬＲ）を送信し、前記サービングノードが前記端末のためのＰＳセッションでのＩＭＳボイス支援表示値を評価できなかった場合に、前記ＵＬＲは、ＰＳセッションでのＩＭＳボイスの同種支援情報を含まない、サービングノード装置である。

本発明の第１乃至第２技術的な側面は下記の事項の全て／一部を含むことができる。

前記ＰＳセッションでのＩＭＳボイス支援表示は、端末のボイスオーバーＩＭＳ（ＶｏｉｃｅｏｖｅｒＩＭＳ）関連能力情報を考慮して決定されてもよい。

前記ボイスオーバーＩＭＳ能力情報は、ボイス支援マッチ指示子（Ｖｏｉｃｅｓｕｐｐｏｒｔｍａｔｃｈｉｎｄｉｃａｔｏｒ）及びＳＲＶＣＣ（ＳｉｎｇｌｅＲａｄｉｏＶｏｉｃｅＣａｌｌＣｏｎｔｉｎｕｉｔｙ）能力情報のうち一つ以上を含んでもよい。

前記ＵＬＲが前記ＰＳセッションでのＩＭＳボイスの同種支援情報を含まない場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は前記ＵＬＲ送信以降に送信されてもよい。

前記ＵＬＲ送信以降に送信される前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、前記サービングノードから前記ＨＳＳに送信される報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージに含まれてもよい。

前記端末のために前記サービングノードのサービス地域（ｓｅｒｖｉｃｅａｒｅａ）で前記ＰＳセッションでのＩＭＳボイスが同一に支援される場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は‘支援’に設定されてもよい。

前記端末のために前記サービングノードのサービス地域で前記ＰＳセッションでのＩＭＳボイスを同一に支援しない場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は‘支援しない’に設定されてもよい。

前記ＰＳセッションでのＩＭＳボイスが前記端末のための前記サービングノードのサービス地域のうちの一部の地域でのみ支援される場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は前記サービングノードで考慮されなくてもよい。

前記ＰＳセッションでのＩＭＳボイスが前記端末のための前記サービングノードのサービス地域で支援されるか否かが確認できない場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は前記サービングノードで考慮されなくてもよい。

前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、サービングノードのＭＭ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ）コンテクストに保存されてもよい。

前記ＵＬＲを送信することは、前記端末のアタッチ手順、前記端末のＴＡＵ手順又は前記端末のＲＡＵ手順のいずれか一手順に含まれてもよい。

前記サービングノードは、ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）又はＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）のいずれか一つであってもよい。

前記サービングノードのサービス地域は、前記サービングノードがＭＭＥである場合に、前記ＭＭＥに関連した全てのＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）であってもよい。

前記サービングノードのサービス地域は、前記サービングノードがＳＧＳＮである場合に、前記ＳＧＳＮに関連した全てのＲＡ（ＲｏｕｔｅｉｎｇＡｒｅａ）である。

前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、前記端末に対する着信音声呼のドメイン選択に用いられてもよい。
本願明細書は、例えば、以下の項目も提供する。
（項目１）
無線通信システムにおいてネットワークの端末に対する音声サービス支援方法であって、
サービングノードがＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ、ＵＬＲ）メッセージを送信すること、を含み、
前記サービングノードが前記端末のためのＰＳセッションでのＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）ボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値を評価できなかった場合に、前記ＵＬＲは、ＰＳセッションでのＩＭＳボイスの同種支援情報を含まない、音声サービス支援方法。
（項目２）
前記ＰＳセッションでのＩＭＳボイス支援表示は、端末のボイスオーバーＩＭＳ（ＶｏｉｃｅｏｖｅｒＩＭＳ）関連能力情報を考慮して決定される、項目１に記載の音声サービス支援方法。
（項目３）
前記ボイスオーバーＩＭＳ能力情報は、ボイス支援マッチ指示子（Ｖｏｉｃｅｓｕｐｐｏｒｔｍａｔｃｈｉｎｄｉｃａｔｏｒ）及びＳＲＶＣＣ（ＳｉｎｇｌｅＲａｄｉｏＶｏｉｃｅＣａｌｌＣｏｎｔｉｎｕｉｔｙ）能力情報のうち一つ以上を含む、項目２に記載の音声サービス支援方法。
（項目４）
前記ＵＬＲが前記ＰＳセッションでのＩＭＳボイスの同種支援情報を含まない場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は前記ＵＬＲ送信以降に送信される、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目５）
前記ＵＬＲ送信以降に送信される前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、前記サービングノードから前記ＨＳＳに送信される報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージに含まれる、項目４に記載の音声サービス支援方法。
（項目６）
前記端末のために前記サービングノードのサービス地域（ｓｅｒｖｉｃｅａｒｅａ）で前記ＰＳセッションでのＩＭＳボイスが同一に支援される場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は‘支援’に設定される、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目７）
前記端末のために前記サービングノードのサービス地域で前記ＰＳセッションでのＩＭＳボイスを同一に支援しない場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は‘支援しない’に設定される、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目８）
前記ＰＳセッションでのＩＭＳボイスが前記端末のための前記サービングノードのサービス地域のうちの一部の地域でのみ支援される場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は前記サービングノードで考慮されない、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目９）
前記ＰＳセッションでのＩＭＳボイスが前記端末のための前記サービングノードのサービス地域で支援されるか否かが確認できない場合に、前記ＰＳセッションでのＩＭＳボイスの同種支援情報は前記サービングノードで考慮されない、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目１０）
前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、サービングノードのＭＭ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ）コンテクストに保存される、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目１１）
前記ＵＬＲを送信することは、前記端末のアタッチ手順、前記端末のＴＡＵ手順又は前記端末のＲＡＵ手順のいずれか一手順に含まれる、項目１に記載の音声サービス支援方法。
（項目１２）
前記サービングノードは、ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）又はＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）のいずれか一つである、項目１に記載の音声サービス支援方法。
（項目１３）
前記サービングノードのサービス地域は、前記サービングノードがＭＭＥである場合に、前記ＭＭＥに関連した全てのＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）である、項目６に記載の音声サービス支援方法。
（項目１４）
前記サービングノードのサービス地域は、前記サービングノードがＳＧＳＮである場合に、前記ＳＧＳＮに関連した全てのＲＡ（ＲｏｕｔｅｉｎｇＡｒｅａ）である、項目６に記載の音声サービス支援方法。
（項目１５）
前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、前記端末に対する着信音声呼のドメイン選択に用いられる、項目１乃至３のいずれか１項に記載の音声サービス支援方法。
（項目１６）
無線通信システムにおけるサービングノード装置であって、
送受信モジュールと、
プロセッサと、
を備え、
前記プロセッサは、ＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ、ＵＬＲ）を送信し、前記サービングノードが前記端末のためのＰＳセッションでのＩＭＳボイス支援表示値を評価できなかった場合に、前記ＵＬＲは、ＰＳセッションでのＩＭＳボイスの同種支援情報を含まない、サービングノード装置。

本発明によれば、ＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）網でＩＭＳ加入者に属した端末への着信音声呼（ｔｅｒｍｉｎａｔｉｎｇｖｏｉｃｅｃａｌｌ）を正確なドメインに伝達することが可能になる。

本発明から得られる効果は、以上に言及した効果に制限されず、言及していない他の効果は、下の記載から、本発明の属する技術の分野における通常の知識を有する者には明確に理解されるであろう。

本明細書に添付される図面は、本発明に関する理解を提供するためのもので、本発明の様々な実施の形態を示し、明細書の記載と共に本発明の原理を説明するためのものである。

図１は、ＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）を含むＥＰＳ（ＥｖｏｌｖｅｄＰａｃｋｅｔＳｙｓｔｅｍ）の概略的な構造を示す図である。図２は、初期アタッチ（ｉｎｉｔｉａｌａｔｔａｃｈ）手順を説明するための図である。図３は、ＴＡＵ（ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅ）手順を説明するための図である。図４は、サービングノードがボイス支援マッチ指示子（ＶｏｉｃｅＳｕｐｐｏｒｔＭａｔｃｈＩｎｄｉｃａｔｏｒ）という情報を獲得する手順を説明するための図である。図５は、着信音声呼（ｔｅｒｍｉｎａｔｉｎｇｖｏｉｃｅｃａｌｌ）に対するドメイン選択に関する動作を説明するための図である。図６は、本発明の実施例に係る初期アタッチ手順を説明するための図である。図７は、本発明の実施例に係るＴＡＵ手順を説明するための図である。図８は、本発明の実施例に係る着信音声呼に対するドメイン選択に関する動作を説明するための図である。図９は、本発明の実施例に係るネットワークノード装置を例示する図である。

以下の実施例は本発明の構成要素と特徴を所定の形態に結合したものである。各構成要素又は特徴は特別な言及がない限り選択的なものとして考慮することができる。各構成要素又は特徴は、他の構成要素や特徴と結合していない形態で実施されてもよく、一部構成要素及び／又は特徴が結合して本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更されてもよい。ある実施例の一部構成や特徴は他の実施例に含まれてもよく、又は、他の実施例の対応する構成又は特徴に取って代わってもよい。

以下の説明で使われる特定用語は、本発明の理解を助けるために提供されたものであり、このような特定用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更されてもよい。

場合によって、本発明の概念が曖昧になることを避けるために公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示してもよい。また、本明細書全体を通じて同一の構成要素には同一の図面符号を付して説明する。

本発明の実施例はＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）８０２系列システム、３ＧＰＰシステム、３ＧＰＰＬＴＥ、ＬＴＥ−Ａシステム、及び３ＧＰＰ２システムの少なくとも一つに関して開示された標準文書によってサポートすることができる。すなわち、本発明の実施例において、本発明の技術的思想を明確にするために説明していない段階又は部分は、上記の文書によって裏付けることができる。また、本文書で開示している用語はいずれも上記の標準文書によって説明することができる。

様々な無線通信システムで以下の技術を用いることができる。明確性のために以下では３ＧＰＰＬＴＥ及び３ＧＰＰＬＴＥ−Ａシステムを中心に説明するが、本発明の技術的思想がこれに制限されるものではない。

本文書で使われる用語を定義すると、次のようになる。

− ＵＭＴＳ（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍ）：３ＧＰＰによって開発された、ＧＳＭ（登録商標）（ＧｌｏｂａｌＳｙｓｔｅｍｆｏｒＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎ）ベースの３世代（Ｇｅｎｅｒａｔｉｏｎ）移動通信技術。

− ＥＰＳ（ＥｖｏｌｖｅｄＰａｃｋｅｔＳｙｓｔｅｍ）：ＩＰベースのパケット交換コアネットワーク（ｐａｃｋｅｔｓｗｉｔｃｈｅｄｃｏｒｅｎｅｔｗｏｒｋ）であるＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）と、ＬＴＥ、ＵＴＲＡＮなどのアクセスネットワークとで構成されたネットワークシステム。ＵＭＴＳが進化した形態のネットワークである。

− ＮｏｄｅＢ：ＧＥＲＡＮ／ＵＴＲＡＮの基地局。屋外に設置し、カバレッジはマクロセル（ｍａｃｒｏｃｅｌｌ）規模である。

− ｅＮｏｄｅＢ：ＬＴＥの基地局。屋外に設置し、カバレッジはマクロセル規模である。

− ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ）：ユーザ機器。ＵＥは、端末（ｔｅｒｍｉｎａｌ）、ＭＥ（ＭｏｂｉｌｅＥｑｕｉｐｍｅｎｔ）、ＭＳ（ＭｏｂｉｌｅＳｔａｔｉｏｎ）などと呼ぶこともできる。また、ＵＥはノートパソコン、携帯電話、ＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）、スマートフォン、マルチメディア機器などのような携帯可能な機器であってもよく、又はＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）、車両搭載装置のような携帯できない機器であってもよい。

− ＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）：３ＧＰＰネットワークにおいてＮｏｄｅＢ、ｅＮｏｄｅＢ及びこれらを制御するＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）を含む単位。ＵＥとコアネットワークとの間に存在し、コアネットワークへの接続を提供する。

− ＨＬＲ（ＨｏｍｅＬｏｃａｔｉｏｎＲｅｇｉｓｔｅｒ）／ＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）：３ＧＰＰネットワーク内の加入者情報を有しているデータベース。ＨＳＳは、設定記憶（ｃｏｎｆｉｇｕｒａｔｉｏｎｓｔｏｒａｇｅ）、アイデンティティ管理（ｉｄｅｎｔｉｔｙｍａｎａｇｅｍｅｎｔ）、ユーザ状態記憶などの機能を果たすことができる。

− ＲＡＮＡＰ（ＲＡＮＡｐｐｌｉｃａｔｉｏｎＰａｒｔ）：ＲＡＮとコアネットワークの制御を担当するノード（ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）／ＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔｉｎｇＮｏｄｅ）／ＭＳＣ（ＭｏｂｉｌｅｓＳｗｉｔｃｈｉｎｇＣｅｎｔｅｒ））間のインターフェース。

− ＰＬＭＮ（ＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ）：個人に移動通信サービスを提供する目的で構成したネットワーク。オペレータ別に区別して構成することができる。

− ＮＡＳ（Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ）：ＵＭＴＳプロトコルスタックにおいてＵＥとコアネットワーク間のシグナリング、トラフィックメッセージをやり取りするための機能的な層。ＵＥの移動性を支援し、ＵＥとＰＤＮＧＷ（ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ）間のＩＰ接続を確立（ｅｓｔａｂｌｉｓｈ）及び維持（ｍａｉｎｔａｉｎ）するセッション管理手順（ｐｒｏｃｅｄｕｒｅ）を支援することを主な機能とする。

− ＨＮＢ（ＨｏｍｅＮｏｄｅＢ）：ＵＴＲＡＮ（ＵＭＴＳＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）カバレッジを提供するＣＰＥ（ＣｕｓｔｏｍｅｒＰｒｅｍｉｓｅｓＥｑｕｉｐｍｅｎｔ）。より具体的な事項については標準文書３ＧＰＰＴＳ２５．４６７を参照すればよい。

− ＨｅＮＢ（ＨｏｍｅｅＮｏｄｅＢ）：Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＴＲＡＮ）カバレッジを提供するＣＰＥ。より具体的な事項については標準文書３ＧＰＰＴＳ３６．３００を参照すればよい。

− ＣＳＧ（ＣｌｏｓｅｄＳｕｂｓｃｒｉｂｅｒＧｒｏｕｐ）：Ｈ（ｅ）ＮＢのＣＳＧの構成員であり、ＰＬＭＮ（ＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ）内の一つ以上のＣＳＧセルにアクセスすることが許容される加入者グループ。

− ＣＳＧＩＤ：ＣＳＧセル又はＣＳＧセルグループに関連したＰＬＭＮ範囲内でＣＳＧを識別する固有の識別子。より具体的な事項は、標準文書３ＧＰＰＴＳ２３．００３を参照すればよい。

− ＬＩＰＡ（ＬｏｃａｌＩＰＡｃｃｅｓｓ）：ＩＰ機能を持つ（ＩＰｃａｐａｂｌｅ）ＵＥがＨ（ｅ）ＮＢを経由して同一の住居（ｒｅｓｉｄｅｎｔｉａｌ）／企業（ｅｎｔｅｒｐｒｉｓｅ）ＩＰネットワーク内の他のＩＰ機能を持つ個体にアクセス。ＬＩＰＡトラフィックは移動事業者（ｏｐｅｒａｔｏｒ）ネットワークを経由しない。３ＧＰＰリリース−１０システムでは、Ｈ（ｅ）ＮＢを経由してローカルネットワーク（すなわち、顧客（ｃｕｓｔｏｍｅｒ）の家又は会社の構内に位置しているネットワーク）上のリソースへのアクセスを提供する。

− ＭＲＡ（ＭａｎａｇｅｄＲｅｍｏｔｅＡｃｃｅｓｓ）：ホームベースのネットワーク（ｈｏｍｅｂａｓｅｄｎｅｔｗｏｒｋ）の外部からＣＳＧユーザがホームネットワークに接続しているＩＰ機能を持つ個体へアクセス。例えば、ＭＲＡを用いると、ローカルネットワークの外部に位置しているユーザが、当該ローカルネットワークからユーザデータを受けることができる。

− ＳＩＰＴＯ（ＳｅｌｅｃｔｅｄＩＰＴｒａｆｆｉｃＯｆｆｌｏａｄ）：３ＧＰＰリリース−１０システムでは事業者がＥＰＣネットワークにおいてＵＥと物理的に近くに位置しているＰＧＷ（ＰａｃｋｅｔｄａｔａｎｅｔｗｏｒｋＧａｔｅＷａｙ）を選択することによってユーザのトラフィックを渡すことを支援する。

− ＳＩＰＴＯ＠ＬＮ（ＳＩＰＴＯａｔＬｏｃａｌＮｅｔｗｏｒｋ）：３ＧＰＰリリース−１０のＳＩＰＴＯの発展した技術であり、事業者がユーザトラフィックを顧客の構内に位置するローカルネットワークを通じて渡すことを意味する。ＳＩＰＴＯ＠ＬＮは、ローカルネットワーク自体のリソースへのアクセスを提供するＬＩＰＡとは違い、ローカルネットワークを経由して外部ネットワーク（例えば、インターネット）に対するアクセスを提供するという点で区別される。これは、ローカルネットワークが窮極としては所望の外部ネットワークへの接続を有するという仮定の下に動作するものである。

− ＰＤＮ（ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋ）接続：一つのＩＰアドレス（一つのＩＰｖ４アドレス及び／又は一つのＩＰｖ６プレフィックス）で表現されるＵＥとＡＰＮ（ＡｃｃｅｓｓＰｏｉｎｔＮａｍｅ）で表現されるＰＤＮとの論理的な接続。

− ＬＩＰＡＰＤＮ接続：Ｈ（ｅ）ＮＢに接続したＵＥに対するＬＩＰＡのためのＰＤＮ接続。

− ＬＩＰＡ−Ｐｅｒｍｉｓｓｉｏｎ：ＡＰＮがＬＩＰＡを通じてアクセスできるか否かを表し、次の３つの値が定義されている：

− ＬＩＰＡ−Ｐｒｏｈｉｂｉｔｅｄ：該当のＡＰＮがＬＩＰＡを通じてアクセスすることが禁止される。すなわち、ユーザプレーン（ｕｓｅｒｐｌａｎｅ）データはＥＰＣのみを経由してアクセスすることができる。

− ＬＩＰＡ−Ｏｎｌｙ：該当のＡＰＮがＬＩＰＡを通じてのみアクセスすることができる。

− ＬＩＰＡ−Ｃｏｎｄｉｔｉｏｎａｌ：該当のＡＰＮが非ＬＩＰＡ方式で（すなわち、ＥＰＣを経由して）アクセスしてもよく、ＬＩＰＡを通じてアクセスしてもよい。

− ＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）：マルチメディアサービスをＩＰベースで提供するシステム

− アプリケーションサーバー（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）：様々なマルチメディアサービスを提供するサーバー

− マルチメディアセッション持続性（Ｍｕｌｔｉ−ＭｅｄｉａＳｅｓｓｉｏｎＣｏｎｔｉｎｕｉｔｙ）：進行中のセッションに対して持続性を維持しながら端末の移動性（ｔｅｒｍｉｎａｌｍｏｂｉｌｉｔｙ）や端末間移動性（ｍｏｂｉｌｉｔｙｂｅｔｗｅｅｎＵＥｓ）を支援する

− ＳＣＣＡＳ（ＳｅｒｖｉｃｅＣｅｎｔｒａｌｉｚａｔｉｏｎａｎｄＣｏｎｔｉｎｕｉｔｙＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）：マルチメディアセッション持続性を支援するアプリケーションサーバー。より具体的な事項は、標準文書３ＧＰＰＴＳ２３．２９２及び３ＧＰＰＴＳ２３．２３７を参照すればよい。

− ＣＳＦＢ（ＣｉｒｃｕｉｔＳｗｉｔｃｈｅｄＦａｌｌＢａｃｋ）：Ｅ−ＵＴＲＡＮａｃｃｅｓｓにある端末をＵＴＲＡＮ／ＧＥＲＡＮＣＳｄｏｍａｉｎａｃｃｅｓｓにフォールバックさせることによってｖｏｉｃｅ及び他のＣＳ−ｄｏｍａｉｎサービスを提供する技術。より具体的な事項は標準文書３ＧＰＰＴＳ２３．２７２を参照すればよい。

以下では上記のように定義された用語に基づいて説明する。

図１は、ＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）を含むＥＰＳ（ＥｖｏｌｖｅｄＰａｃｋｅｔＳｙｓｔｅｍ）の概略的な構造を示す図である。

ＥＰＣは、３ＧＰＰ技術の性能を向上するためのＳＡＥ（ＳｙｓｔｅｍＡｒｃｈｉｔｅｃｔｕｒｅＥｖｏｌｕｔｉｏｎ）の核心的な要素である。ＳＡＥは、種々のネットワーク間の移動性を支援するネットワーク構造を決定する研究課題に該当する。ＳＡＥは、例えば、ＩＰベースに様々な無線接続技術を支援し、より向上したデータ送信能力を提供するなどの最適化したパケットベースのシステムを提供することを目標とする。

具体的に、ＥＰＣは３ＧＰＰＬＴＥシステムのためのＩＰ移動通信システムのコアネットワーク（ＣｏｒｅＮｅｔｗｏｒｋ）であり、パケットベースの実時間及び非実時間サービスを支援することができる。既存の移動通信システム（すなわち、２世代又は３世代移動通信システム）では音声のためのＣＳ（Ｃｉｒｃｕｉｔ−Ｓｗｉｔｃｈｅｄ）及びデータのためのＰＳ（Ｐａｃｋｅｔ−Ｓｗｉｔｃｈｅｄ）の２個の区別されるサブドメインを通じてコアネットワークの機能が具現された。しかし、３世代移動通信システムの進化である３ＧＰＰＬＴＥシステムでは、ＣＳ及びＰＳのサブドメインが一つのＩＰドメインに単一化した。すなわち、３ＧＰＰＬＴＥシステムでは、ＩＰ能力（ｃａｐａｂｉｌｉｔｙ）を持つ端末と端末間の接続をＩＰベースの基地局（例えば、ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄＮｏｄｅＢ））、ＥＰＣ、アプリケーションドメイン（例えば、ＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ））を通じて構成することができる。すなわち、ＥＰＣは端−対−端（ｅｎｄ−ｔｏ−ｅｎｄ）ＩＰサービス具現に必須な構造である。

ＥＰＣは様々な構成要素を含むことができ、図１では、その一部に該当する、ＳＧＷ（ＳｅｒｖｉｎｇＧａｔｅｗａｙ）、ＰＤＮＧＷ（ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋＧａｔｅｗａｙ）、ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）、ＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔｉｎｇＮｏｄｅ）、ｅＰＤＧ（ｅｎｈａｎｃｅｄＰａｃｋｅｔＤａｔａＧａｔｅｗａｙ）を示す。

ＳＧＷ（又は、Ｓ−ＧＷ）は、無線接続ネットワーク（ＲＡＮ）とコアネットワーク間の境界点として動作し、ｅＮｏｄｅＢとＰＤＮＧＷ間のデータ経路を維持する機能を担う要素である。また、端末がｅＮｏｄｅＢによってサービング（ｓｅｒｖｉｎｇ）される領域にわたって移動する場合、ＳＧＷはローカル移動性アンカーポイント（ａｎｃｈｏｒｐｏｉｎｔ）の役割を担う。すなわち、Ｅ−ＵＴＲＡＮ（３ＧＰＰリリース−８以降で定義されるＥｖｏｌｖｅｄ−ＵＭＴＳ（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍ）ＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）内での移動性のためにＳＧＷを介してパケットをルーティングすることができる。また、ＳＧＷは他の３ＧＰＰネットワーク（３ＧＰＰリリース−８の前に定義されるＲＡＮ、例えば、ＵＴＲＡＮ又はＧＥＲＡＮ（ＧＳＭ（登録商標）（ＧｌｏｂａｌＳｙｓｔｅｍｆｏｒＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎ）／ＥＤＧＥ（ＥｎｈａｎｃｅｄＤａｔａｒａｔｅｓｆｏｒＧｌｏｂａｌＥｖｏｌｕｔｉｏｎ）ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）との移動性のためのアンカーポイントとして機能することもできる。

ＰＤＮＧＷ（又は、Ｐ−ＧＷ）は、パケットデータネットワークに向かうデータインターフェースの終了点（ｔｅｒｍｉｎａｔｉｏｎｐｏｉｎｔ）に該当する。ＰＤＮＧＷは政策執行特徴（ｐｏｌｉｃｙｅｎｆｏｒｃｅｍｅｎｔｆｅａｔｕｒｅｓ）、パケットフィルタリング（ｐａｃｋｅｔｆｉｌｔｅｒｉｎｇ）、課金支援（ｃｈａｒｇｉｎｇｓｕｐｐｏｒｔ）などを支援することができる。また、３ＧＰＰネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ネットワーク（例えば、Ｉ−ＷＬＡＮ（ＩｎｔｅｒｗｏｒｋｉｎｇＷｉｒｅｌｅｓｓＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）のような信頼されないネットワーク、ＣＤＭＡ（ＣｏｄｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）ネットワークやＷｉＭａｘのような信頼されるネットワーク）との移動性管理のためのアンカーポイントの役割を担うことができる。

図１のネットワーク構造の例示では、ＳＧＷとＰＤＮＧＷを別のゲートウェイとしているが、両ゲートウェイを単一ゲートウェイ構成オプション（ＳｉｎｇｌｅＧａｔｅｗａｙＣｏｎｆｉｇｕｒａｔｉｏｎＯｐｔｉｏｎ）によって構成することもできる。

ＭＭＥは、ＵＥのネットワーク接続に対するアクセス、ネットワークリソースの割当、トラッキング（ｔｒａｃｋｉｎｇ）、ページング（ｐａｇｉｎｇ）、ローミング（ｒｏａｍｉｎｇ）及びハンドオーバーなどを支援するためのシグナリング及び制御機能を行う要素である。ＭＭＥは加入者及びセッション管理に関連した制御プレーン機能を制御する。ＭＭＥは多数のｅＮｏｄｅＢを管理し、他の２Ｇ／３Ｇネットワークへのハンドオーバーのための従来のゲートウェイの選択のためのシグナリングを行う。また、ＭＭＥは、保安過程（ＳｅｃｕｒｉｔｙＰｒｏｃｅｄｕｒｅｓ）、端末−対−ネットワークセッションハンドリング（Ｔｅｒｍｉｎａｌ−ｔｏ−ｎｅｔｗｏｒｋＳｅｓｓｉｏｎＨａｎｄｌｉｎｇ）、遊休端末位置決定管理（ＩｄｌｅＴｅｒｍｉｎａｌＬｏｃａｔｉｏｎＭａｎａｇｅｍｅｎｔ）などの機能を担う。

ＳＧＳＮは、他の３ＧＰＰネットワーク（例えば、ＧＰＲＳネットワーク）に対するユーザの移動性管理及び認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）のような全てのパケットデータをハンドリングする。

ｅＰＤＧは、信頼されない非−３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ、ＷｉＦｉホットスポット（ｈｏｔｓｐｏｔ）など）に対する保安ノードとして機能する。

図１を参照して説明したように、ＩＰ能力を持つ端末は、３ＧＰＰアクセスの他、非−３ＧＰＰアクセスに基づいても、ＥＰＣ内の様々な要素を経由して事業者（すなわち、オペレータ（ｏｐｅｒａｔｏｒ））が提供するＩＰサービスネットワーク（例えば、ＩＭＳ）にアクセスすることができる。

また、図１では、様々なレファレンスポイント（例えば、Ｓ１−Ｕ、Ｓ１−ＭＭＥなど）を示す。３ＧＰＰシステムではＥ−ＵＴＲＡＮ及びＥＰＣにおける異なった機能個体（ｆｕｎｃｔｉｏｎａｌｅｎｔｉｔｙ）に存在する２個の機能を接続する概念的なリンクをレファレンスポイント（ｒｅｆｅｒｅｎｃｅｐｏｉｎｔ）と定義する。次の表１は、図１に示したレファレンスポイントを整理したものである。表１の例示の他にも、ネットワーク構造によって様々なレファレンスポイントが存在してもよい。

図１に示すレファレンスポイントのうちＳ２ａ及びＳ２ｂは、非−３ＧＰＰインターフェースに該当する。Ｓ２ａは、信頼される非−３ＧＰＰアクセス及びＰＤＮＧＷ間の関連制御及び移動性支援をユーザプレーンに提供するレファレンスポイントである。Ｓ２ｂは、ｅＰＤＧ及びＰＤＮＧＷ間の関連制御及び移動性支援をユーザプレーンに提供するレファレンスポイントである。

図２は、初期アタッチ（ｉｎｉｔｉａｌａｔｔａｃｈ）手順を説明するための図である。

段階Ｓ２０１〜Ｓ２０２で、ＵＥ１００は、アタッチ手順を開始するためにＭＭＥ３００にアタッチ要請（ＡｔｔａｃｈＲｅｑｕｅｓｔ）メッセージを送信する。該アタッチ要請メッセージはｅＮｏｄｅＢ２００を経てＭＭＥ３００に伝達される。ＵＥ１００は当該アタッチ要請メッセージにＳＲＶＣＣ（ＳｉｎｇｌｅＲａｄｉｏＶｏｉｃｅＣａｌｌＣｏｎｔｉｎｕｉｔｙ）能力（ｃａｐａｂｉｌｉｔｙ）情報を含めることができる。

段階Ｓ２０３で、完全性保障（Ｉｎｔｅｇｒｉｔｙｐｒｏｔｅｃｔｉｏｎ）及びＮＡＳ暗号（ｃｉｐｈｅｒｉｎｇ）を活性化（ａｃｔｉｖａｔｅ）するために認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）及びＮＡＳセキュリティセットアップ（ｓｅｃｕｒｉｔｙｓｅｔｕｐ）が行われてよい。この段階は、ネットワークにＵＥ１００に対するＵＥコンテクスト（ｃｏｎｔｅｘｔ）がない場合、又は上記段階Ｓ２０１で送信されたアタッチ要請メッセージが完全性保障されていない場合などに行われる。

段階Ｓ２０４で、ＭＭＥ３００はＨＳＳ７００に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ）メッセージを送信することができる。この段階は、ＭＭＥがＵＥ１００の最後のデタッチ（ｄｅｔａｃｈ）以降に変更されたり、ＭＭＥ３００がＵＥ１００の有効な加入者コンテクスト（ｓｕｂｓｃｒｉｐｔｉｏｎｃｏｎｔｅｘｔ）を有していない場合などに行われる。

段階Ｓ２０５で、ＨＳＳ７００はＵＥ１００に関する加入者情報を含む位置更新応答（ＵｐｄａｔｅＬｏｃａｔｉｏｎＡｎｓｗｅｒ）メッセージをＭＭＥ３００に送信する。

段階Ｓ２０６で、ＭＭＥ３００は、Ｓ−ＧＷを選択し、ＵＥと関連したデフォルトベアラ（ｄｅｆａｕｌｔｂｅａｒｅｒ）のためのＥＰＳベアラ識別子（ＢｅａｒｅｒＩｄｅｎｔｉｔｙ）を割り当てる。そして、ＭＭＥ３００は、選択したＳ−ＧＷ４００にセッション生成要請（ＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ）メッセージを送信する。

仮に、ＭＭＥがＰＳセッション（又はドメイン）でのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値を決定するためにＵＥ１００に関するボイス支援マッチ指示子（ＶｏｉｃｅＳｕｐｐｏｒｔＭａｔｃｈＩｎｄｉｃａｔｏｒ）情報を必要とするなら、ＭＭＥ３００はｅＮｏｄｅＢ２００にＵＥ無線能力マッチ要請（ＲａｄｉｏＣａｐａｂｉｌｉｔｙＭａｔｃｈＲｅｑｕｅｓｔ）メッセージを送信する。このようなＵＥ無線能力マッチ要請動作については後述する。

段階Ｓ２０７で、Ｓ−ＧＷ４００は自身のＥＰＳベアラテーブルに新しいエントリーを生成し、ＭＭＥ３００から受信したセッション生成要請メッセージ内のＰ−ＧＷアドレス情報に基づいて上記のＰ−ＧＷ５００にセッション生成要請メッセージを送信する。

段階Ｓ２０８で、Ｐ−ＧＷ５００はＰＣＲＦ６００とＩＰ−ＣＡＮセッション確立／修正（ＳｅｓｓｉｏｎＥｓｔａｂｌｉｓｈｍｅｎｔ／Ｍｏｄｉｆｉｃａｔｉｏｎ）を行うことができる。この段階は、動的なＰＣＣ（ｄｙｎａｍｉｃＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＣｏｎｔｒｏｌ）が配置（ｄｅｐｌｏｙ）されている場合に行われる。

段階Ｓ２０９で、Ｐ−ＧＷ５００は自身のＥＰＳベアラコンテクストテーブルに新しいエントリーを生成し、Ｓ−ＧＷ４００にセッション生成応答（ＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅ）メッセージを送信する。

ＵＥがハンドオーバーをする場合以外は、この段階以降からはＵＥ１００への下りリンクデータをＰ−ＧＷ５００からＳ−ＧＷ４００に伝達することができる。

段階Ｓ２１０で、Ｓ−ＧＷ４００はＭＭＥ３００にセッション生成応答メッセージを送信する。

段階Ｓ２１１で、ＭＭＥ３００は、ＵＥ１００に送るアタッチ受諾（ＡｔｔａｃｈＡｃｃｅｐｔ）メッセージを含む初期コンテクストセットアップ要請（ＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｑｕｅｓｔ）メッセージをｅＮｏｄｅＢ２００に送信する。このアタッチ受諾メッセージはＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）情報を含む。前述したように、ＭＭＥはＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値を決定時に、下記要素の一つ以上の要素を考慮することができる。

− ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報：ボイス支援マッチ指示子情報及び／又はＵＥが提供するＳＲＶＣＣ能力情報

− ｌｏｃａｌｐｏｌｉｃｙ

− ＨＰＬＭＮ（ＨｏｍｅＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ）

− ネットワークのＳＲＶＣＣ能力

− ｅｘｔｅｎｄｓｏｆＥ−ＵＴＲＡＮ／ＵＴＲＡＮｃｏｖｅｒａｇｅ

− ＵＥがローミング（ｒｏａｍｉｎｇ）状態の場合、ＵＥのＨＰＬＭＮとのローミング協定（ｒｏａｍｉｎｇａｇｒｅｅｍｅｎｔ）

段階Ｓ２１２で、ｅＮｏｄｅＢ２００はＵＥ１００に、上記ＭＭＥ３００から受信したアタッチ受諾メッセージに加えて、ＥＰＳ無線ベアラ識別子情報を含むＲＲＣ接続再設定（ＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信する。

段階Ｓ２１３で、ＵＥ１００は、ＲＲＣ接続再設定完了（ＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージをｅＮｏｄｅＢ２００に送信する。

段階Ｓ２１４で、ｅＮｏｄｅＢ２００はＭＭＥ３００に初期コンテクストセットアップ応答（ＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｓｐｏｎｓｅ）メッセージを送信する。

段階Ｓ２１５で、ＵＥ１００は、ＭＭＥに送るアタッチ完了（ＡｔｔａｃｈＣｏｍｐｌｅｔｅ）メッセージを含む直接送信（ＤｉｒｅｃｔＴｒａｎｓｆｅｒ）メッセージをｅＮｏｄｅＢ２００に送信する。

段階Ｓ２１６で、ｅＮｏｄｅＢ２００は、ＵＥから受信したアタッチ完了メッセージをＭＭＥ３００に伝達する。

この段階以降からＵＥ１００は上りリンクデータを送信することができる。

段階Ｓ２１７で、上記段階Ｓ２１４及び段階Ｓ２１６で初期コンテクストセットアップ応答メッセージ及びアタッチ完了メッセージの両方を受信したＭＭＥ３００は、Ｓ−ＧＷ４００にベアラ修正要請（ＭｏｄｉｆｙＢｅａｒｅｒＲｅｑｕｅｓｔ）メッセージを送信する。

段階Ｓ２１８で、Ｓ−ＧＷ４００は、Ｐ−ＧＷ５００にベアラ修正要請メッセージを送信することができる。この段階は、上記段階Ｓ２１７で受信したベアラ修正要請メッセージがハンドオーバー指示情報を含んでいる場合に行われる。

段階Ｓ２１９で、Ｐ−ＧＷ５００はベアラ修正応答メッセージでＳ−ＧＷ４００に応答する。

段階Ｓ２２０で、Ｓ−ＧＷ４００はベアラ修正応答メッセージでＭＭＥ３００に応答する。以降、Ｓ−ＧＷ４００はＵＥ１００に下りリンクデータを伝達することができる。

段階Ｓ２２１で、非３ＧＰＰアクセスネットワークへの移動性（ｍｏｂｉｌｉｔｙ）を支援するためにＡＰＮ、ＰＤＮＧＷのＩＤなどをＨＳＳ７００に記憶させておかなければならない場合に、ＭＭＥ３００は報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージを用いてＨＳＳ登録過程を行うことができる。

段階Ｓ２２２で、ＨＳＳ７００は報知応答（ＮｏｔｉｆｙＡｎｓｗｅｒ）メッセージでＭＭＥ３００に応答する。

図３は、ＴＡＵ（ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅ）手順を説明するための図である。

図３を参照すると、段階Ｓ３０１〜Ｓ３０２で、ＵＥ１００は、ＴＡＵ手順を開始するためにＭＭＥ３００にＴＡＵ要請（ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔ）メッセージを送信する。このＴＡＵ要請メッセージはｅＮｏｄｅＢ２００を経てＮｅｗＭＭＥ３００に伝達される。ＵＥ１００はＴＡＵ要請メッセージにＳＲＶＣＣ能力情報を含めることができる。

段階Ｓ３０３で、ＮｅｗＭＭＥ３００は、ユーザ情報を獲得するためにＯｌｄＭＭＥ３１０にコンテクスト要請（ＣｏｎｔｅｘｔＲｅｑｕｅｓｔ）メッセージを送信する。

段階Ｓ３０４で、ＯｌｄＭＭＥ３１０はコンテクスト応答（ＣｏｎｔｅｘｔＲｅｓｐｏｎｓｅ）メッセージでＮｅｗＭＭＥ３００に応答する。このコンテクスト応答メッセージはＭＭコンテクスト内にＵＥ１００に関するボイス支援マッチ指示子情報を含むことができる。

段階Ｓ３０５で、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）及びセキュリティセットアップ（ｓｅｃｕｒｉｔｙｓｅｔｕｐ）を行うことができる。この段階は、上記段階Ｓ３０１で送信されたＴＡＵ要請メッセージが完全性保障されていない場合などに行われる。

段階Ｓ３０６で、ＮｅｗＭＭＥ３００はＯｌｄＭＭＥ３１０にコンテクスト確認（ＣｏｎｔｅｘｔＡｃｋｎｏｗｌｅｄｇｅ）メッセージを送信する。

段階Ｓ３０７で、ＮｅｗＭＭＥ３００はＳ−ＧＷ４００にＰＤＮ接続当たりにベアラ修正要請（ＭｏｄｉｆｙＢｅａｒｅｒＲｅｑｕｅｓｔ）メッセージを送信する。

段階Ｓ３０８で、Ｓ−ＧＷ４００はＰ−ＧＷ５００にＰＤＮ接続当たりにベアラ修正要請メッセージを送信することができる。この段階は、Ｓ−ＧＷ４００がＰ−ＧＷ５００に情報（例えば、変更されたＲＡＴｔｙｐｅ、ユーザの位置情報など）を知らせる必要がある場合に行われる。

段階Ｓ３０９で、Ｐ−ＧＷ５００はＰＣＲＦ６００とＩＰ−ＣＡＮセッション修正（ＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎ）を行うことができる。この段階は、動的なＰＣＣが配置（ｄｅｐｌｏｙ）されており、Ｐ−ＧＷ５００がＰＣＲＦ６００に情報を提供する必要がある場合に行われる。

段階Ｓ３１０で、Ｐ−ＧＷ５００はベアラ修正応答（ＭｏｄｉｆｙＢｅａｒｅｒＲｅｓｐｏｎｓｅ）メッセージでＳ−ＧＷ４００に応答する。

段階Ｓ３１１で、Ｓ−ＧＷ４００はベアラ修正応答メッセージでＮｅｗＭＭＥ３００に応答する。

段階Ｓ３１２で、ＮｅｗＭＭＥ３００はＨＳＳ７００に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ）メッセージを送信することができる。この段階は、ＮｅｗＭＭＥ３００がＵＥ１００に関する加入者情報（ｓｕｂｓｃｒｉｐｔｉｏｎｄａｔａ）がない場合などに行われる。

段階Ｓ３１３で、ＨＳＳ７００はＯｌｄＭＭＥ３１０に位置削除（ＣａｎｃｅｌＬｏｃａｔｉｏｎ）メッセージを送信する。

段階Ｓ３１４で、ＯｌｄＭＭＥ３１０は位置削除確認（ＣａｎｃｅｌＬｏｃａｔｉｏｎＡｃｋ）メッセージでＨＳＳ７００に応答する。

段階Ｓ３１５で、ＨＳＳ７００はＵＥ１００に関する加入者情報を含む位置更新応答（ＵｐｄａｔｅＬｏｃａｔｉｏｎＡｎｓｗｅｒ）メッセージをＮｅｗＭＭＥ３００に送信する。

段階Ｓ３１６で、ＮｅｗＭＭＥ３００が上記段階Ｓ３０４でＯｌｄＭＭＥ３１０からボイス支援マッチ指示子情報を受信できなかった場合、ＮｅｗＭＭＥ３００はｅＮｏｄｅＢ２００にＵＥ無線能力マッチ要請（ＲａｄｉｏＣａｐａｂｉｌｉｔｙＭａｔｃｈＲｅｑｕｅｓｔ）メッセージを送信する。このようなＵＥ無線能力マッチ要請動作は、図２で前述した内容に従う。ＮｅｗＭＭＥ３００はＵＥ１００にＴＡＵ受諾（ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅＡｃｃｅｐｔ）メッセージを送信する。ＴＡＵ受諾メッセージは、ＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）情報を含む。ＮｅｗＭＭＥ３００がＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値を決定時に考慮する要素は、図２の段階Ｓ２１１で説明した通りである。

段階Ｓ３１７で、ＵＥ１００はＴＡＵ完了（ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅＣｏｍｐｌｅｔｅ）メッセージをＮｅｗＭＭＥ３００に送信することができる。この段階は、ＧＵＴＩ（ＧｌｏｂａｌｌｙＵｎｉｑｕｅＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｔｙ）情報が変更された場合に行われる。

図２乃至図３で説明された、アタッチ又はＴＡＵ手順においてＭＭＥがＨＳＳに送信する位置更新要請は、ＰＳセッションでのＩＭＳボイスの同種支援（ＨｏｍｏｇｅｎｅｏｕｓＳｕｐｐｏｒｔｏｆＩＭＳＶｏｉｃｅＯｖｅｒＰＳＳｅｓｓｉｏｎｓ）情報を含むことができる。

例えば、図２の段階Ｓ２０４でＭＭＥがＨＳＳに位置更新要請を送信する時、位置更新要請メッセージは次の４つの基準に基づいてＰＳセッションでのＩＭＳボイスの同種支援情報を含むこともあり、含まないこともある。

ｉ）ＭＭＥがサービングする（又は、関連した）全てのＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）が同一に（ｈｏｍｏｇｅｎｅｏｕｓｌｙ）ＰＳセッションでのＩＭＳボイス（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎ）を支援する場合、ＭＭＥはＰＳセッションでのＩＭＳボイスの同種支援値をＳｕｐｐｏｒｔｅｄ（又は１又はＴｒｕｅ）に設定して位置更新要請メッセージに含める。（これは、ＭＭＥがサービングする全てのＴＡで‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＬＴＥが支援されることを意味する）

ｉｉ）ＭＭＥがサービングする（又は、関連した）全てのＴＡが同一にＰＳセッションでのＩＭＳボイスを支援しない場合、ＭＭＥはＰＳセッションでのＩＭＳボイスの同種支援値をＮｏｔ＿Ｓｕｐｐｏｒｔｅｄ（或いは、０又はＦａｌｓｅ）に設定して位置更新要請メッセージに含める。（これは、ＭＭＥがサービングする全てのＴＡで‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＬＴＥが支援されないことを意味する。換言すれば、ＭＭＥがサービングする全てのＴＡでＣＳフォールバック（ＣＳＦＢ）によって音声サービスが支援されることを意味する）

ｉｉｉ）ＭＭＥがサービングする（又は、関連した）ＴＡのうちの一部のＴＡはＰＳセッションでのＩＭＳボイスを支援するが、残り一部のＴＡはＰＳセッションでのＩＭＳボイスを支援しない場合、ＭＭＥは位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援値を含めない。

ｉｖ）ＭＭＥがサービングする（又は、関連した）ＴＡが同一にＰＳセッションでのＩＭＳボイスを支援するか否かが確認できない場合、ＭＭＥは位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援値を含めない。

また、アタッチ又はＲＡＵ（ＲｏｕｔｅｉｎｇＡｒｅａＵｐｄａｔｅ）手順において行われるＳＧＳＮのＨＳＳへの位置更新要請も同様、ＰＳセッションでのＩＭＳボイスの同種支援情報を含むことができる。

また、ＳＧＳＮはＨＳＳに位置更新要請メッセージを送信時に、次のようにＰＳセッションでのＩＭＳボイスの同種支援情報を含めることもあり、含めないこともある。

ｉ）ＳＧＳＮがサービングする（又は、関連した）全てのＲＡが同一にＰＳセッションでのＩＭＳボイスを支援する場合、ＳＧＳＮはＰＳセッションでのＩＭＳボイスの同種支援値をＳｕｐｐｏｒｔｅｄ（又は、１又はＴｒｕｅ）に設定して位置更新要請メッセージに含める。（これは、ＳＧＳＮがサービングする全てのＲＡで‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＨＳＰＡが支援されることを意味する）

ｉｉ）ＳＧＳＮがサービングする（又は、関連した）全てのＲＡが同一にＰＳセッションでのＩＭＳボイスを支援しない場合、ＳＧＳＮはＰＳセッションでのＩＭＳボイスの同種支援値をＮｏｔ＿Ｓｕｐｐｏｒｔｅｄ（又は、０又はＦａｌｓｅ）に設定して位置更新要請メッセージに含める。（これは、ＳＧＳＮがサービングする全てのＲＡで‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＨＳＰＡが支援されないことを意味する。換言すれば、ＵＥはＵＴＲＡＮで支援するＣＳｖｏｉｃｅサービスを用いるべきということを意味する）

ｉｉｉ）ＳＧＳＮがサービングする（又は、関連した）ＲＡのうちの一部のＲＡはＰＳセッションでのＩＭＳボイスを支援するが、残り一部のＲＡはＰＳセッションでのＩＭＳボイスを支援しない場合、ＳＧＳＮは位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援値を含めない。

ｉｖ）ＳＧＳＮがサービングする（又は、関連した）ＲＡが同一にＰＳセッションでのＩＭＳボイスを支援するか否かが確認できない場合、ＳＧＳＮは位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援値を含めない。

上述したＭＭＥがサービングする（又は、関連した）全てのＴＡ、及びＳＧＳＮがサービングする（又は、関連した）全てのＲＡを、サービングノードのサービス地域（ｓｅｒｖｉｃｅａｒｅａ）と呼ぶものとする。一方、上述したアタッチ又はＴＡＵ又はＲＡＵ手順において、サービングノード（ＭＭＥ又はＳＧＳＮ）はＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）情報を決定することができるが、このとき、ＵＥの無線能力（ｒａｄｉｏｃａｐａｂｉｌｉｔｙ）情報を考慮することができる。ＵＥの無線能力情報はボイス支援マッチ指示子（ＶｏｉｃｅＳｕｐｐｏｒｔＭａｔｃｈＩｎｄｉｃａｔｏｒ）という情報であり、サービングノードはこの情報をＲＡＮ（すなわち、ｅＮｏｄｅＢ又はＲＮＣ）から獲得することができる。サービングノードであるＭＭＥがｅＮｏｄｅＢからボイス支援マッチ指示子という情報を獲得する動作は、図４に示すようになる。この動作は、ＵＥのアタッチ又はＴＡＵ手順においてサービングノードがＨＳＳに位置更新要請を行った以降とＵＥにアタッチ受諾又はＴＡＵ受諾メッセージを送信する前に行われる。以下、図４を参照して、ボイス支援マッチ指示子という情報を獲得する手順について説明する。

段階Ｓ４０１で、ＭＭＥ３００はＵＥ１００のキャンプ−オン（ｃａｍｐ−ｏｎ）したｅＮｏｄｅＢ２００からＵＥ１００に関するボイス支援マッチ指示子情報を獲得するために、ｅＮｏｄｅＢ２００にＵＥ無線能力マッチ要請（ＲａｄｉｏＣａｐａｂｉｌｉｔｙＭａｔｃｈＲｅｑｕｅｓｔ）メッセージを送信する。この時、ＭＭＥ３００は、前にｅＮｏｄｅＢ２００から受信したＵＥ無線能力情報を有している場合はその情報をＵＥ無線能力マッチ要請メッセージに含める。

段階Ｓ４０２で、ｅＮｏｄｅＢ２００がＵＥ１００からＵＥ無線能力情報を獲得できなかった場合、又は上記段階４０１で受信したＵＥ無線能力マッチ要請メッセージがＵＥ無線能力情報を含んでいない場合に、ｅＮｏｄｅＢ２００はＵＥからＵＥ無線能力情報を獲得するために、ＵＥ１００にＵＥ能力エンクイリ（ＣａｐａｂｉｌｉｔｙＥｎｑｕｉｒｙ）メッセージを送信する。

段階Ｓ４０３で、ＵＥ１００はｅＮｏｄｅＢ２００に、ＵＥ無線能力情報を含むＵＥ能力情報（ＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ）メッセージを送信する。

段階Ｓ４０４で、ｅＮｏｄｅＢ２００はＵＥの無線能力情報とネットワークの設定（ｎｅｔｗｏｒｋｃｏｎｆｉｇｕｒａｔｉｏｎ）との互換性（ｃｏｍｐａｔｉｂｉｌｉｔｙ）を確認することによって、ＩＭＳで開始された（ｉｎｉｔｉａｔｅｄ）音声呼のサービス連続性（ｓｅｒｖｉｃｅｃｏｎｔｉｎｕｉｔｙ）を保障できるか否かを決定する。ｅＮｏｄｅＢ２００は、上記決定のために次のうち一つ以上のＵＥ無線能力情報を点検することができる。

− ＳＲＶＣＣ（ＳｉｎｇｌｅＲａｄｉｏＶｏｉｃｅＣａｌｌＣｏｎｔｉｎｕｉｔｙ）能力情報及びＵＴＲＡＮ／Ｅ−ＵＴＲＡＮＶｏｉｃｅｏｖｅｒＰＳｃａｐａｂｉｌｉｔｙ情報

− ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮＦＤＤ及び／又はＴＤＤのための無線能力情報

− ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮ周波数帯域（ｆｒｅｑｕｅｎｃｙｂａｎｄｓ）支援関連情報

ｅＮｏｄｅＢ２００は、ＩＭＳで開始された音声呼のサービス連続性を保障できるか否かを決定した後、それを反映するボイス支援マッチ指示子値を設定してＵＥ無線能力マッチ応答（ＵＥＲａｄｉｏＣａｐａｂｉｌｉｔｙＭａｔｃｈＲｅｓｐｏｎｓｅ）メッセージをＭＭＥ３００に送信する。ｅＮｏｄｅＢ２００はＩＭＳ音声呼のサービス連続性を保障できると判断した場合はボイス支援マッチ指示子値を‘Ｓｕｐｐｏｒｔｅｄ’（或いは、１又はＴｒｕｅ）に設定し、そうでない場合は‘ＮｏｔＳｕｐｐｏｒｔｅｄ’（或いは、０又はＦａｌｓｅ）に設定する。

ＭＭＥ３００は、ＵＥのＭＭ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ）コンテクストに、ｅＮｏｄｅＢ２００から獲得したボイス支援マッチ指示子情報を保存し、この情報を、ＵＥ１００のためのＰＳドメインでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値の決定時に用いる。

段階Ｓ４０５で、ｅＮｏｄｅＢ２００が上記の段階Ｓ４０２、Ｓ４０３を行ってＵＥ１００からＵＥ無線能力情報を獲得した場合に、ｅＮｏｄｅＢ２００はＭＭＥ３００に、上記のＵＥ無線能力情報を含むＵＥ能力情報指示（ＣａｐａｂｉｌｉｔｙＩｎｆｏＩｎｄｉｃａｔｉｏｎ）メッセージを送信する。ＭＭＥ３００は、受信したＵＥ無線能力情報を保存する。ＭＭＥ３００は、上記段階Ｓ４０４のＵＥ無線能力マッチ応答メッセージよりも段階Ｓ４０５のＵＥ能力情報指示メッセージを先に受信することもできる。

ＭＭＥと同様にＳＧＳＮもＵＥのアタッチ又はＲＡＵ時に、ＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値の決定のためにＵＥの無線能力情報を考慮する。したがって、ＳＧＳＮはＲＮＣに、ＵＥに関するボイス支援マッチ指示子情報を獲得するためのＵＥ無線能力マッチ要請動作を行うことができる。その詳細な事項は３ＧＰＰＴＳ２３．０６０を参照すればよい。

また、サービングノードが、ＵＥのアタッチ又はＴＡＵ又はＲＡＵ時に、ＰＳセッションでのＩＭＳボイス支援表示を決定するときに参考にする他の情報としてＵＥのＳＲＶＣＣ能力情報があり、この情報は、ＵＥがサービングノードにアタッチ要請又はＴＡＵ／ＲＡＵ要請メッセージを送信する時に含める。このＵＥのＳＲＶＣＣ能力情報は、アタッチ要請、ＴＡＵ要請、ＲＡＵ要請メッセージの‘ＭＳｎｅｔｗｏｒｋｃａｐａｂｉｌｉｔｙ’情報要素（ｉｎｆｏｒｍａｔｉｏｎｅｌｅｍｅｎｔ（ＩＥ））を構成する次のようなフラグの形態である。

ＳＲＶＣＣｔｏＧＥＲＡＮ／ＵＴＲＡＮｃａｐａｂｉｌｉｔｙ：

０＝ＳＲＶＣＣｆｒｏｍＵＴＲＡＮＨＳＰＡｏｒＥ−ＵＴＲＡＮｔｏＧＥＲＡＮ／ＵＴＲＡＮｎｏｔｓｕｐｐｏｒｔｅｄ

１＝ＳＲＶＣＣｆｒｏｍＵＴＲＡＮＨＳＰＡｏｒＥ−ＵＴＲＡＮｔｏＧＥＲＡＮ／ＵＴＲＡＮｓｕｐｐｏｒｔｅｄ

上述したように、サービングノードがＵＥにＩＭＳドメインでボイスサービスを提供するか否かを決定（すなわち、ＵＥに提供する、ＰＳセッションでのＩＭＳボイス支援表示（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳＳｅｓｓｉｏｎＳｕｐｐｏｒｔｅｄＩｎｄｉｃａｔｉｏｎ）値を決定）する時に考慮するＵＥの能力情報として、ＲＡＮ（ｅＮｏｄｅＢ／ＲＮＣ）が提供するボイス支援マッチ指示子情報、及びＵＥがアタッチ、ＴＡＵ、ＲＡＵ動作時に提供するＳＲＶＣＣ能力情報がある。本発明では、ボイス支援マッチ指示子情報及び／又はＵＥがアタッチ、ＴＡＵ、ＲＡＵ動作時に提供するＳＲＶＣＣ能力情報を、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報と呼ぶものとする。

参考として、サービングノードはＰＳセッションでのＩＭＳボイス支援表示値を決定時に、上記情報の両方を考慮してもよく、いずれか一方の情報のみを考慮してもよい。

ＭＭＥは、ＰＳセッションでのＩＭＳボイス支援表示値を決定時に、上記のＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報に加えて、地域政策（ｌｏｃａｌｐｏｌｉｃｙ）、ＨＰＬＭＮ、ネットワークのＳＲＶＣＣ能力、ｅｘｔｅｎｄｓｏｆＥ−ＵＴＲＡＮ／ＵＴＲＡＮｃｏｖｅｒａｇｅなどをさらに考慮することができる。ＳＧＳＮは、ＰＳセッションでのＩＭＳボイス支援表示値を決定時に、上記のＵＥのＶｏｉｃｅｏｖｅｒＩＭＳ関連能力情報に加えて、地域政策、ＨＰＬＭＮ、ネットワークのＳＲＶＣＣ能力、ｌｅｖｅｌｏｆＵＴＲＡＮｃｏｖｅｒａｇｅなどをさらに考慮することができる。

前述したように、ＰＳセッションでのＩＭＳボイス支援表示情報は、ＵＥのサービングＰＬＭＮがＵＥに知らせる情報であり、これは、ＵＥがサービングＰＬＭＮで成功的にＰＳセッションでのＩＭＳボイス（ＩＭＳｖｏｉｃｅｏｖｅｒＰＳｓｅｓｓｉｏｎ）を使用できるということを指す。この情報は、ＵＥがＭＭＥにアタッチ又はＴＡＵ動作時にアタッチ受諾メッセージ又はＴＡＵ受諾メッセージを通じて獲得することができる。また、この情報は、ＵＥがＳＧＳＮにアタッチ又はＲＡＵ動作時にアタッチ受諾メッセージ又はＲＡＵ受諾メッセージを通じて獲得することができる。

図５は、着信音声呼（ｔｅｒｍｉｎａｔｉｎｇｖｏｉｃｅｃａｌｌ）に対するドメイン選択に関する動作を説明するための図である。

ＩＭＳ網のＳＣＣＡＳがＵＥへの着信音声呼を受信すると、ＵＥをサービングするネットワークの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’支援に関する情報を獲得するためにＨＳＳにクエリーを送り、ＨＳＳは、ＵＥの登録されたサービングノード（すなわち、ＭＭＥ及び／又はＳＧＳＮ）から上記情報を獲得し、該情報に基づいてＳＣＣＡＳにクエリーに対する応答をする。仮に、ＨＳＳがＭＭＥ又はＳＧＳＮから受信した、ＰＳセッションでのＩＭＳボイスの同種支援情報がある場合は、クエリーすることを飛ばすことができる。以下、各段階についてより詳しく説明する。

段階Ｓ５０１で、ＳＣＣＡＳ４００は、自身がサービングするＩＭＳユーザ（すなわち、ＩＭＳ加入者）への着信音声呼（ｔｅｒｍｉｎａｔｉｎｇｖｏｉｃｅｃａｌｌ）を受信する。

段階Ｓ５０２で、ＳＣＣＡＳ４００は、着信音声呼をＵＥに伝達するためのドメインを選択するために、ＨＳＳ３００にドメイン選択に必要な情報を要請するユーザデータ要請（ＵｓｅｒＤａｔａＲｅｑｕｅｓｔ）メッセージを送信する。ユーザデータ要請メッセージは、着信音声呼の受信者に関する識別情報（例えば、ＩＭＳ公開ユーザ識別子（ＰｕｂｌｉｃＵｓｅｒＩｄｅｎｔｉｔｙ）又はＭＳＩＳＤＮ）、及びＨＳＳに要請する情報が着信アクセスドメイン選択（ｔｅｒｍｉｎａｔｉｎｇａｃｃｅｓｓｄｏｍａｉｎｓｅｌｅｃｔｉｏｎ（Ｔ−ＡＤＳ））動作に必要な情報であることを知らせるパラメーターを含む。

段階Ｓ５０３で、ＨＳＳ３００は、着信音声呼の受信者に属したＵＥをサービングするノード（ＭＭＥ及び／又はＳＧＳＮ）からＰＳセッションでのＩＭＳボイスの同種支援情報を前に受信したか否かを検査する。参考として、ＭＭＥは、前述したように、ＵＥのアタッチ又はＴＡＵ動作中にＨＳＳに位置更新要請メッセージを送る時に、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めることもあり、含めないこともある。ＳＧＳＮも同様、前述したように、ＵＥのアタッチ又はＲＡＵ動作中にＨＳＳに位置更新要請メッセージを送る時に、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めることもあり、含めないこともある。

ＵＥのサービングノードとしてＭＭＥがＨＳＳに登録されており、ＳＧＳＮはＨＳＳに登録されていないとき、ＨＳＳ３００がＭＭＥからＰＳセッションでのＩＭＳボイスの同種支援情報を受信しなかった場合は、段階Ｓ５０４ａを行う。これとは違い、ＨＳＳ３００がＭＭＥからＰＳセッションでのＩＭＳボイスの同種支援情報を受信した場合は、段階Ｓ５０４ａを行わない。ＳＧＳＮはＨＳＳに登録されておらず、段階Ｓ５０４ｂは行わない。

ＵＥのサービングノードとしてＳＧＳＮがＨＳＳに登録されており、ＭＭＥはＨＳＳに登録されていないとき、ＨＳＳ３００がＳＧＳＮからＰＳセッションでのＩＭＳボイスの同種支援情報を受信しなかった場合は、段階Ｓ５０４ｂを行う。これとは違い、ＨＳＳ３００がＳＧＳＮからＰＳセッションでのＩＭＳボイスの同種支援情報を受信した場合は、段階Ｓ５０４ｂを行わない。ＭＭＥはＨＳＳに登録されておらず、段階Ｓ５０４ａは行わない。

ＵＥのサービングノードとしてＭＭＥとＳＧＳＮの両方がＨＳＳに登録されている場合、ＨＳＳ３００がＭＭＥとＳＧＳＮの両方からＰＳセッションでのＩＭＳボイスの同種支援情報を受信し、且つ両情報の値が一致すると（すなわち、両情報の値ともＳｕｐｐｏｒｔｅｄ（或いは、１又はＴｒｕｅ）であるか、又はＮｏｔ＿Ｓｕｐｐｏｒｔｅｄ（或いは、０又はＦａｌｓｅ）の場合）、段階Ｓ５０４ａ及び段階５０４ｂを行わない。その他の場合は段階Ｓ５０４ａ及び段階Ｓ５０４ｂを行う。

段階Ｓ５０４ａで、ＳＣＣＡＳ４００に応答するために必要な情報（すなわち、Ｔ−ＡＤＳ関連情報）を獲得するために、ＨＳＳ３００がＭＭＥ２００にサブスクライバデータ挿入要請（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＲｅｑｕｅｓｔ）メッセージを送信する。

段階Ｓ５０４ｂで、ＳＣＣＡＳ４００に応答するために必要な情報（すなわち、Ｔ−ＡＤＳ関連情報）を獲得するために、ＨＳＳ３００がＳＧＳＮ１００にサブスクライバデータ挿入要請メッセージを送信する。

段階Ｓ５０５ａで、ＭＭＥ２００はＨＳＳ３００にＴ−ＡＤＳ関連情報を含むサブスクライバデータ挿入応答（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＡｎｓｗｅｒ）メッセージを送信する。このＴ−ＡＤＳ関連情報は次のような情報を含むことができる。

ｉ）ＩＭＳ−Ｖｏｉｃｅ−Ｏｖｅｒ−ＰＳ−Ｓｅｓｓｉｏｎｓ−Ｓｕｐｐｏｒｔｅｄ：

ＮＯＴ＿ＳＵＰＰＯＲＴＥＤ（或いは、０又はＦａｌｓｅ）＝ＭＭＥ内のＵＥの最も最近に用いられた（ｍｏｓｔｒｅｃｅｎｔｌｙｕｓｅｄ）ＴＡがＰＳセッションでのＩＭＳボイスを支援しないことを示す。

ＳＵＰＰＯＲＴＥＤ（或いは、１又はＴｒｕｅ）＝ＭＭＥ内のＵＥの最も最近に用いられたＴＡがＰＳセッションでのＩＭＳボイスを支援することを指す。

ｉｉ）Ｌａｓｔ−ＵＥ−Ａｃｔｉｖｉｔｙ−Ｔｉｍｅ：ＵＥがＭＭＥに最も最近に無線接触（ｒａｄｉｏｃｏｎｔａｃｔ）をした時間

ｉｉｉ）ＲＡＴ−Ｔｙｐｅ：ＵＥをサービングするＲＡＴ（ｒａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ）の種類を示す。例えば、Ｅ−ＵＴＲＡＮ。

段階Ｓ５０５ｂで、ＳＧＳＮ１００はＨＳＳ３００にＴ−ＡＤＳ関連情報を含むサブスクライバデータ挿入応答メッセージを送信する。このＴ−ＡＤＳ関連情報は次のような情報を含むことができる。

ＮＯＴ＿ＳＵＰＰＯＲＴＥＤ（或いは、０又はＦａｌｓｅ）＝ＳＧＳＮ内のＵＥの最も最近に用いられたＲＡがＰＳセッションでのＩＭＳボイスを支援しないことを示す。

ＳＵＰＰＯＲＴＥＤ（或いは、１又はＴｒｕｅ）＝ＳＧＳＮ内のＵＥの最も最近に用いられたＲＡがＰＳセッションでのＩＭＳボイスを支援することを示す。

ｉｉ）Ｌａｓｔ−ＵＥ−Ａｃｔｉｖｉｔｙ−Ｔｉｍｅ：ＵＥがＳＧＳＮに最も最近に無線接触をした時間

ｉｉｉ）ＲＡＴ−Ｔｙｐｅ：ＵＥをサービングするＲＡＴの種類を示す。例えば、ＵＴＲＡＮ又はＧＥＲＡＮ。

段階Ｓ５０６で、ＨＳＳ３００はＳＣＣＡＳ４００にＴ−ＡＤＳ関連情報を含むユーザデータ応答（ＵｓｅｒＤａｔａＡｎｓｗｅｒ）メッセージを送信する。このＴ−ＡＤＳ関連情報は、ＵＥの位置しているＴＡ又はＲＡがＰＳセッションでのＩＭＳボイスを支援するか否かを表す。さらに、Ｔ−ＡＤＳ関連情報は、可用の場合、ＵＥをサービングするＲＡＴタイプを含むことができ、これはサービングノードから獲得した情報に基づく。ＨＳＳ３００は、下記のようにＴ−ＡＤＳ関連情報をユーザデータ応答（ＵｓｅｒＤａｔａＡｎｓｗｅｒ）メッセージに含める。

ＵＥのサービングノードとしてＭＭＥのみがＨＳＳに登録されており、ＳＧＳＮはＨＳＳに登録されていない場合：

ａ）上記段階Ｓ５０３の結果、ＨＳＳ３００がＭＭＥ２００からＰＳセッションでのＩＭＳボイスの同種支援情報を受信したと判断した場合：

ａ−１）ＰＳセッションでのＩＭＳボイスの同種支援値がＳｕｐｐｏｒｔｅｄ（或いは、１又はＴｒｕｅ）であれば、Ｔ−ＡＤＳ関連情報としてＰＳセッションでのＩＭＳボイス支援情報をＩＭＳ−ＶＯＩＣＥ−ＯＶＥＲ−ＰＳ−ＳＵＰＰＯＲＴＥＤ（或いは、１又はＴｒｕｅ）に設定する。

ａ−２）ＰＳセッションでのＩＭＳボイスの同種支援値がＮｏｔ＿Ｓｕｐｐｏｒｔｅｄ（或いは、０又はＦａｌｓｅ）であれば、Ｔ−ＡＤＳ関連情報としてＰＳセッションでのＩＭＳボイス支援情報をＩＭＳ−ＶＯＩＣＥ−ＯＶＥＲ−ＰＳ−ＮＯＴ−ＳＵＰＰＯＲＴＥＤ（或いは、０又はＦａｌｓｅ）に設定する。

ｂ）上記段階Ｓ５０３の結果、上記段階Ｓ５０４ａを行った場合：

上記段階Ｓ５０５ａで受信したサブスクライバデータ挿入応答（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＡｎｓｗｅｒ）メッセージに含まれたＴ−ＡＤＳ関連情報に基づいて、ユーザデータ応答（ＵｓｅｒＤａｔａＡｎｓｗｅｒ）メッセージに含めるＴ−ＡＤＳ関連情報を設定する。

ＵＥのサービングノードとしてＳＧＳＮのみがＨＳＳに登録されており、ＭＭＥはＨＳＳに登録されていない場合：

ａ）上記段階Ｓ５０３の結果、ＨＳＳ３００がＳＧＳＮ１００からＰＳセッションでのＩＭＳボイスの同種支援情報を受信したと判断した場合：

ｂ）上記段階Ｓ５０３の結果、上記段階Ｓ５０４ｂを行った場合：

上記段階Ｓ５０５ｂで受信したサブスクライバデータ挿入応答メッセージに含まれたＴ−ＡＤＳ関連情報に基づいてユーザデータ応答メッセージに含めるＴ−ＡＤＳ関連情報を設定する。

ＵＥのサービングノードとしてＭＭＥとＳＧＳＮの両方がＨＳＳに登録されている場合：

ａ）ＨＳＳ３００がＭＭＥとＳＧＳＮの両方からＰＳセッションでのＩＭＳボイスの同種支援情報を受信し、且つ両情報の値が互いに一致すると判断した場合：

ａ−１）ＭＭＥとＳＧＳＮから受信したＰＳセッションでのＩＭＳボイスの同種支援値が両方ともＳｕｐｐｏｒｔｅｄ（或いは、１又はＴｒｕｅ）であれば、Ｔ−ＡＤＳ関連情報としてＰＳセッションでのＩＭＳボイス支援情報をＩＭＳ−ＶＯＩＣＥ−ＯＶＥＲ−ＰＳ−ＳＵＰＰＯＲＴＥＤ（或いは、１又はＴｒｕｅ）に設定する。

ａ−２）ＭＭＥとＳＧＳＮから受信したＰＳセッションでのＩＭＳボイスの同種支援値が両方ともＮｏｔ＿Ｓｕｐｐｏｒｔｅｄ（或いは、０又はＦａｌｓｅ）であれば、Ｔ−ＡＤＳ関連情報としてＰＳセッションでのＩＭＳボイス支援情報をＩＭＳ−ＶＯＩＣＥ−ＯＶＥＲ−ＰＳ−ＮＯＴ−ＳＵＰＰＯＲＴＥＤ（或いは、０又はＦａｌｓｅ）に設定する。

ｂ）上記段階Ｓ５０３の結果、上記段階Ｓ５０４ａ及び段階Ｓ５０４ｂを行った場合：

最も最近にＵＥが活動（ａｃｔｉｖｅ）したサービングノードから獲得したＴ−ＡＤＳ関連情報に基づいて、ユーザデータ応答メッセージに含めるＴ−ＡＤＳ関連情報を設定する。

段階Ｓ５０７で、ＳＣＣＡＳ４００は、受信したユーザデータ応答メッセージに含まれたＴ−ＡＤＳ関連情報に基づいて、着信音声呼を伝達するドメインを選択する。すなわち、ＩＭＳドメイン（すなわち、ＰＳドメイン）を選択したり、ＣＳドメインを選択する。

段階Ｓ５０８で、段階Ｓ５０７で選択したドメインに着信音声呼を伝達する。

上述したドメイン選択に関する内容及びより詳細な説明は、３ＧＰＰＴＳ２３．２９２、ＴＳ２９．３２９、ＴＳ２９．３２８、ＴＳ２９．２７２で参照すればよい。

上述したように、従来技術ではサービングノードがＨＳＳに位置更新要請メッセージを送信時に、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めるか否か、そして含める場合はどの値に設定するかを決定するとき、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報を考慮しない。一般には、サービングノードがネットワーク設定（ｎｅｔｗｏｒｋｃｏｎｆｉｇｕｒａｔｉｏｎ及び／又はｎｅｔｗｏｒｋｐｒｏｖｉｓｉｏｎ）に基づいてＰＳセッションでのＩＭＳボイスの同種支援情報を含めるか否か、そして含める場合はとの値に設定するかを決定する。このような決定ではＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報は考慮されない。

これに対し、前述したように、サービングノードはＵＥにＩＭＳドメインにボイスサービスを提供するか否かを決定（すなわち、ＵＥに提供するＰＳセッションでのＩＭＳボイス支援表示値を決定）するときは、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報を考慮する。

したがって、ネットワーク設定上ではＩＭＳドメインにボイスサービスを提供するとしても、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報によって実際にはＵＥにＩＭＳドメインにボイスサービスを提供しないことと決定することもある。このような場合、サービングノードはＨＳＳに正しくないＰＳセッションでのＩＭＳボイスの同種支援情報を提供することがあり、結果としてはＨＳＳがＳＣＣＡＳに正しくないＴ−ＡＤＳ関連情報を提供することがある。すなわち、正しくないＴ−ＡＤＳ関連情報によってＳＣＣＡＳは誤選択したドメインに着信音声呼を伝達することがあり、よって、このドメインに伝達された音声呼は失敗する問題が発生する。

例えば、ＵＥのＴＡＵ実行によってＭＭＥが位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援値としてＳｕｐｐｏｒｔｅｄ（或いは、１又はＴｒｕｅ）を設定してＨＳＳに送り、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’能力情報を考慮した結果、ＵＥにＩＭＳドメインにボイスサービスを提供しないこと、すなわち、ＰＳドメインでのＩＭＳボイス支援表示をＮＯＴ＿ＳＵＰＰＯＲＴＥＤ（或いは、０又はＦａｌｓｅ）値に決定し、ＵＥ（すなわち、ＵＥの属したユーザ／加入者）への着信音声呼がＳＣＣＡＳに受信されることがある。このような場合、ＳＣＣＡＳはＨＳＳにＴ−ＡＤＳ関連情報を要請するユーザデータ要請メッセージを送信し、これを受信したＨＳＳは、ＭＭＥから受信したＰＳセッションでのＩＭＳボイスの同種支援情報に基づいてＳＣＣＡＳに、ＵＥの位置しているＴＡがＰＳセッションでのＩＭＳボイスを支援するという情報を含むユーザデータ応答（ＵｓｅｒＤａｔａＡｎｓｗｅｒ）メッセージで応答する。ＵＥは音声サービスのためにＩＭＳドメインではなくＣＳドメインを使用するにもかかわらず、ＨＳＳがＳＣＣＡＳに最新の正しい情報を与えないため、ＳＣＣＡＳはＵＥへの着信音声呼のための最初のドメインとしてＩＭＳドメインを選択し、ＩＭＳドメインへの音声呼伝達は失敗する。結果としては、ユーザ／加入者への音声呼伝達に完全に失敗することもあり、音声呼伝達ドメインを再選択できる場合であっても音声呼伝達に遅延が発生することがある。

要するに、従来のサービングノードがＨＳＳに提供するＰＳセッションでのＩＭＳボイスの同種支援情報は、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報を考慮していない、ＵＥにＩＭＳドメインにボイスサービスを提供するか否かを考慮していない、又はＵＥに提供するＰＳセッションでのＩＭＳボイス支援表示情報を考慮していない、ＰＳセッションでのＩＭＳボイスの同種支援情報であってもよい。

したがって、上述したような問題点、すなわち、ＰＳセッションでのＩＭＳボイスの同種支援情報がＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報を反映できない問題、これに関係してＩＭＳボイス又は着信音声呼（両方向音声メディア（ｂｉ−ｄｉｒｅｃｔｉｏｎａｌｓｐｅｅｃｈｍｅｄｉａ）を含む受信セッション（ｉｎｃｏｍｉｎｇｓｅｓｓｉｏｎ）であってよい）の正しいドメイン選択に失敗することになる問題などを解決するために、本発明ではサービングノードがＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報を考慮して、ＨＳＳに提供するＰＳセッションでのＩＭＳボイスの同種支援情報を決定することを提案する。

換言すれば、サービングノードは、ＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報を考慮して決定されるＰＳセッションでのＩＭＳボイス支援表示情報を追加的に考慮し、ＨＳＳに提供するＰＳセッションでのＩＭＳボイスの同種支援情報を決定することができる。さらにいうと、上述したように、ＰＳセッションでのＩＭＳボイス支援表示情報はボイス支援マッチ指示子、端末／ネットワークのＳＲＶＣＣ能力に基づくので、ＰＳセッションでのＩＭＳボイスの同種支援情報をボイス支援マッチ指示子、端末／ネットワークのＳＲＶＣＣ能力に基づいて決定することができる。

また、ＭＭＥは下記のような原則に基づいてＨＳＳに、上述したバーのような、ＰＳセッションでのＩＭＳボイスの同種支援情報を提供することもあり、提供しないこともある。（ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則）

ｉ）ＵＥのサービングＭＭＥ内の全てのＴＡがＵＥのために同一にＰＳセッションでのＩＭＳボイスを支援する場合、ＭＭＥはＰＳセッションでのＩＭＳボイスの同種支援値を‘Ｓｕｐｐｏｒｔｅｄ’（或いは、１又はＴｒｕｅ）に設定してＨＳＳに提供する。（これは、ＭＭＥ内の全てのＴＡでＵＥに‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＬＴＥを支援することを意味する。）

ｉｉ）ＵＥのサービングＭＭＥ内の全てのＴＡがＵＥのために同一にＰＳセッションでのＩＭＳボイスを支援しない場合、ＭＭＥはＰＳセッションでのＩＭＳボイスの同種支援値を‘Ｎｏｔ＿Ｓｕｐｐｏｒｔｅｄ’（或いは、０又はＦａｌｓｅ）に設定してＨＳＳに提供する。（これは、ＭＭＥ内の全てのＴＡでＵＥに‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＬＴＥを支援しないことを意味する。換言すれば、ＭＭＥ内の全てのＴＡでＵＥにＣＳフォールバック（ＣｉｒｃｕｉｔＳｗｉｔｃｈｅｄｆａｌｌｂａｃｋ）サービスを支援することを意味する。）

ｉｉｉ）ＵＥのサービングＭＭＥ内のＴＡのうちの一部のＴＡはＰＳセッションでのＩＭＳボイスを支援するが、残り一部のＴＡはＰＳセッションでのＩＭＳボイスを支援しない場合、ＭＭＥはＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援値を提供しない。

ｉｖ）ＵＥのサービングＭＭＥ内のＴＡが同一にＰＳセッションでのＩＭＳボイスを支援するか否か確認できない場合、ＭＭＥはＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援値を提供しない。

上述したＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則と同様に、ＳＧＳＮは下記のような原則に基づいてＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援情報を提供することもあり、提供しないこともある。（ＳＧＳＮのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則）

ｉ）ＵＥのサービングＳＧＳＮ内の全てのＲＡがＵＥのために同一にＰＳセッションでのＩＭＳボイスを支援する場合、ＳＧＳＮは、ＰＳセッションでのＩＭＳボイスの同種支援値を‘Ｓｕｐｐｏｒｔｅｄ’（或いは、１又はＴｒｕｅ）に設定してＨＳＳに提供する。（これは、ＳＧＳＮ内の全てのＲＡでＵＥに‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＨＳＰＡを支援することを意味する。）

ｉｉ）ＵＥのサービングＳＧＳＮ内の全てのＲＡがＵＥのために同一にＰＳセッションでのＩＭＳボイスを支援しない場合、ＳＧＳＮは、ＰＳセッションでのＩＭＳボイスの同種支援値を‘Ｎｏｔ＿Ｓｕｐｐｏｒｔｅｄ’（或いは、０又はＦａｌｓｅ）に設定してＨＳＳに提供する。（これは、ＳＧＳＮ内の全てのＲＡでＵＥに‘ＶｏｉｃｅｏｖｅｒＩＭＳ’、すなわち、ＶｏＨＳＰＡを支援しないことを意味する。換言すれば、ＵＥはＵＴＲＡＮで支援するＣＳボイスサービスを用いるべきということを意味する。）

ｉｉｉ）ＵＥのサービングＳＧＳＮ内のＲＡのうちの一部のＴＡはＰＳセッションでのＩＭＳボイスを支援するが、残り一部のＲＡはＰＳセッションでのＩＭＳボイスを支援しない場合、ＳＧＳＮはＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援値を提供しない。

ｉｖ）ＵＥのサービングＳＧＳＮ内のＲＡが同一にＰＳセッションでのＩＭＳボイスを支援するか否か確認できない場合、ＳＧＳＮはＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援値を提供しない。

上述した原則において、‘提供’は、サービングノードがＨＳＳに送るメッセージに、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めることを意味し、‘非提供’は、サービングノードがＨＳＳに送るメッセージに、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めないことを意味する。サービングノードがＨＳＳに送るメッセージは、従来のメッセージ（例、位置更新要請メッセージ）であってもよく、従来のメッセージに、本発明のために新しくＰＳセッションでのＩＭＳボイスの同種支援情報を含めるための情報要素（ｉｎｆｏｒｍａｔｉｏｎｅｌｅｍｅｎｔ）を追加した形態（例、報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージ、サブスクライバデータ挿入応答（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＡｎｓｗｅｒ）メッセージ）であってもよく、本発明のために新しく定義したメッセージであってもよい。

ｉｉｉ）の場合、サービングノードはＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援値を提供しない代わりに、ＰＳセッションでのＩＭＳボイスの同種支援値をＮｏｎ＿Ｈｏｍｏｇｅｎｅｏｕｓのように本発明のために新しく定義された値に設定してＨＳＳに提供することもできる。

ｉｖ）の場合、サービングノードはＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援値を提供しない代わりに、ＰＳセッションでのＩＭＳボイスの同種支援値を‘Ｕｎｋｎｏｗｎ’のように本発明のために新しく定義された値に設定してＨＳＳに提供することもできる。

本発明で提案する方案では、追加的に、ＭＭＥとＳＧＳＮがＵＥのＭＭコンテクストにＰＳセッションでのＩＭＳボイスの同種支援情報を保存することができる。また、追加的には、ＵＥのＭＭコンテクストに保存されたＰＳセッションでのＩＭＳボイスの同種支援値がＨＳＳに提供されたか又はアップデートされたかも保存することができる。

以下では、上述した本発明の内容が具体的に適用される実施例について説明する。

実施例１

図６は、本発明の実施例に係る初期アタッチ手順を説明するための図である。以下では、図６に示す各段階のうち、本発明の適用に関連する段階を中心に説明し、以下に説明されていない各段階についての説明は、図２で説明された内容に代えればよい。

初期アタッチ手順のうち段階Ｓ６０４で、ＭＭＥ３００はＨＳＳ７００に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ）メッセージを送信することができる。この時、ＭＭＥはＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価（ｅｖａｌｕａｔｅ）しなかった場合は、すなわち、ＰＳセッションでのＩＭＳボイス支援表示値を決定しなかった場合は、ＰＳセッションでのＩＭＳボイスの同種支援（ＨｏｍｏｇｅｎｅｏｕｓＳｕｐｐｏｒｔｏｆＩＭＳＶｏｉｃｅｏｖｅｒＰＳｓｅｓｓｉｏｎ）情報を上記の位置更新要請メッセージに含めない（すなわち、後述するように、ＰＳセッションでのＩＭＳボイスの同種支援情報の送信を遅延させることができる）。換言すれば、ＭＭＥは、この段階でＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価完了した場合に限って上記の位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援情報を含めるか否かを決定する。

大体の場合、段階Ｓ６０４が行われる時点にＭＭＥ３００がＰＳセッションでのＩＭＳボイス支援表示値を決定するために考慮する要素の一つであるＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報のうち、ｅＮｏｄｅＢから獲得するボイス支援マッチ指示子情報がない可能性が高いため、ＰＳセッションでのＩＭＳボイスの同種支援情報も決定することができない。そのため、上記の位置更新要請メッセージを送信時に、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めないこととなる。

選択的には、敢えて位置更新要請メッセージを送信する必要がない場合、又は位置更新要請メッセージが送信されない場合に、ＰＳセッションでのＩＭＳボイス支援表示値を決定することによってＰＳセッションでのＩＭＳボイスの同種支援情報をＨＳＳにアップデートする必要があるなら、ＭＭＥ３００は位置更新要請メッセージの代わりに報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージをＨＳＳ７００に送信することもできる。報知要請メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、ＰＳセッションでのＩＭＳボイスの同種支援情報を含んだり含まない。報知要請メッセージは追加的には、当該報知要請メッセージがＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートしようとする目的である旨を知らせる情報を含むこともできる。

上述した段階Ｓ６０４以降に、下記の条件を満たすと、ＭＭＥ３００はＨＳＳ７００に、ＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートするための報知要請メッセージを送信することができる。すなわち、報知要請メッセージは、下記の条件を満たす場合は段階Ｓ６０４以降にいつでも送信することができる。（図６では、便宜上、段階Ｓ６２１としている）

ｉ）ＭＭＥがＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価完了する、すなわち、ＰＳセッションでのＩＭＳボイス支援表示値を評価する（又は、決定する）。

ｉｉ）ＭＭＥがＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートしなければならないと判断する。

このようなアップデートに対する判断は、前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に基づけばよい。すなわち、アップデートに対する判断は、下記の一つ以上を含むことができる。

ｉ）以前にＭＭＥ３００がＨＳＳ７００にＵＥ１００に対するＰＳセッションでのＩＭＳボイスの同種支援情報を提供したことがないが、ＰＳセッションでのＩＭＳボイス支援表示値を決定した結果、ＰＳセッションでのＩＭＳボイスの同種支援情報を‘Ｓｕｐｐｏｒｔｅｄ’（或いは、１又はＴｒｕｅ）に設定して提供しなければならないと判断（又は、逆の場合であって、以前にはＰＳセッションでのＩＭＳボイスの同種支援情報を提供したか、今は提供してはならないと判断）

ｉｉ）以前にＭＭＥ３００がＨＳＳ７００に提供したＵＥ１００に対するＰＳセッションでのＩＭＳボイスの同種支援値と新しく決定されたＰＳセッションでのＩＭＳボイスの同種支援値とが異なると判断（例えば、以前にＭＭＥ３００がＨＳＳ７００にＵＥ１００に対するＰＳセッションでのＩＭＳボイスの同種支援情報を‘Ｓｕｐｐｏｒｔｅｄ’（或いは、１又はＴｒｕｅ）に設定して提供したが、ＰＳセッションでのＩＭＳボイス支援表示値を決定した結果、ＰＳセッションでのＩＭＳボイスの同種支援情報を‘Ｎｏｔ＿Ｓｕｐｐｏｒｔｅｄ’（或いは、０又はＦａｌｓｅ）に設定して提供しなければならない場合など）

報知要請メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、ＰＳセッションでのＩＭＳボイスの同種支援情報を含んだり含まない。すなわち、上記の報知要請メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて、ＰＳセッションでのＩＭＳボイスの同種支援情報のアップデート事項又はアップデートされたＰＳセッションでのＩＭＳボイスの同種支援情報を含む。報知要請メッセージは追加的には、当該報知要請メッセージがＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートしようとする目的である旨を知らせる情報を明示的／黙示的に含むこともできる。

報知要請メッセージを送信時に、ＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報をさらに含めることもできる。又は、報知要請メッセージ送信とは別に、段階Ｓ６０４以降に、ＭＭＥがＵＥに対するＰＳセッションでのＩＭＳボイス支援表示値を決定した場合は、ＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報を含むメッセージ（既存のメッセージ又は新しいメッセージ）をＭＭＥがＨＳＳに送信することもできる。

ＨＳＳ７００は、ＭＭＥ３００から受信したＰＳセッションでのＩＭＳボイスの同種支援情報及び／又はＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報に基づいて、ＵＥ１００に関連したユーザ（又は加入者）のデータベースをアップデートする。

段階Ｓ６２２で、ＨＳＳ７００は報知応答（ＮｏｔｉｆｙＡｎｓｗｅｒ）メッセージでＭＭＥ３００に応答する。

上記段階Ｓ６２１及び段階Ｓ６２２では、報知要請メッセージ及び報知応答メッセージが用いられたが、これとは違い、既存の他のメッセージが用いられてもよく、本発明のために新しく定義されたメッセージが用いられてもよい。

上述した実施例１で提案した方案は、ＵＥがＳＧＳＮにアタッチ動作を行う場合にも類似の形態で適用することができる。

実施例２

図７は、本発明の実施例に係るＴＡＵ手順を説明するための図である。以下では、図７に示す各段階のうち、本発明の適用に関連した段階を中心に説明し、以下に説明されていない各段階についての説明は、図３で説明された内容に代えればよい。

段階Ｓ７１２で、ＮｅｗＭＭＥ３００は、ＨＳＳ７００に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ）メッセージを送信することができる。この段階は、ＮｅｗＭＭＥ３００がＵＥ１００に関する加入者情報（ｓｕｂｓｃｒｉｐｔｉｏｎｄａｔａ）がない場合などに行われる。

この時、ＮｅｗＭＭＥは、ＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価しなかった場合、すなわち、ＰＳセッションでのＩＭＳボイス支援表示値を決定しなかった場合は、ＰＳセッションでのＩＭＳボイスの同種支援情報を位置更新要請メッセージに含めない。換言すれば、ＮｅｗＭＭＥは、この段階でＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価完了した場合に限って位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援情報を含めるか否かを決定する。

通常、この段階でＮｅｗＭＭＥ３００は、ＰＳセッションでのＩＭＳボイス支援表示値を決定するために考慮する要素の一つであるＵＥの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’関連能力情報のうちのボイス支援マッチ指示子情報を、段階Ｓ７０４でＯｌｄＭＭＥ３１０から獲得できる場合が殆どであるため、ＰＳセッションでのＩＭＳボイスの同種支援情報を決定することができる。そのため、前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援情報を含めたり含めないこととなる。

選択的には、敢えて位置更新要請メッセージを送信する必要がない場合、又は位置更新要請メッセージが送信されない場合に、ＰＳセッションでのＩＭＳボイス支援表示値を決定することによってＰＳセッションでのＩＭＳボイスの同種支援情報をＨＳＳにアップデートする必要があるなら、ＮｅｗＭＭＥ３００は位置更新要請メッセージの代わりに報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージをＨＳＳ７００に送信することもできる。報知要請メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、ＰＳセッションでのＩＭＳボイスの同種支援情報を含んだり含まない。報知要請メッセージは追加的には、この報知要請メッセージがＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートしようとする目的である旨を知らせる情報を含むこともできる。

段階Ｓ７１６で、ＮｅｗＭＭＥ３００が上記段階Ｓ７０４でＯｌｄＭＭＥ３１０からボイス支援マッチ指示子情報を受信できなかった場合は、ＮｅｗＭＭＥ３００はｅＮｏｄｅＢ２００にＵＥ無線能力マッチ要請（ＲａｄｉｏＣａｐａｂｉｌｉｔｙＭａｔｃｈＲｅｑｕｅｓｔ）メッセージを送信する。このようなＵＥ無線能力マッチ要請動作は、図４で前述した内容に従う。ＮｅｗＭＭＥ３００はＵＥ１００にＴＡＵ受諾メッセージを送信する。ＴＡＵ受諾メッセージはＰＳセッションでのＩＭＳボイス支援表示情報を含む。ＮｅｗＭＭＥ３００がＰＳセッションでのＩＭＳボイス支援表示値を決定時に考慮する要素は、図２の段階Ｓ２１１で説明した通りである。

段階Ｓ７１２以降に、下記の条件を満たすと、ＮｅｗＭＭＥ３００はＨＳＳ７００に、ＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートするための報知要請（ＮｏｔｉｆｙＲｅｑｕｅｓｔ）メッセージを送る。すなわち、報知要請メッセージは、下記の条件を満たす場合は段階Ｓ７１２以降にいつでも送信されてもよい（図７では便宜上、段階Ｓ７１７としている）。

ｉ）以前にＭＭＥ３００がＨＳＳ７００にＵＥ１００に対するＰＳセッションでのＩＭＳボイスの同種支援情報を提供したことがないが、ＰＳセッションでのＩＭＳボイス支援表示値を決定した結果、ＰＳセッションでのＩＭＳボイスの同種支援情報を‘Ｓｕｐｐｏｒｔｅｄ’（或いは、１又はＴｒｕｅ）に設定して提供しなければならないと判断（又は、その逆の場合であって、以前にはＰＳセッションでのＩＭＳボイスの同種支援情報を提供したが、今は提供してはならないと判断）

報知要請メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、ＰＳセッションでのＩＭＳボイスの同種支援情報を含んだり含まない。すなわち、報知要請メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて、ＰＳセッションでのＩＭＳボイスの同種支援情報のアップデート事項又はアップデートされたＰＳセッションでのＩＭＳボイスの同種支援情報を含む。追加的には、この報知要請メッセージがＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートしようとする目的である旨を知らせる情報を明示的／黙示的に含むこともできる。

報知要請メッセージを送信時に、ＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報をさらに含めることもできる。又は、報知要請メッセージ送信とは別に、段階Ｓ７１２以降に、ＭＭＥがＵＥに対するＰＳセッションでのＩＭＳボイス支援表示値を決定した場合は、ＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報を含むメッセージ（既存のメッセージ又は新しいメッセージ）をＭＭＥがＨＳＳに送信することもできる。

ＨＳＳ７００は、ＮｅｗＭＭＥ３００から受信したＰＳセッションでのＩＭＳボイスの同種支援情報及び／又はＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報に基づいて、ＵＥ１００に関連したユーザ（又は、加入者）のデータベースをアップデートする。

段階Ｓ７１７及び段階Ｓ７１８では報知要請メッセージ及び報知応答メッセージが用いられたが、これとは違い、既存の他のメッセージが用いられてもよく、本発明のために新しく定義されたメッセージが用いられてもよい。

図７では、Ｓ−ＧＷが変更されないＴＡＵ動作を示したが、上述の実施例２はＳ−ＧＷが変更されるＴＡＵ動作にも同一に適用することができる。また、実施例２で提案した方案は、ＵＥがＳＧＳＮにＲＡＵ動作を行う場合にも類似の形態で適用することができる。

実施例３

実施例１に追加的に、ＵＥのアタッチ動作中にサービングノードがＵＥ無線能力マッチ要請動作を、ＨＳＳに位置更新要請メッセージを送信する前に行うように設定することができる。図６を再び参照すると、段階Ｓ６０６でＭＭＥ３００はｅＮｏｄｅＢ２００からＵＥ１００に対するボイス支援マッチ指示子情報を獲得するためのＵＥ無線能力マッチ要請動作を行うことができる。実施例３では、これと違い、図４で説明されたＵＥ無線能力マッチ要請動作を、図６の段階Ｓ６０４以前に行うように設定することができる。

これと同様に、実施例２に追加的に、ＵＥのＴＡＵ／ＲＡＵ動作中にサービングノードがＵＥ無線能力マッチ要請動作を、ＨＳＳに位置更新要請メッセージを送信する前に行うように設定することができる。

このように位置更新要請メッセージを送信する前にＵＥ無線能力マッチ要請動作を行うと、結果としてＨＳＳに位置更新要請メッセージを送信することにつながることもある（図６では段階Ｓ６０４、図７では段階Ｓ７１２）。ここで、位置更新要請メッセージを用いる代わりに、従来の他のメッセージや本発明のために新しく定義されたメッセージを用いてＨＳＳにＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートすることもできる。

実施例４

実施例１では、ＵＥのＡｔｔａｃｈ動作中にサービングノードがＨＳＳに位置更新要請メッセージを送信時に、ＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価しなかった場合、すなわち、ＰＳセッションでのＩＭＳボイス支援表示値を決定しなかった場合は、ＰＳセッションでのＩＭＳボイスの同種支援情報を位置更新要請メッセージに含めなかった。しかし、これとは違い、実施例４では、サービングノードはネットワーク設定に基づくＰＳセッションでのＩＭＳボイスの同種支援情報を位置更新要請メッセージに含めることもできる。図６を参照すると、段階Ｓ６０４で、ＭＭＥが未だＰＳセッションでのＩＭＳボイス支援表示値を決定できなかったとしても、ネットワーク設定に基づくＰＳセッションでのＩＭＳボイスの同種支援値が‘Ｓｕｐｐｏｒｔｅｄ’又は‘Ｎｏｔ＿Ｓｕｐｐｏｒｔｅｄ’の場合に、ＨＳＳに送信する位置更新要請メッセージに、ネットワーク設定に基づく値に設定したＰＳセッションでのＩＭＳボイスの同種支援情報を含めることができる。

これと同様に、実施例２でも、サービングノードがネットワーク設定に基づくＰＳセッションでのＩＭＳボイスの同種支援情報を位置更新要請メッセージに含めることもできる。図７を参照すると、段階Ｓ７１２でＭＭＥが未だＰＳセッションでのＩＭＳボイス支援表示値を決定できなかったとしても、ネットワーク設定に基づくＰＳセッションでのＩＭＳボイスの同種支援値が‘Ｓｕｐｐｏｒｔｅｄ’又は‘Ｎｏｔ＿Ｓｕｐｐｏｒｔｅｄ’の場合に、ＨＳＳに送信する位置更新要請メッセージに、ネットワーク設定に基づく値に設定したＰＳセッションでのＩＭＳボイスの同種支援情報を含めることができる。

上記のように位置更新要請メッセージにＰＳセッションでのＩＭＳボイスの同種支援情報を含める場合に、追加的に、ＰＳセッションでのＩＭＳボイスの同種支援値が将来変更されることもある旨を知らせる情報を共に送信することができる。追加的な情報によって、ＨＳＳは、ＰＳセッションでのＩＭＳボイスの同種支援情報を有していても、ＳＣＣＡＳからＴ−ＡＤＳ関連情報を要請するメッセージ（すなわち、ユーザデータ要請メッセージ）を受信した場合に選択的にサービングノードへのＴ−ＡＤＳ関連情報を要請する段階（すなわち、サブスクライバデータ挿入要請（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＲｅｑｕｅｓｔ）メッセージ送信）を飛ばさずに行うことができる。

実施例５

サービングノードがＨＳＳからＴ−ＡＤＳ関連情報を要請するメッセージ（すなわち、サブスクライバデータ挿入要請（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＲｅｑｕｅｓｔ）メッセージ）を受信した後、それに対する応答を送る時に、ＵＥに対するＰＳセッションでのＩＭＳボイス支援の有無を評価完了、すなわち、ＰＳセッションでのＩＭＳボイス支援表示値を決定した場合は、応答メッセージ（すなわち、サブスクライバデータ挿入応答（ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＡｎｓｗｅｒメッセージ））に、ＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートする内容を含める。応答メッセージにＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートする内容を含めるか否かを決定するために、情報をＨＳＳにアップデートする必要があるか否かもさらに考慮することができる。

これについて図８を参照して説明する。以下、図８の説明において具体的に説明されない段階は、図５の説明に代ればよい。

図８を参照すると、段階Ｓ８０５ａで、ＭＭＥ２００がＰＳセッションでのＩＭＳボイス支援表示情報を決定した以降であれば、ＨＳＳ３００にサブスクライバデータ挿入応答メッセージを送信時に、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて前述の‘ＭＭＥのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めたり含めない。すなわち、サブスクライバデータ挿入応答メッセージは、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて、ＰＳセッションでのＩＭＳボイスの同種支援情報のアップデート事項又はアップデートされたＰＳセッションでのＩＭＳボイスの同種支援情報を含む。また、段階Ｓ８０５ｂで、ＳＧＳＮ１００がＰＳセッションでのＩＭＳボイス支援表示情報を決定した以降であれば、ＨＳＳ３００にサブスクライバデータ挿入応答メッセージを送信時に、決定されたＰＳセッションでのＩＭＳボイス支援表示値に基づいて前述の‘ＳＧＳＮのＰＳセッションでのＩＭＳボイスの同種支援情報提供／非提供の原則’に従って、ＰＳセッションでのＩＭＳボイスの同種支援情報を含めたり含めない。

サブスクライバデータ挿入応答メッセージは、ＰＳセッションでのＩＭＳボイスの同種支援情報をアップデートする旨を知らせる情報を明示的／黙示的にさらに含むこともできる。

サブスクライバデータ挿入応答メッセージを送信時に、ＰＳセッションでのＩＭＳボイスの同種支援情報のアップデートに加えて、ＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報をさらに含めることもできる。又は、ＰＳセッションでのＩＭＳボイスの同種支援情報のアップデートの代わりに、ＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報のみを含めることもできる。

ＨＳＳは、サービングノードから受信したＰＳセッションでのＩＭＳボイスの同種支援情報及び／又はＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報に基づいて、関連したユーザ（又は加入者）のデータベースをアップデートする。

実施例５で、上述した内容と共に、又は上述した内容とは独立して、以下のようにＳＣＣＡＳが動作することができる。

まず、ＳＣＣＡＳは下記の列挙された情報の一つ以上を用いて、着信音声呼の受信者がＩＭＳベースのボイスサービス（すなわち、ＩＭＳｖｏｉｃｅｏｖｅｒＰＳｓｅｓｓｉｏｎ又はＰＳドメインでの音声サービス）を受けるか否かを決定する。このような判断のための情報としては、ｉ）ＵＥがボイスを含まないサービスに対してのみＩＭＳ網に登録を行ったか否か、ｉｉ）加入者情報に加入者又は加入者の特定ＵＥがＩＭＳベースのボイスサービスを受けないという事項を含む、ｉｉｉ）ＵＥの能力情報、ｉｖ）ＵＥをサービングするＰＬＭＮの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’支援の有無に関する情報、ｖ）明示的な又は含蓄的な方法でＵＥ又は他のノードから獲得した情報及び／又はＳＣＣＡＳに設定されている情報、などが挙げられる。ｉ）と関連して、ＳＣＣＡＳが、ＵＥがボイスを含まないサービスに対してのみＩＭＳ網に登録を行ったか否かを考慮するために、ＵＥがＩＭＳ網に登録時に、ボイス（又は、ＭＭＴｅｌ）サービスをＩＭＳベースで受けるか否かに関する情報を（明示的に又は含蓄的に）含めることができる。これは追加的に次の動作を伴うことがある。すなわち、ＵＥがボイスサービスをＩＭＳベースで受けたがっていたが、以降そうでなくなった場合、又は逆に、ボイスサービスをＩＭＳベースで受けたくなかったが、以降ＩＭＳベースで受けたくなった場合に、ＵＥはその旨をネットワークに知らせるためにＩＭＳ登録又は報知要請を行う。

判断の結果、着信音声呼の受信者がＩＭＳベースのボイスサービスを受けない場合は、ＩＭＳ網のＳＣＣＡＳがＵＥへの着信音声呼を受信しても、ＵＥをサービングするネットワークの‘ＶｏｉｃｅｏｖｅｒＩＭＳ’支援に関する情報を獲得するためにＨＳＳにクエリーを送信しないことと決定することができる。

又は、ＳＣＣＡＳが、着信音声呼の受信者がＩＭＳベースのボイスサービスを受けないと判断すれば、ＩＭＳ網のＳＣＣＡＳがＵＥへの着信音声呼を受信しても、ボイスメディアのための着信ドメイン選択のためのＴ−ＡＤＳを行わないことと決定することができる。

上記のように、ＳＣＣＡＳが、着信音声呼の受信者がＩＭＳベースのボイスサービスを受けないと判断すれば、着信音声呼をＣＳドメインに伝達する動作を行うことができる。逆の場合、すなわち、ＳＣＣＡＳが、着信音声呼の受信者がＩＭＳベースのボイスサービスを受けると判断すれば、着信音声呼をＩＭＳドメインに伝達する動作を行うことができる。

上述した実施例５は、実施例１及び実施例２の内容と組み合わせた形態で用いることができる。又は、実施例５は、実施例４の内容と組み合わせた形態で用いることもできる。本発明で提案するＵＥのサービングノードがＨＳＳに、ＰＳセッションでのＩＭＳボイスの同種支援情報及び／又はＰＳセッションでのＩＭＳボイス支援表示情報及び／又はボイス支援マッチ指示子情報などのＴ−ＡＤＳ関連情報検索（ｒｅｔｒｉｅｖａｌ）動作に関する情報を提供する方法は、ＨＳＳが情報に基づいてサービングノードへのＴ−ＡＤＳ関連情報検索動作を飛ばしても（ｓｋｉｐ）Ｔ−ＡＤＳに関して正しい情報を確認できるようにする目的、又はＨＳＳが情報に基づいてサービングノードへのＴ−ＡＤＳ関連情報検索動作を飛ばさずに行うようにする目的のものである。したがって、本発明において、サービングノードがＨＳＳに提供する情報は、ＰＳセッションでのＩＭＳボイスの同種支援情報、ＰＳセッションでのＩＭＳボイス支援表示情報、ボイス支援マッチ指示子情報の他にも様々な形態で、様々なメッセージで、様々な時点に提供することもできる。

図９は、本発明の一例に係る送受信装置の好適な実施例の構成を示す図である。

図９を参照すると、本発明に係るサービングノード装置９１０は、送受信モジュール９１１、プロセッサ９１２、及びメモリー９１３を備えることができる。送受信モジュール９１１は外部装置ネットワークノード（図示せず）及び／又はサーバー装置（図示せず）及び／又はＵＥ（図示せず）に各種の信号、データ及び情報を送信し、外部装置ネットワークノード（図示せず）及び／又はサーバー装置（図示せず）及び／又はＵＥ（図示せず）から各種の信号、データ及び情報を受信するように構成することができる。プロセッサ９１２はサービングノード９１０の動作全般を制御し、サービングノード９１０が外部装置と送受信する情報などを演算処理する機能を果たすように構成することができる。メモリー９１３は、演算処理された情報などを所定時間記憶することができ、バッファー（図示せず）などの構成要素に取って代わってもよい。

本発明の一実施例に係るサービングノード９１０のプロセッサは、ＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ、ＵＬＲ）を送信するが、サービングノードが端末のためのＰＳセッションでのＩＭＳボイス支援表示値を評価できなかった場合、ＵＬＲは、ＰＳセッションでのＩＭＳボイスの同種支援情報を含まなくてもよい。また、プロセッサは前述の各実施例に必要な動作を処理することができる。

また、このようなサービングノード９１０の具体的な構成は、前述した本発明の諸実施例で説明した事項が独立して適用されたり、又は２つ以上が同時に適用されるように具現すればよく、重複する内容は明確性のために説明を省略する。

上述した本発明の実施例は様々な手段を用いて具現することができる。例えば、本発明の実施例は、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア又はそれらの結合などによって具現することができる。

ハードウェアによる具現の場合、本発明の実施例に係る方法は、一つ又はそれ以上のＡＳＩＣｓ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔｓ）、ＤＳＰｓ（ＤｉｇｉｔａｌＳｉｇｎａｌＰｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ＤｉｇｉｔａｌＳｉｇｎａｌＰｒｏｃｅｓｓｉｎｇＤｅｖｉｃｅｓ）、ＰＬＤｓ（ＰｒｏｇｒａｍｍａｂｌｅＬｏｇｉｃＤｅｖｉｃｅｓ）、ＦＰＧＡｓ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙｓ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。

ファームウェアやソフトウェアによる具現の場合、本発明の実施例に係る方法は、以上で説明された機能又は動作を実行するモジュール、手順又は関数などの形態で具現することができる。ソフトウェアコードは、メモリーユニットに保存され、プロセッサによって駆動されてよい。メモリーユニットは、プロセッサの内部又は外部に設けられ、既に公知の様々な手段によってプロセッサとデータを交換することができる。

以上開示された本発明の好ましい実施例についての詳細な説明は、当業者が本発明を具現して実施できるように提供された。以上では本発明の好適な実施例を参照して説明したが、当該技術の分野における熟練した当業者に理解されるように、本発明の領域から逸脱しない範囲内で本発明を様々に修正及び変更することもできる。例えば、当業者は、上記の実施例に記載された各構成を互いに組み合わせる方式で用いてもよい。したがって、本発明は、ここに開示されている実施形態に制限されるものではなく、ここに開示されている原理及び新規な特徴と一致する最も広い範囲を与えるためのものである。

本発明は、本発明の精神及び必須特徴から逸脱することなく、他の特定の形態に具体化することができる。そのため、上記の詳細な説明はいずれの面においても制約的に解釈してはならず、例示的なものとして考慮しなければならない。本発明の範囲は、添付した請求項の合理的解釈によって定めなければならず、本発明の等価的範囲内における変更はいずれも本発明の範囲に含まれる。本発明は、ここに開示されている実施形態に制限されるものではなく、ここに開示されている原理及び新規な特徴と一致する最も広い範囲を有するものである。また、特許請求の範囲で明示的な引用関係を有しない請求項を結合して実施例を構成してもよく、出願後の補正によって新しい請求項として含めてもよい。

上述したような本発明の実施の形態は様々な移動通信システムに適用可能である。

Claims

無線通信システムにおいてネットワークのユーザ機器（ＵＥ）の音声サービスを支援する方法であって、
前記方法は、サービングノードによってＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵＬＲ）メッセージを送信することを含み、
前記サービングノードが前記サービングノードに関連した全てのＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）又は全てのＲＡ（ＲｏｕｔｉｎｇＡｒｅａ）におけるＰＳセッションでのＩＭＳボイス支援の同種性を知る場合に、前記ＵＬＲメッセージは、「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を含み、前記ＰＳセッションでのＩＭＳボイス支援の同種性は、前記ＵＥのボイスオーバーＩＭＳ関連能力情報を含む情報を考慮して決定され、
前記サービングノードがＵＥのボイスオーバーＩＭＳ関連能力情報を含む情報の欠如に起因して前記ＰＳセッションでのＩＭＳボイス支援の同種性を知らない場合に、前記ＵＬＲメッセージは、「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を含まない、方法。
前記ボイスオーバーＩＭＳ能力情報は、ボイス支援マッチ指示子及びＳＲＶＣＣ（ＳｉｎｇｌｅＲａｄｉｏＶｏｉｃｅＣａｌｌＣｏｎｔｉｎｕｉｔｙ）能力情報のうちの少なくとも一つを含む、請求項１に記載の方法。
前記ＵＬＲメッセージが「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を含まない場合に、前記「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素は、前記サービングノードから前記ＨＳＳに送信される報知要請メッセージに含まれる、請求項１に記載の方法。
前記ＰＳセッションでのＩＭＳボイスが前記サービングノードのサービス地域において前記ＵＥに対して同一に支援される場合に、前記「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素の値は、支援状態（Ｓｕｐｐｏｒｔｅｄ）に設定される、請求項１に記載の方法。
前記ＰＳセッションでのＩＭＳボイスが前記サービングノードのサービス地域において前記ＵＥに対して同一に支援されない場合に、前記「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素の値は、支援されない状態（Ｎｏｔ＿Ｓｕｐｐｏｒｔｅｄ）に設定される、請求項１に記載の方法。
前記ＰＳセッションでのＩＭＳボイスが前記ＵＥに対して前記サービングノードのサービス地域のうちの一部の地域でのみ支援される場合に、前記サービングノードは、前記「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を前記ＨＳＳに提供しない、請求項１に記載の方法。
前記ＰＳセッションでのＩＭＳボイスを、前記ＵＥに対して前記サービングノードのサービス地域で支援することが不可能な場合に、前記サービングノードは、前記「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を前記ＨＳＳに提供しない、請求項１に記載の方法。
前記「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素は、前記サービングノードのＭＭ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ）コンテクストに保存される、請求項１に記載の方法。
ＵＬＲ送信ステップは、前記ＵＥのアタッチ手順、前記ＵＥのＴＡＵ（ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅ）又は前記ＵＥのＲＡＵ（ＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅ）手順のいずれか一つに含まれる、請求項１に記載の方法。
前記サービングノードは、ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）及びＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）のいずれか一つである、請求項１に記載の方法。
前記サービングノードがＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）である場合に、前記サービングノードのサービス地域は、前記ＭＭＥに関連した全てのＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）を含む、請求項４に記載の方法。
前記サービングノードがＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）である場合に、前記サービングノードのサービス地域は、前記ＳＧＳＮに関連した全てのＲＡ（ＲｏｕｔｉｎｇＡｒｅａ）を含む、請求項４に記載の方法。
前記ＰＳセッションでのＩＭＳボイスの同種支援情報は、前記ＵＥに対する着信音声呼のドメインを選択するために用いられる、請求項１に記載の方法。
無線通信システムにおいて用いられるサービングノード装置であって、前記サービングノード装置は、
送受信モジュールと、
プロセッサと
を備え、
前記プロセッサは、サービングノードによってＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）に位置更新要請（ＵＬＲ）メッセージを送信し、
前記サービングノードが前記サービングノードに関連した全てのＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）又は全てのＲＡ（ＲｏｕｔｉｎｇＡｒｅａ）におけるＰＳセッションでのＩＭＳボイス支援の同種性を知る場合に、前記ＵＬＲメッセージは、「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を含み、前記ＰＳセッションでのＩＭＳボイス支援の同種性は、ＵＥのボイスオーバーＩＭＳ関連能力情報を含む情報を考慮して決定され、
前記サービングノードがＵＥのボイスオーバーＩＭＳ関連能力情報を含む情報の欠如に起因して前記ＰＳセッションでのＩＭＳボイス支援の同種性を知らない場合に、前記ＵＬＲメッセージは、「ＰＳセッションでのＩＭＳボイスの同種支援」情報要素を含まない、サービングノード装置。