JP4571618B2 - 会話型ベアラの交渉 - Google Patents

Description

本発明は、例えば実時間の音声およびビデオ情報を運ぶのに用いられる会話型ベアラを通信網内に準備することの交渉に関するものである。

従来、ディジタル携帯電話網は音声通信などのユーザ・トラフィックを運ぶのに回線交換チャンネルを用いてきた。回線交換チャンネルは所定のＴＤＭＡチャンネル内でフレーム当たり１スロットを割り当てることにより形成される。音声呼では回線交換セッションで十分であることが分かっているが、「バースト的な」性質を持つ大量のデータを転送するための機構としては効率的でない。例えば、ウエブ・サーバからウエブ・ページをダウンロードするために回線交換セッションを準備すると、かなりの時間は接続がアイドル状態になり、データを送信するときはオーバーロードになる可能性がある。

移動体端末に高速でデータ転送を行うため、ディジタル携帯電話網にパケット交換データ・サービスが導入されつつある。例えば、現在一般パケット無線サービス（ＧＰＲＳ）が多くのＧＳＭ網に導入されつつある。回線交換セッションとは異なり、所定のユーザのためのＧＰＲＳセッション（ＰＤＰコンテキストと呼ばれる）は所定のＴＤＭＡチャンネルで必ずしもフレーム当たり１スロットを占有せず、スロットはユーザがデータを送信または受信するときだけ使われる。送信するトラッフィックがないときは、スロットはユーザに割り当てられない。大量のデータを送信するときは、ユーザはフレーム当たり１つ以上のスロットを割り当てられる。

将来ＧＰＲＳは、ＴＤＭＡではなくＣＤＭＡを用いる３Ｇ網などの第３世代網で用いられよう。しかし、少なくとも予見できる将来には、３Ｇ網は回線交換サービスを提供し続けるものと思われる。ただし、かかるセッションは必ずしも終端間ではない。移動体端末と網との間のリンクは回線交換で行われ、データの経路は大容量パケット交換網（実時間トラフィックを処理するのに十分な帯域幅を有する）を介して網内および網間に指定される。

将来、パケット交換（アクセス）ドメインは実時間情報ストリーム（例えば、音声電話やビデオ電話に関するもの）を運ぶことができると考えられる。しかし現在のところ、ＧＰＲＳの伝送信頼度はユーザが期待する質の電話サービスをユーザに提供できるほど十分でないので、回線交換サービスは引き続き提供されると思われる（ＧＰＲＳが利用できない旧型の移動体端末装置へのサービスを継続する必要からも回線交換サービスを提供する必要がありそうである）。

パケット交換「ドメイン」を介したマルチメディア・サービスの提供を促進するため、３Ｇ標準を担当する第３世代パートナーシップ・プロジェクト（３ＧＰＰ）は、いわゆるＩＰマルチメディア・コア網サブシステム（ＩＭＳ）を開発した。ＩＭＳはＧＰＲＳコア網と通信し、ＩＰベースのマルチメディア・サービスを提供するのに用いられる全ての要素を含む。移動体間の電話において、移動体が異なる網に属すると仮定するとき、ＩＭＳは各移動体のホーム網内で提供される。各ＩＭＳはそのホーム網のＧＰＲＳコア網に接続される。マルチメディア・サービス用の基本プロトコルはＩＥＴＦセッション・イニシエーション・プロトコル（ＳＩＰ）である。ＳＩＰでは、呼を開始する前に発呼者が被呼者の現在のＩＰアドレスを知らなくても、発呼者は被呼者へのパケット交換セッションを確立することができる（ユーザ端末内に設けられるいわゆるＳＩＰユーザ・エージェント（ＵＡ）を用いて）。ＳＩＰはセッション・パラメータ（例えば、サービスの質やコーデック）の交渉を含む他の機能を提供する。

図１は、回線交換（ＣＳ）アクセス網とパケット交換（ＰＳ）アクセス網とを移動体端末に提供する３Ｇ網の略図を示す。この図は、パケット交換網だけにアクセスすることができるＰＣに、移動体端末からその回線交換アクセス網を介して呼が行われることを示す。セッションは移動体端末が電話番号をダイアルすることにより開始される。すなわち、この場合はホーム網と移動体端末との間にＳＩＰ信号は全く交換されないので、ＳＩＰ ＵＲＬをＣＳドメインの上で転送することはできない。かかるセッションを確立するには、宛先端末に標準電話番号を割り当てなければならない。

回線交換データとパケット交換データとの間の変換は網間接続ゲートウエイ（ＧＷ）により行われ、ＧＷはＳＩＰ信号を用いてＰＣへのパケット交換セッションを確立する。ＰＣが用いるパケット交換網が十分な帯域幅を有する（例えば、網が広帯域網である）と仮定すると、呼は音声およびビデオ用の十分なレベルの質をユーザに提供する。このシナリオではホーム・オペレータの網のＩＭＳは用いられない。

宛先端末に電話番号を割り当てる必要があるだけでなく、図１の構造の別の欠点は、ＣＳアクセス網を用いて会話型ベアラが確立されたことを宛先端末が必ずしも知らないことである。宛先端末が追加の（非会話型）ＰＳベアラを確立しようとしてもできない。なぜなら、ゲートウエイはこのサービスを提供しないからである。また、開始端末が（非会話型）ＰＳベアラを確立しようとしてもできない。なぜなら、宛先端末は準備要求を既存の会話型ベアラと関連づけることができないからである。

図２は、移動体端末が利用可能なＰＳアクセス網を用いて移動体端末とＰＣとの間に呼を確立する別のシナリオを示す。呼はＩＭＳのＳＩＰサーバを用いて確立される。移動体端末が利用可能なＰＳアクセス網の帯域幅は限られているので、セッションは実時間の音声データやビデオ・データを処理するだけの十分な質のものでない可能性がある。このためには別個のＣＳベアラを確立しなければならない。しかし、開始端末または終端端末はピア端末のＳＩＰ ＵＲＬだけを知っていて電話番号を知らないので、これは簡単ではない。

共通の信号インターフェースを用いて回線交換呼とパケット交換呼とを開始し受信することをユーザは希望する可能性がある。しかし、現在の提案では、ユーザがパケット交換呼を開始し受信するにはＳＩＰを用いる（例えば、パケット交換呼を開始するにはユーザは被呼者のＳＩＰアドレス（例えば、ｊｏｈｎ＠ｅｘａｍｐｌｅ．ｏｒｇ）を入力する）が、ユーザが回線交換呼を開始し受信するにはＤＴＡＰプロトコルを用いる（例えば、かかる呼を開始するには、ユーザは被呼者の電話番号（例えば、０１２３４５．．．）をダイアルする）。網オペレータも共通信号インターフェースを用いることを希望するであろう。なぜなら、パケット交換ドメインが必要なサービスを提供できるように十分開発された場合は、これにより回線交換サービスからパケット交換ドメインへの移行が簡単になるからである。

本発明の第１の態様では、通信システムのピア・ユーザ端末の間に、少なくとも部分的に回線交換アクセス網全体に延びるセッションを準備する方法を提供する。この方法は、少なくとも１つのピア・ユーザ端末と前記通信システムとの間に前記セッションを開始するための信号を、ＩＰベースのパケット交換アクセス網を介して、エンド・ツー・エンド・パケット交換セッションを準備するのにも用いられる呼制御プロトコルを用いて転送し、次に前記信号に基づいて前記セッションを確立することを含む。

ここで、「通信システム」という用語は単一の通信網または網の集合（種々の国内網および国際網から成る世界的電気通信システムなど）を示すのに用いられる。
回線交換ドメイン内で前記セッションを開始する信号は間接的に開始する。すなわち、通信システムの或る適当なノードが、この信号は回線交換セッションを必要とすると解釈する。次に、回線交換ドメイン内の信号によりセッションは直接開始される。前記少なくとも１つのピア・ユーザ端末は回線交換セッションが必要であることを最初は知らなくてよい。

本発明の実施の形態の利点は、回線交換ドメインとパケット交換ドメインの両方に関係するセッション開始信号をパケット交換アクセス網の上だけで運ぶことができることである。
本発明は、開始したセッションが１つ以上の会話型ベアラを必要とする場合に特に適している。しかし、必ずしもそうでなくてもよい。前記セッションは会話型ベアラを必要としない１つ以上のメディア・ストリームにより強化され、パケット・アクセス網を通して確立してよい。例えば、セッションは１つ以上の会話型ベアラを必要とするが、更に、１つ以上の非会話型ベアラ（インスタント・メッセージング、ゲーミングなど）で補完される。かかるベアラはパケット・アクセス網／ドメインを通して確立される。

好ましくは、少なくとも１つのピア・ユーザ端末は、前記パケット交換アクセス網と回線交換アクセス網の両方を用いることができるデュアル・モード移動体端末である。

好ましくは、前記呼制御プロトコルはセッション・イニシエーション・プロトコル（ＳＩＰ）で、ＳＩＰ信号は前記少なくとも１つのピア・ユーザ端末とＩＰマルチメディア・コア網サブシステム（ＩＭＳ）のＳＩＰサーバとの間で交換される。より好ましくは、前記ＳＩＰサーバは、１つ以上の会話型ベアラを確立する必要があるセッション開始要求を受けるとゲートウエイ・サーバに通報し、ゲートウエイはシステム内の回線交換セッションを終わらせる。ゲートウエイは一方の回線交換セッションと他方のパケット交換セッションとの間の網間接続を提供する。ＳＩＰサーバとゲートウエイ・サーバとは物理的に同じ場所に配置される。

一般に、サーバからの通報の後、ゲートウエイは前記少なくとも１つのピア・ユーザ端末にＳＩＰサーバを介してコールバック電話番号を知らせ、ピア・ユーザ端末はその番号に電話してゲートウエイとの回線交換セッションを確立する。ゲートウエイは用いられたコールバック番号に基づいて、確立された回線交換セッションをＳＩＰ信号セッションにマップする。好ましくは、ゲートウエイは利用可能なコールバック番号のプールからコールバック番号を選ぶ。

好ましくはＳＩＰサーバは、前記セッションが次の１つ以上の結果、すなわち、
ＳＩＰサーバが知っているシステムの特性、
前記少なくとも１つのピア・ユーザ端末からの前の通報、
セッションを開始するＳＩＰ信号内に含まれる情報、
ピア・ユーザ端末のために定義された特性、
ローミング・ユーザ端末の場合は訪問先網からの前の通報、
ピア・ユーザ端末が用いる無線アクセス網からの前の通報、
から回線交換セッションを確立する必要があると判定する。

好ましくは、少なくとも１つのピア・ユーザ端末は確立された回線交換セッションをパケット交換ドメインの上で信号セッションにマップして、両セッションを共に終わらせることができるようにする。

本発明の１つの実施の形態では、前記ピア・ユーザ端末は移動体無線端末であり、前記少なくとも１つのピア・ユーザ端末は前記パケット交換アクセス網と回線交換アクセス網の両方を用いることができるデュアル・モード移動体端末である。他の移動体端末は、同様にデュアル・モード端末でもよいし、または回線交換アクセス網だけ（または実際にパケット交換網だけ）にアクセスすることができるシングル・モード端末でもよい。本発明の別の実施の形態では、前記少なくとも１つのピア・ユーザ端末は、例えばパケット交換アクセスと回線交換アクセスの両方を提供する前記通信システムに広帯域リンクする固定回線端末でよい。もちろん他の構成も可能である。例えば、前記少なくとも１つのピア・ユーザ端末はデュアル・モード無線端末であり、他のユーザ端末は固定回線端末である。

ＳＩＰはパケット交換網と回線交換網の上でセッションを準備するための呼制御プロトコルの一例であり、パケット交換網の上で転送される。Ｈ．３２３などの他の呼制御プロトコルを用いてもよい。

本発明の第２の態様では、回線交換アクセス網を用いる手段とＩＰベースのパケット交換アクセス網を用いる手段と、パケット交換網の上でエンド・ツー・エンド・パケット交換セッションを準備して回線交換網の上でセッションを開始するのにも用いられる呼制御プロトコルを用いて信号情報を転送する手段と、を備えるユーザ端末を提供する。

本発明の第３の態様では、ＩＰマルチメディア・コア網サブシステムで用いられるセッション・イニシエーション・プロトコル・サーバを提供する。このサーバは、
ＩＰベースのパケット交換ドメインの上でユーザ端末からＩＮＶＩＴＥ要求を受けてセッションを開始する手段と、
前記セッションが回線交換ドメイン内に１つ以上の会話型ベアラを準備する必要があると判定する手段と、
前記会話型ベアラを確立する手段と、
を備える。

本発明の第４の態様では、回線交換アクセス網とパケット交換アクセス網との間のインターフェースを提供するゲートウエイ・サーバを提供する。ゲートウエイ・サーバは、ＩＰマルチメディア・コア網サブシステムのセッション・イニシエーション・プロトコルとのインターフェースと、回線交換アクセス網の上でユーザ端末とセッションを確立することを命じる信号をＳＩＰサーバから受ける手段とを有する。

既存の提案されている電気通信網における代表的な呼セッション・シナリオについて図１と図２とを参照して上に説明した。
図３は、移動体端末（すなわち「ユーザ装置」（ＵＥ）１）のユーザが３Ｇ携帯電話網２（加入者のホーム網）の加入者である代表的なシナリオの略図を示す。ＵＥ１は、例えば３ＧＰＰリリース５（デュアルＣＳ−ＩＭＳ／ＰＳ）に指定された、デュアル・モード端末である。ＵＥを用いる加入者は特有の加入者識別（例えば、国際移動体加入者識別、ＩＭＳＩ）によりホーム網２内で識別され、またこの網は加入者の「ホーム」網と呼ばれる。ホーム網は一般パケット無線サービス（ＧＰＲＳ）コア網３と回線交換コア網４とを備える。両コア網３，４は共通ＵＭＴＳ無線アクセス網（ＵＴＲＡＮ）５を利用する。ＵＴＲＡＮに加えてまたはその代わりに、ＵＥはＧＥＲＡＮ（ＧＳＭ／ＥＤＧＥ無線アクセス網）を介してコア網と通信してよい。

ＧＰＲＳ網３内で、ＵＥ１に関する２つのノードを識別することができる。これらはサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）６とゲートウエイＧＰＲＳサポート・ノード（ＧＧＳＮ）７とである。ＳＧＳＮ６の役目は加入データ（識別とアドレス）を保持し、網内のＵＥ１の位置を追跡することである。ＧＧＳＮ７の役目は加入情報と割り当てられたＩＰアドレスとを保持し、ＵＥ１が所属するＳＧＳＮを追跡することである。ＧＧＳＮ７はＩＰバックボーン網８に結合する（ＳＧＳＮもＩＰ網８に結合する。ただし、このセッションは図に示していない。ＧＰＲＳ網（ＧＧＳＮとＳＧＳＮとを含む）のノードの間、およびＵＴＲＡＮとＧＰＲＳ網のゲートウエイ・ノードの間の通信はＩＰ網８を介して行われる）。一般に、ＵＥ１が起動するとＧＧＳＮに「所属して」、ＵＥ１とＧＧＳＮ７との間にＰＤＰコンテキストが確立される。このコンテキストはＵＥ１からＧＧＳＮ７にデータを転送するための「パイプ」を形成する。このプロセスはＩＰアドレスをＵＥ１に割り当てることを含む。一般に、アドレスの経路指定接頭部はＧＧＳＮ７に割り当てられた経路指定接頭部である。

また図３にはＩＰマルチメディア・コア網サブシステム（ＩＭＳ）９が示されている。これはパケット交換ドメイン内でＩＰベースのマルチメディア・サービスを提供するのに必要な全ての要素を含み、また移動体端末と通信する。ＩＭＳ９が提供する機能は３ＧＰＰ Ｖ５．６．０に述べられている。ＩＭＳ９は、自分たちの間で、またＩＰバックボーン網８を介してＩＭＳの外部のノードと通信する（これらのセッションは図に示していない）一組のノードから成る。ＩＭＳ９内に代理呼状態制御機能（Ｐ−ＣＳＣＦ）ノード１０とサービング呼状態制御機能（Ｓ−ＣＳＣＦ）ノード１１とを示す。ここでは、ＩＭＳはホーム網２のオペレータが所有していると仮定する（しかし、必ずしもそうでなくてもよい）。ローミング加入者の場合は、ＵＴＲＡＮとコア網とはもちろん「訪問先」網に属する。Ｐ−ＣＳＣＦも訪問先網に属するが、Ｓ−ＣＳＣＦとＨＳＳ（ホーム加入者サーバ）とはホーム網内にある。加入者はＩＭＳ内で、ＩＭＳ加入と特有の関係を有するＩＭＰＩ（ＩＰマルチメディア・プライベート識別）により識別される。

Ｓ−ＣＳＣＦ１１はＵＥのセッション制御サービスを行い、サービスをサポートするのにホーム網オペレータが必要とするセッション状態を保持する。セッション中にＳ−ＣＳＣＦ１１が行う主な機能は出入りする呼準備要求の経路を指定することである。Ｐ−ＣＳＣＦ１０が行う主な機能はＵＥ１とホーム網２のＩＭＳ９との間のＳＩＰメッセージの経路を指定することである。

ＵＥ１がＧＰＳＲに所属した後で、ＵＥは用いるべきＰ−ＣＳＣＦの識別（すなわち、ＩＰアドレス）を「見つけ」なければならない。これは以下の機構のどれかを用いて行う。
１． ＤＨＣＰを用いて、ＵＥに代理ＣＳＣＦのドメイン名と、代理ＣＳＣＦ名を決めることのできるドメイン名サーバ（ＤＮＳ）のアドレスとを与える。
２． ＰＤＰコンテキスト活動化信号内の代理ＣＳＣＦアドレスをＵＥに転送する（この第２の機構はＤＨＣＰをサポートしない端末に用いられる）。
次にＵＥ１はＳ−ＣＳＣＦ１１にＰ−ＣＳＣＦ１０を介してその現在の位置（すなわち、ＧＧＳＮにより割り当てられたＩＰアドレス）を通知する（このプロセスはＵＥ１からＳ−ＣＳＣＦへ、およびその逆への認証が必要で、特有の加入者識別を利用する）。Ｓ−ＣＳＣＦ１１はこの情報をホーム加入者サーバ１２が使えるようにし、これを用いてその後に入る呼の経路をＵＥ１に指定するのに用いられる。

図３には、以下にＢ加入者と呼ぶ加入者に属するＵＥ１３を示す。ＵＥ１３は自分のホーム網１４に所属する。この網１４はＵＥ１が用いるホーム網２の鏡映であって、添字「ｂ」を持つ同じ番号を用いて網１４の構成要素を識別する。以下の説明では、ＵＥ１（すなわち「Ａ加入者」）がパケット交換ドメインを用いてＵＥ１３（すなわち「Ｂ加入者」）にマルチメディア呼を確立したいと希望していると仮定する。ＵＥ１はまずＳＩＰ ＩＮＶＩＴＥメッセージをＰ−ＣＳＣＦノード１０に送る。ＩＮＶＩＴＥメッセージはＵＥ１３のＳＩＰアドレス（例えば、ｊｏｈｎ＠ｅｘａｍｐｌｅ．ｏｒｇ）と、必要なサービスの識別とを含む。Ｐ−ＣＳＣＦノード１０はＩＮＶＩＴＥメッセージをＳ−ＣＳＣＦノード１１に送る。

Ｓ−ＣＳＣＦ１１は、ＩＮＶＩＴＥメッセージ内で識別される要求されたサービスを用いる権利をＵＥ１（または、むしろＵＥ１を用いる加入者）が有することを確認する。次にＳ−ＣＳＣＦ１１はＵＥ１３のＩＰアドレスを識別しなければならない。これには、ＳＩＰアドレスをＩＰアドレスにマップするルックアップ・テーブルを用いる。所定のＳＩＰアドレスに対して、テーブルは対応する加入者の「ホーム」網のＩＰアドレスを与える。識別されたＩＰアドレスを用いて、ＩＮＶＩＴＥメッセージはＢ加入者のホームＩＭＳ網９ｂ内のＳ−ＣＳＣＦ１１ｂに送られる。ＩＮＶＩＴＥメッセージ内に含まれるＳＩＰアドレスを用いて、Ｓ−ＣＳＣＦ１１ｂはＵＥ１３の現在のＩＰアドレスを識別し、ＩＮＶＩＴＥメッセージをそのアドレスに送る。ＩＮＶＩＴＥメッセージを受けると、またＵＥ１３が呼に答えると仮定すると、ＯＫメッセージがＵＥ１に返される。一般に、このメッセージは２つのＳ−ＣＳＣＦ１１、１１ｂを介して送られる。ＯＫメッセージがＵＥ１に確かに届いたことを確認するために、このＵＥはメッセージを受けるとＡＣＫメッセージをピアＵＥ１３に返す。予め定められた或る時間内にＵＥ１３がＡＣＫメッセージを受けない場合は、ＯＫメッセージを再送信する。

移動体端末の間にＰＳセッションを確立するのに用いるのと同様に、ＳＩＰは移動体端末と固定端末との間、および固定端末だけの間にＰＳセッションを確立するのに用いてもよい。例えば、ＳＩＰは移動体加入者と、インターネットに広帯域セッションを有する固定端末との間にＰＳセッションを確立するのに用いてよい。

前に述べたように、ＵＥ１，１３とそれぞれのＵＴＲＡＮとの間のパケット交換リンクの質は、これらのリンクが２つのピアＵＥの間、またはＵＥの１つと固定端末との間の、呼に関連する音声データやビデオ・データなどの実時間の会話データを転送するのに十分でないことがある。したがって、ＵＥ１、１３またはそれぞれと、その回線交換コア網４，４ｂとの間に回線交換セッションを確立することが必要なことがある。次の機構はかかる回線交換セッションを確立するのに用いられる。

ＵＥは、そのホーム網のＩＭＳへのＰＳドメイン・セッションを有し、またＵＥはＩＭＳドメインに登録されていると仮定する。ＵＥのＳＩＰ ＵＡはすでにそのＩＭＳ ＳＩＰサーバ（これは一般にホーム網のＳ−ＣＳＣＦであるが、訪問先網のＰ−ＣＳＣＦでもよい）に、例えば登録中に、会話型ベアラをＰＳドメインの上で確立してはならないことと、ＳＩＰ ＵＡはかかるベアラのためにＣＳドメインを用いる（この要求はＵＥのデフォールト設定でよい）ことをすでに知らせている。しかし、ＰＳドメインとＳＩＰサーバとはＣＳドメインの上で会話型ベアラを準備するための信号を伝えるのに用いられる。理解されるように、会話型ベアラをＣＳドメインの上で準備すべきであるとＵＥがＳＩＰサーバに伝えるのではなく、この要求はすでにＳＩＰサーバが知っている（例えば、これは加入者のために定義された「特性」である）か、またはＵＥがそのアクセス網として用いる訪問先網がＳＩＰサーバにこの要求を知らせてよい。

この手続きを図４に示す。図４では、ＵＥ２０（３Ｇ網のＵＴＲＡＮを介してＰＳコア網２１とＣＳコア網２３に所属している）と固定端末２４（例えば、広帯域インターネット・セッションを有するＰＣ）との間に会話型ベアラが確立される。ゲートウエイ２５はＵＥ２０とホーム網との間のＣＳドメイン・セッションを終わらせるためのノードを提供する。ＵＥ２０のホーム・オペレータに関連する網（ＣＳ、ＰＳ、ＩＭＳ）の構造はこの図に詳細には示していないが、認識されるように、これは図３に示した形を取っている。ゲートウエイ２５はホーム網ＩＭＳ２７のＳＩＰサーバ２６（Ｓ−ＣＳＣＦ）と、例えばＩＰバックボーン網（図示しない）を介して通信する。ＳＩＰサーバ２６はゲートウエイ２５を、ＵＥ２０にサービスを提供するアプリケーション・サーバとして見る。ＳＩＰの観点からは、ゲートウエイは透明なバック・ツウ・バックＵＡとして動作する（また、ＳＩＰメッセージ内のセッション記述プロトコルを修正することができる）。または、ゲートウエイは不透明なバック・ツウ・バックＵＡとして動作してよい。ゲートウエイ２５はメディア経路内だけでなく信号経路内にも存在するので、ゲートウエイはＳＩＰ／ＳＳ７網間接続機能を与えることができる。（或る実施の形態では、ＳＩＰサーバとゲートウエイとは、加入者のホーム網内または訪問先網内で物理的に同じ場所に設置してよい）。

会話型ベアラの準備を要求するＳＩＰ ＩＮＶＩＴＥをＳＩＰサーバ２６がＵＥ２０から受けると、ゲートウエイ２５は知らせを受けて「コールバック」番号をセッションに割り当てる。ＵＥ２０はこの番号を通知され、これに電話をかけてゲートウエイ２５へのＣＳ接続を確立する。ＳＩＰはゲートウエイ２５と被呼者２４との間にセッションを確立するのに用いられる。開始端末としての移動体端末の観点から、図５の信号図を参照してこの手続きを以下に詳細に定義する。

１． 発信ＵＥは、会話型ベアラを必要とする１つ以上のメディア・ストリームを必要とするセッションの確立を要求するＳＩＰ ＩＮＶＩＴＥをホームＩＭＳに送る。ＩＮＶＩＴＥは被呼者のＳＩＰアドレス（例えば、ｓｉｐ：ｊｏｈｎ＠ｅｘａｍｐｌｅ．ｏｒｇ．）を含む。
２． ホームＩＭＳのＳＩＰサーバはセッション企画信号の経路をゲートウエイに指定する。

３． ゲートウエイはＩＰアドレスとポート番号とを出側（すなわち被呼者の方）のセッションに割り当てる（この例では、会話型ベアラは完全にＰＳドメインの上でゲートウエイと被呼者との間に運ばれる）。ゲートウエイは割り当てられたＩＰアドレスとポート番号とを追加することによりＩＮＶＩＴＥ内のＳＤＰを修正して、修正されたメッセージをＳＩＰサーバに送り返す。
４． ＳＩＰサーバはＩＮＶＩＴＥの経路を被呼者の方に指定する。

５． ゲートウエイは適当なコールバック電話番号（例えば、１２３）を選んで、これをＳＩＰサーバに送り返す（すなわちＳＩＰ ＲＥＦＥＲ法を用いて）。ただし、これは仮のメッセージ内にその番号を含めることにより行ってよい。一般に、ゲートウエイはコールバック番号のプールにアクセスすることができる。更に、ゲートウエイは発信ＵＥにＳＩＰインスタント・メッセージの形で情報メッセージを与えることができる。これは、例えば呼の状態と呼の価格についての情報を含んでよい。

６． ＳＩＰサーバはＳＩＰ ＲＥＦＥＲの経路を発信ＵＥに指定する。
７． 発信ＵＥはＣＳドメインを用いて、割り当てられたコールバック番号１２３への呼を開始する。
８． ＣＳドメイン（ＭＳＣ）は呼準備要求ＩＡＭの経路をゲートウエイに指定する。ゲートウエイは用いられたコールバック番号に基づいて、入る呼と前のＳＩＰ対話とを関連づけることができる。
９． ＳＩＰサーバは被呼者のホーム網から回答２００ＯＫを受ける。
１０． この応答はゲートウエイに送られる。

１１． 応答を受けると、ゲートウエイはＣＳドメイン（ＭＳＣ）向けの回答メッセージＡＮＭを作成する。またゲートウエイはＳＩＰコール・レッグとＣＳコール・レッグとを接続する。
１２． ＣＳドメインは回答ＣＯＮＮＥＣＴを発信ＵＥ１に送る。この時点で会話型ベアラが確立される。
１３．１４． ゲートウエイはＳＩＰサーバを介して応答２００ＯＫを発信ＵＥに送る。
１５−１８． ＵＥ１は肯定応答メッセージを生成して被呼者に送る。

上に説明したシーケンスは単なる例であって、必要に応じて修正してよい。更に、発信ＵＥと被呼者との間に先行セッションが確立されていないと仮定したが、会話型ベアラを確立する前にかかるセッションが存在してもこの手続きは適用可能である。

図６は、終端端末としての移動体端末の観点からＰＳドメインの上で会話型ベアラを準備することに関連する信号を示す。この手続きのステップは次の通りである。
１． 終端ＵＥのホームＩＭＳ内のＳＩＰサーバは会話型ベアラを必要とする１つ以上のメディア構成要素の確立を要求するＳＩＰ ＩＮＶＩＴＥを受ける。
２． ＳＩＰサーバは、要求された構成要素を確立するには終端ＵＥのためにＣＳドメインを用いなければならないと判定する。したがって、ＩＮＶＩＴＥの経路をＣＳドメインとパケット交換バックボーン網とを相互接続するゲートウエイに指定する。

３． ゲートウエイはＩＰアドレスとポート番号とを入り側（すなわち、被呼者の方）のセッションに割り当てる。ゲートウエイは割り当てられたＩＰアドレスとポート番号とを追加することによりＩＮＶＩＴＥ内のＳＤＰを修正して、ＩＮＶＩＴＥをＳＩＰサーバに送り返す。
４． ＳＩＰサーバはＩＮＶＩＴＥの経路を終端ＵＥに指定する。
５． ゲートウエイはコールバック電話番号（再び１２３）を決定し、ＳＩＰ ＲＥＦＥＲ法を用いてこれをＳＩＰサーバに送る。
６． ＳＩＰサーバはＳＩＰ ＲＥＦＥＲの経路を終端ＵＥに指定する。
７． 終端ＵＥはＣＳドメインの上で、修正されたコールバック電話番号１２３への呼を開始する。
８． ＣＳドメイン（ＭＳＣ）は呼準備要求ＩＡＭの経路をゲートウエイに指定する。ゲートウエイは用いたコールバック番号に基づいて呼とＳＩＰ対話とを関連づける。

９． ＳＩＰサーバは終端ＵＥから回答２００ＯＫを受ける。
１０． ＳＩＰサーバは回答の経路をゲートウエイに指定する。
１１． ＳＩＰサーバから回答を受けると、ゲートウエイはＣＳドメイン（ＭＳＣ）向けの回答ＡＮＭを作成する。ゲートウエイはＳＩＰコール・レッグとＣＳコール・レッグとを接続することもできる。
１２． ＣＳドメインは回答ＣＯＮＮＥＣＴを終端ＵＥに送る。
１３．１４． ＳＩＰ回答２００ＯＫの経路を発信網のＩＭＳの方に指定する。
１５−１８． 肯定応答ＡＣＫの経路を終端移動体端末の方に指定する。

図５と図６とは一般レベルでの信号を示す。特定の実施の形態は、恐らく図に示した信号「ステップ」の少なくともいくつかについて追加の信号を含む。図７は移動体が開始する呼に関連する信号を示す。この場合、３ＧＰＰ網内のＣＳアクセス網上で会話型ベアラを確立する必要がある。信号ステップは次の通りである。
１． 移動体端末は、会話型ベアラ（例えば、オーディオ、ビデオ）を必要とする１つ以上のメディア・ストリームを有するセッションを確立するためのＳＩＰ ＩＮＶＩＴＥ要求をユーザのＩＭＳ網に送る。更に、移動体端末は非会話型ベアラ（例えば、テキスト・チャット、ホワイトボーディング）を必要とするメディア・ストリームを確立することを要求してよい。

２． ＩＭＳ網内のＰ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）は、パケット交換アクセスが会話型ベアラを移動体ユーザに与えることができないことを知っている。したがって、セッション企画信号の経路をゲートウエイ（ＭＧＣＦとＭＧＷから成る）に指定する。
３． ゲートウエイはメディアのＩＰアドレスとポート番号とを出側に割り当てる。ゲートウエイはＩＰアドレスとポート番号とを追加することによりＩＮＶＩＴＥ内のＳＤＰを修正して、これをＰ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）に送り返す。
４． Ｐ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）はＩＮＶＩＴＥの経路を終端ユーザの方に指定する。
５． Ｐ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）は終端側から１８３応答を受ける。
６． Ｐ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）は１８３応答の経路をゲートウエイに指定する。

７． ゲートウエイは１８３応答の経路をＰ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）に指定する。
８． Ｐ−ＣＳＣＦ（または、Ｓ−ＣＳＣＦ）は１８３応答の経路を発信ユーザに指定する。（完全な呼フローはＵＥから仮の応答ＰＲＡＣＫメッセージとＰＲＡＣＫのための２００ＯＫとを送ることを含むことに注意。またＵＥは、この段階で会話型ベアラを必要としないメディア・ストリームのためのＰＤＰ−コンテキスト活動を行うことに注意）。
９． ゲートウエイは適当なコールバック電話番号（この例では１２３）を選んで端末に送り返す（例えば、ＳＩＰ ＲＥＦＥＲ法を用いて）。注意：ゲートウエイは多くの同時呼を処理するために電話番号のプールを有してよい。利用可能なコールバック番号を選んで移動体ユーザに割り当てるだけでよい。

１０． ＳＩＰサーバはＳＩＰ ＲＥＦＥＲ要求の経路をＵＥに指定する。
１１． ＵＥはＣＳドメインを用いて呼を開始する。宛先電話番号は１２３（上のステップ１０でＳＩＰ ＲＥＦＥＲメッセージで受けたもの）である。
１２． ＣＳドメインＭＳＣは呼の経路をゲートウエイに指定する。呼がこのコールバック電話番号で終わったので、ゲートウエイは入るＣＳ呼とＳＩＰ対話とを関連づけることができる。
１３． ゲートウエイはＣＳ呼に回答する。
１４． ＣＳドメインは回答をＵＥに送る。（ＵＥはＣＳ呼の呼状態情報を一切エンド・ユーザに示してはならないことに注意。なぜなら、ＣＳ呼はＳＩＰセッションのためのメディア・ベアラとしてだけ用いられるからである。）
１５．１６．１７．１８． ＩＭＳ網により経路が終端ユーザに指定されるＵＰＤＡＴＥメッセージを送ることにより、ＵＥは資源保存ができたことを他のエンドに知らせる。

１９．２０． ＵＥはＮＯＴＩＦＹメッセージを送ることにより、ＣＳ呼が確かに確立されたことをゲートウエイに通知する。
２１．２２． ゲートウエイはＮＯＴＩＦＹに対する応答をＵＥに送る。
２３．２４．２５．２６ ＵＰＤＡＴＥのための２００ＯＫの経路がＵＥに指定される。
２７．２８． （完全なシーケンスでは、発信網とＵＥとは終端ＵＥがエンド・ユーザに電話をかけていることを示す応答を受けることに注意。）Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）はＩＮＶＩＴＥの２００ＯＫの経路をゲートウエイに指定する。
２９． ゲートウエイはＳＩＰコール・レッグとＣＳコール・レッグとを接続して、ＩＮＶＩＴＥの２００ＯＫの経路をＰ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）に指定する。
３０． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）はＩＮＶＩＴＥの２００ＯＫの経路をＵＥに指定する。
３１．３２．３３．３４． ＵＥは肯定応答を送る。その経路は終端ユーザの方に指定される。

図８は３ＧＰＰ網内の移動体終端呼に関連する信号を示す。信号ステップは次の通りである。
１． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）は、会話型ベアラ（例えば、オーディオ、ビデオ）を必要とする１つ以上のメディア・ストリームを有するセッションを確立するためのＳＩＰ ＩＮＶＩＴＥ要求を受ける。更に、この要求は非会話型ベアラ（例えば、テキスト・チャット、ホワイトボーディング）を必要とするメディア・ストリームを確立するための命令を含んでよい。

２． ＩＭＳ網内のＰ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）は、パケット交換アクセスが会話型ベアラを移動体ユーザに与えることができないことを知っている。したがって、セッション企画信号の経路をゲートウエイ（ＭＧＣＦとＭＧＷから成る）に指定する。
３． ゲートウエイはＩＮＶＩＴＥをＰ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）に送り返す。
４． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）はＩＮＶＩＴＥの経路を終端ユーザの方に指定する。
５． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）は終端側から１８３応答を受ける。
６． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）は１８３応答の経路をゲートウエイに指定する。

７． ゲートウエイは出側のメディアにＩＰアドレスとポート番号とを割り当てる。ゲートウエイはＰ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）への１８３応答内のＳＤＰを修正する。
８． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）は１８３応答の経路を発信ユーザの方に指定する。（完全な呼フローは１８３の仮の応答（ＰＲＡＣＫメッセージとＰＲＡＣＫのための２００ＯＫ）を送ることを含むことに注意。）
９． ゲートウエイは適当なコールバック電話番号（この例では１２３）を選んで端末に送り返す（例えば、ＳＩＰ ＲＥＦＥＲ法を用いて）。注意：ゲートウエイは多くの同時呼を処理するために電話番号のプールを有してよい。利用可能なコールバック番号を選んで移動体ユーザに割り当てるだけでよい。

１０． ＳＩＰサーバはＳＩＰ ＲＥＦＥＲ要求の経路をＵＥに指定する。
１１． ＵＥはＣＳドメインを用いて呼を開始する。宛先電話番号は１２３（上のステップ１０でＳＩＰ ＲＥＦＥＲメッセージで受けたもの）である。
１２． ＣＳドメインＭＳＣは呼の経路をゲートウエイに指定する。呼がこのコールバック電話番号で終わったので、ゲートウエイは入るＣＳ呼とＳＩＰ対話とを関連づけることができる。
１３． ゲートウエイはＣＳ呼に回答する。
１４． ＣＳドメインは回答をＵＥに送る。（ＵＥはＣＳ呼の呼状態情報を一切エンド・ユーザに示してはならないことに注意。なぜなら、ＣＳ呼はＳＩＰセッションのメディア・ベアラとしてだけ用いられるからである。）
１５．１６． ＵＥはＮＯＴＩＦＹメッセージを送ることにより、ＣＳ呼が確かに確立されたことをゲートウエイに通知する。
１７．１８． ゲートウエイはＮＯＴＩＦＹに対する応答をＵＥに送る。

１９．２０．２１．２２． ＵＥは、発信ＵＥのための資源保存ができたことを知らせるＵＰＤＡＴＥメッセージを受ける。
２３．２４．２５．２６． ＵＥはＵＰＤＡＴＥメッセージのための２００ＯＫを発信ユーザに送る。（完全なシーケンスでは、ＵＥは電話が今鳴っていることを知らせる応答を発信ＵＥに送る。）
２７．２８． エンド・ユーザは呼に回答し、ＵＥはＩＮＶＩＴＥのための２００ＯＫ応答を送り、Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）はその経路をゲートウエイに指定する。
２９． ゲートウエイはＳＩＰコール・レッグとＣＳコール・レッグとを接続してＩＮＶＩＴＥのための２００ＯＫの経路をＰ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）に指定する。
３０． Ｐ−ＣＳＣＦ（またはＳ−ＣＳＣＦ）はＩＮＶＩＴＥのための２００ＯＫの経路を発信ＵＥの方に指定する。
３１．３２．３３．３４ 終端ＵＥは発信ＵＥから肯定応答を受ける。

当業者が認識するように、本発明の範囲から逸れることなく上に述べた実施の形態に種々の修正を行うことができる。例えば、別の方法では、ＳＩＰサーバ自身がコールバック番号を決めてＵＥに送る。ＵＥがその番号に電話をかけると、呼の経路はゲートウエイに指定され、これにより次にＳＩＰサーバへのＳＩＰ呼が確立される（ＳＩＰサーバの観点からこれは追加のＳＩＰセッションであることに注意）。ＳＩＰサーバはゲートウエイが割り当てたＩＰアドレスとポート番号とをそのＳＩＰ信号から集めて、ＩＮＶＩＴＥ内のＳＤＰを修正する。しかしこの方法の欠点は、ＣＳ呼を発信ＵＥから受ける前にＩＮＶＩＴＥを終端側に送ることができないことである。なぜなら、終端側は呼を受けるまでは割り当てられたＩＰアドレスとポート番号とを知らないからである。またＳＩＰサーバ内の論理が複雑である。

回線交換アクセス網とパケット交換アクセス網の上で電気通信システムの２つのピア・ノードの間に確立されるセッションを示す。 それぞれのパケット交換アクセス網の上で電気通信システムの２つのピア・ノードの間に確立されるセッションを示す。 ＳＩＰを用いてピア移動体端末の間にパケット交換セッションを確立するための構造の詳細を示す。 ＰＳドメインの上で送られる信号を用いてＣＳドメイン内に会話型ベアラを準備する手続きを示す。 移動体端末がベアラを開始する、図４の手続きに関連する信号を示す。 移動体端末がベアラを終わらせる、図４の手続きに関連する信号を示す。 ３ＧＰＰ網内で移動体が開始する呼に関連する信号の詳細を示す。 ３ＧＰＰ網内で移動体が終わらせる呼に関連する信号の詳細を示す。

Claims (13)

1. 通信システムのピア・ユーザ端末の間に、セッションを設定する方法であり、ここで前記ピア・ユーザ端末の少なくとも１つは、ＩＰベースのパケット交換網と回線交換アクセス網の両方にアクセス可能なデュアル・モード端末であり、かつ前記セッションは少なくとも部分的に前記回線交換アクセス網に亘って延びており、前記方法は、
   前記セッションを開始するための信号を、前記ＩＰベースのパケット交換アクセス網を介し、かつ、エンド・ツー・エンド・パケット交換セッションの設定にも用いられる呼制御プロトコルを用いて、転送し、ここで前記信号は、前記すくなくとも１つのピア・ユーザ端末と、IPマルチメディアコアーネットワークサブシステム（IMS）のセッション開始プロトコル（SIP）サーバと、の間の交換をするためのセッション開始プロトコル(SIP)信号であり、
   通信システム内の回線交換セッションを終端するゲートウエイ・サーバへ、前記セッション開始プロトコルサーバから、１以上の会話型ベアラの設立が必要であるという通知を、送り、
   前記セッション開始プロトコルサーバからの通知に続いて、コールバック電話番号を、前記ゲートウエイ・サーバから前記デュアル・モード端末に送り、
   前記デュアル・モード端末から前記コールバック電話番号にコールして、ゲートウエイ・サーバとの回線交換セッションを確立する、
   前記方法。
2. 前記セッションは１つ以上の会話型ベアラを必要とする、請求項１記載のセッションを設定する方法。
3. 前記セッションは前記ＩＰベースのパケット交換網の上で確立された非会話型ベアラを含む、請求項２記載のセッションを設定する方法。
4. 前記セッション開始プロトコルサーバと前記ゲートウエイ・サーバとは物理的に同じ場所に配置される、請求項１から３のいずれかの請求項に記載のセッションを設定する方法。
5. 前記ゲートウエイは一方の前記回線交換セッションと他方のパケット交換セッションとの間の網間接続を提供する、請求項１から４のいずれかの請求項に記載のセッションを設定する方法。
6. 前記コールバック番号の通報はセッション開始プロトコルサーバを介して転送される、請求項１から５のいずれかの請求項に記載のセッションを設定する方法。
7. 前記ゲートウエイは、前記用いられたコールバック番号に基づいて、前記確立された回線交換セッションを前記セッション開始プロトコル信号セッションにマップする、請求項１から６のいずれかの請求項に記載のセッションを設定する方法。
8. 前記ゲートウエイは利用可能なコールバック番号のプールから前記コールバック番号を選ぶ、請求項１から７のいずれかの請求項に記載のセッションを設定する方法。
9. 前記セッション開始プロトコルサーバは、前記セッションが次の１つ以上の結果、すなわち、
   前記セッション開始プロトコルサーバが知っているシステムの特性、
   前記少なくとも１つの前記ピア・ユーザ端末からの前の通報、
   前記セッションを開始する前記セッション開始プロトコル信号内に含まれる情報、
   前記デュアル・モード端末のために定義された特性、
   ローミング・ユーザ端末の場合は訪問先網からの前の通報、
   前記デュアル・モード端末が用いる無線アクセス網からの前の通報、
   から回線交換セッションを確立する必要があると判定する、請求項１から８のいずれかの請求項に記載のセッションを設定する方法。
10. 前記少なくとも１つのデュアル・モード端末は確立された回線交換セッションをパケット交換ドメインの上で信号セッションにマップして、両セッションを共に終端することができるようにする、請求項１から９のいずれかの請求項に記載のセッションを設定する方法。
11. デュアル・モードユーザ端末であって、
    回線交換アクセス網を用いる手段と、
    ＩＰベースのパケット交換アクセス網を用いる手段と、
    エンド・ツー・エンド・パケット交換セッション設定のためにも用いられるセッション開始プロトコル信号情報を、回線交換網上でのセッション開始のために、パケット交換網上で転送する手段と、
    ゲートウエイ・サーバから、前記パケット交換アクセス網を介して、コールバック電話番号を受信する手段と、
    前記コールバック電話番号をコールして、ゲートウエイ・サーバとの回線交換セッションを確立する手段と、
    を備える前記デュアル・モードユーザ端末。
12. ＩＰマルチメディア・コア網サブシステムで用いられるセッション開始プロトコルサーバであって、このサーバは、
    ＩＰベースのパケット交換アクセス網の上でデュアル・モード端末からＩＮＶＩＴＥ要求を受けてセッションを開始する手段と、
    前記デュアル・モード端末にサービスを提供する回線交換アクセス網上に１以上の会話型ベアラを確立することが、前記セッションにとって必要であると判定する手段と、
    通信システム内の回線交換セッションを終端するゲートウエイ・サーバへ、前記セッション開始プロトコルサーバから、１以上の会話型ベアラの設立が必要であるという通知を、送る手段と、
    前記ゲートウエイ・サーバからコールバック電話番号を受信して、そのコールバック電話番号を前記デュアル・モード端末に転送する手段と、
    を備える前記サーバ。
13. 回線交換アクセス網とパケット交換網との間のインターフェースを提供するゲートウエイ・サーバであって、このゲートウエイ・サーバは、
    ＩＰマルチメディア・コア網サブシステムのセッション開始プロトコルサーバへのインターフェースと、
    前記回線交換アクセス網の上でデュアル・モード端末とセッションを確立することを命じる信号を、セッション開始プロトコルサーバから受信する手段と、
    上記信号の受信に応答して、コールバック電話番号を、前記セッション開始プロトコルサーバを介して前記デュアル・モード端末へ送る手段と、
    前記デュアル・モード端末によって行われた、前記コールバック番号へのコールを終端する手段と、
    を有する前記ゲートウエイ・サーバ。

Images