(57)【要約】  SIPプロトコルを用いてユーザ端末と基幹ネットワークとの間でアクセスネットワークを介して呼接続を行なう呼接続処理方法であり、アクセスネットワーク内の所定の装置(代理装置)にユーザ端末に代わって所定のSIPシグナリングメッセージを基幹ネットワークへ送信するよう指示するステップ、該指示にしたがって、代理装置は呼接続時にユーザ端末と基幹ネットワーク間で送受信される所定のSIPシグナリングメッセージをユーザ端末へ送らず、あるいはユーザ端末に代わって基幹ネットワークへ送信する。
2008044265.tif 000002
【特許請求の範囲】
【請求項１】
SIPプロトコルを用いてユーザ端末と基幹ネットワークとの間でアクセスネットワークを介して呼接続を行なう呼接続処理方法において、
前記アクセスネットワーク内の装置(代理装置)に所定のSIPシグナリングメッセージの基幹ネットワークへの送信をユーザ端末に代わって行うよう該ユーザ端末より指示するステップ、
該指示にしたがって、呼接続時に前記所定のSIPシグナリングメッセージのあるSIPシグナリングメッセージはユーザ端末へ送らず、あるいは他のメッセージはユーザ端末に変わって基幹ネットワークへ送信するステップ、
前記所定のSIPシグナリングメッセージ以外のメッセージはユーザ端末と基幹ネットワークとの間で送受信するステップ、
を有することを特徴とする呼接続処理方法。
【請求項２】
請求項１記載の呼接続処理方法において、
前記第１ステップの指示は、ユーザ端末がSIPプロトコルのINVITEメッセージで、(１)信頼性応答を要求しないこと、(２)ベアラ設定のための前提条件を指定しないこと、を宣言することにより行ない、
前記第２ステップにおいて、前記代理装置は信頼性応答に関するSIPシグナリングメッセージの送受信、およびベアラ設定後の所定のSIPシグナリングメッセージの送受信を、ユーザ端末の代わりに行なう、
ことを特徴とする呼接続処理方法。
【請求項３】
請求項２記載の呼接続処理方法において、
ユーザ端末を前記アクセスネットワークに登録する際、該ユーザ端末の能力情報や加入者情報を前記代理装置に登録するステップ
を備え、
前記代理装置は該登録情報を用いてベアラ設定を行ない、該ベアラ設定後の所定のSIPシグナリングメッセージの送受信を、ユーザ端末の代わりに行なう、
ことを特徴とする呼接続処理方法。
【請求項４】
請求項１記載の呼接続処理方法において、
所定のSIPシグナリングメッセージの送受信をユーザ端末に代わって行うよう該ユーザ端末より指示がなかったとき、前記代理装置は、所定のSIPシグナリングメッセージの送受信をユーザ端末に代わって行なうことを該ユーザ端末に通知するステップ、
前記SIPシグナリングメッセージの送受信をユーザ端末に代わって行なうステップ、
を有することを特徴とする呼接続処理方法。
【請求項５】
請求項４記載の呼接続処理方法において、
前記所定のSIPシグナリングメッセージは、確認応答のSIPシグナリングメッセージである、
ことを特徴とする呼接続処理方法。
【請求項６】
請求項１または４記載の呼接続処理方法において、
呼接続時に発信側ユーザ端末がSIPプロトコルのINVITEメッセージを発信してから、該INVITEメッセージに対する200OKを着信側ユーザ端末が応答する直前までの呼接続処理シーケンスを、該着信側ユーザ端末のネットワークへの接続状態に関係なく、発信側において独自に進めるステップ、
発信側ユーザ端末が着信側ユーザ端末より前記200OKを受信後、前記基幹ネットワークを介して発信側ユーザ端末と着信側ユーザ端末間で通信を行うステップ、
を備えることを特徴とする呼接続処理方法。
【請求項７】
請求６記載の呼接続処理方法において、
前記着信側ユーザ端末が200OKを応答する直前までの着信側の呼接続処理シーケンスを、該着信側ユーザ端末と着信側の代理装置との間で独自に行なうステップ、
を有することを特徴とする呼接続処理方法。
【請求項８】
請求項１または４記載の呼接続処理方法において、
前記代理装置は基幹ネットワークより呼接続の進捗情況を示すSIPメッセージを受信したとき、該メッセージのユーザ端末へ送信を留保し、サービス内容やQosの選択が正常に終了したことを確認してから、該メッセージをユーザ端末へ送信するステップ、
を有することを特徴とする呼接続処理方法。
【請求項９】
SIPプロトコルを用いてユーザ端末との間で呼接続処理を行う基幹ネットワークにアクセスするアクセスネットワーク内に設けられ、呼接続時にユーザ端末を代理して基幹ネットワークとの間でSIPシグナリングメッセージの送受信を行なうメッセージ送受信代理装置において、
ユーザ端末の能力情報や加入者情報を取得して蓄積するユーザ情報蓄積部、
SIPシグナリングメッセージを受信して解析する処理、前記蓄積情報を用いたベアラ設定処理、移動端末と基地局間のSIPシグナリングメッセージの中継処理、移動端末に代わってSIPシグナリングメッセージ作成して送信する処理を行なう処理部、
ユーザ端末とメッセージの送受信を行なう送受信部、
基幹ネットワーク側とメッセージの送受信を行なう送受信部、
を備えたことを特徴とするメッセージ送受信代理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼接続処理方法およびメッセージ送受信代理装置に係わり、特に、SIPプロトコルを用いてユーザ端末と基幹ネットワークとの間でアクセスネットワークを介して呼接続を行なう呼接続処理方法およびメッセージ送受信代理装置に関する。
【背景技術】
【０００２】
今日の通信システムとしてその扱いやすさやコストの面からIP（Internet Protocol）プロトコルとその関連プロトコルを使用したシステムが構築されるようになってきた。このIPプロトコルを中心としたプロトコル群は、固定通信だけでなく移動通信システムにも適用されている。そして、そのプロトコル群の中で、呼制御に使用されるプロトコルとして標準となりつつあるのがSIP（Session Initiation Protocol)プロトコルである。次世代ネットワークシステムにおいては、このSIPプロトコルを使用したIMS（IP Multimedia Subsystem)を中心に、統合システムが構築されようとしており、すべての固定通信、移動通信ネットワークはこれにつながるように構築されようとしている。【０００３】
・LTE/SAEシステム
図１８はIMSに接続する次世代ネットワークシステムであるEvolved 3GPPシステムの構成例である(非特許文献1参照)。Evolved 3GPPシステムは、基地局であるeNB(evolved-UTRAN NodeB) 1a 〜1n、それを幾つか束ねて制御するアクセスゲートウェイaGW (evolved-UTRAN Access Gateway)2a〜2c、ネットワーク全体のアンカーであるIASA( Inter Access System Anchor)3などで構成され、aGW 2a〜2cとIASA 3とでIMＳに対するアクセスネットワークACNが形成される。
基地局であるeNB 1a〜1nは、従来の基地局NBと無線網制御装置RNC (Radio Network Controller)の機能とほぼ同等の機能を備えている。呼接続時、移動端末(Mobile Station)とeNB間はRRC(Radio Resource Control)によりが接続され、しかる後、Attachにより該移動端末とaGW間が接続されると共に移動端末の固有の端末IDがaGWに通知される。
aGW 2a〜2cは移動端末4a,4bとIMS 5間のメッセージの受け渡しを行ない、eNB 1a 〜1nとでLTE-RAN (Radio Access Network)を形成する。ルータ的な機能を備えたIASA3はIMS 5に接続すると共にHSS (Home Subscriber Server)6、PCRF(Policy & Charging Rule Function)7, PCEF (Policy & Charging Enhance Function)に接続している。HSSは加入者(Subscriber)のプロファイルを保存するサーバ、PCRF はベアラ条件を決定し、PCRF は決定されたベアラをaGWに設定するものである。HSS はRRC接続が完了するとIASA 3, aGW2a〜2cを介してユーザ端末の認証を行い、また、aGWは該ユーザの呼に関して自分が担当である旨をHSS6に登録する。
認証、登録などの処理完了後、移動端末より発呼があると、aGW 2a〜2c はeNB 1a 〜1n
を介して受信したユーザ端末からの呼制御用SIPメッセージをIASA 3を介してIMS 5のCSCF(Call Session Control Function)8に送出し、また、IMS 5のCSCF8からIASA 3を介して受信した呼制御用SIPメッセージをeNB 1a 〜1nを介して移動端末4a,4bに送出する。そして、aGW 2a〜2cは呼接続制御完了後、移動端末からのデータをeNB 1a 〜1nを介して受信してIMS 5のルータに送出し、また、IMS 5のルータから受信したデータをeNB 1a 〜1nを介してユーザ端末4a,4bに送出する。【０００４】
図１９はIMS端末である移動端末4aを購入した時に該移動端末をIMS5に登録する手順説明図である。登録のための要求があると移動端末とeNB間はRRC(Radio Resource Control)によりが接続され、しかる後、Attachにより移動端末とaGW間が接続されると共に、移動端末の固有の番号(端末ID)がaGWに通知される。そして、RRC接続が完了するとHSS 6はIASA 3,aGW2aを介して移動端末4aの認証を行い、aGWは移動端末4aの呼に関して自分が担当で
ある旨をHSS6に登録する(Register MME/Confirm Registration)。MMEはMobile Management Entityの略である。
以上の認証、登録、秘匿処理が終了すれば、移動端末4aはIMSサービスを受けるためにIMS5のCSCF8に登録を要請する（Register）。CSCF8は移動端末4aが未登録であるため、401
Unauthorized を返す。これにより、移動端末4aは認証データを付して再度登録を要請する（Register）。CSCFは該認証データを参照して正当であれば該移動端末4aを登録し、登録した旨を示す200OKメッセージを移動端末4aに送信する。以上により、移動端末4aはIMSサービスを受けられるようになる。【０００５】
図２０はIMS端末の発呼手順説明図である。
移動端末4aが発呼すると該移動端末とeNB11a間がRRC(Radio Resource Control)により接続され、しかる後、Attachにより移動端末とaGW間が接続されると共に、移動端末の固有の番号(端末ID)がaGWに通知される。RRC接続が完了するとHSS 6はIASA 3,aGW2aを介して移動端末4aの認証を行う。認証処理が終了すれば、移動端末4aはINVITEメッセージをCSCF 8に送り、CSCF 8はINVITEを受け付けた旨の100 Tryingメッセージを返す。INVITEメッセージは相手電話番号の他に、発信側移動端末4aが希望するQoS情報(例えば音声ビデオの双方向通信)、コーデック情報、使用するメッセージの種別、確認応答の有無などを含んでいる。QoSはQuality of Serviceの略である。
しかる後、CSCF 8はINVITEメッセージを着信側の移動端末14aに送るが移動端末とaGW間が接続されていない場合、aGW 12aは一斉呼び出し（paging）する。このpagingにより着信側の移動端末14aが応答すれば、発信側と同様にRRC接続、認証/秘匿処理が行なわれ、認証が終了すれば、aGW12aはINVITEメッセージを移動端末14aに送る。移動端末14aはINVITEメッセージを受信すれば、受け付けた旨を示す100 Tryingメッセージを返すと共に、セッションの進捗情況を示す183 Session Progressを発行する。183 Session Progressメッセージは、着信側移動端末14aのQoS情報(例えば音声ビデオの双方向通信)、コーデック情報、使用するメッセージの種別、確認応答の有無などを含んでいる。CSCF 8は該183 Session Progressメッセージを受信すれば発信側移動端末4aに通知し、該移動端末4aは183 Session Progressメッセージを受信すれば確認応答であるPRACKをCSCF 8を介して着信側移動端末14aに送る。着信側移動端末14a はPRACKを受信すれば、200OKメッセージをCSCF 8を介して発信側移動端末4aに通知する。【０００６】
以上の処理が終了すれば、CSCF 8のAF(Application Function)は、INVITEメッセージや183 Session Progressメッセージ内のQoS情報および各移動端末の契約情報を参照し、ベアラ（bearer）設定に必要な情報をPCRF/PCEF7に渡し、PCRF/PCEF7は発信側aGW2a、着信側aGW12aとの間でベアラ設定を行ない、各aGW2a、12aは移動端末4a,14aとの間でベアラ設定を行なう。
発信側の移動端末4aはベアラ設定に基づいて更新すれば、UPDATEをCSCF 8を介して着信側移動端末14aに送る。着信側移動端末14aもベアラ設定に基づいて更新を完了していれば200OKメッセージをCSCF 8を介して発信側移動端末4aに送ると共に呼び出し音発生メッセージ（Ringing）を送る。発信側移動端末4aはRingingメッセージを受信すればCSCF 8を介して確認応答PRACKを着信側移動端末14aに送り、着信側移動端末14aは200OKメッセージによりPRACK受信を発信側移動端末4aに送る。
かかる状態において、着信側移動端末14aのユーザが例えば受話機を取り上げれば（Off
Hook）、着信側移動端末14aはCSCF 8を介して200OK(INVITE)を発信側移動端末4aに送り、発信側移動端末4aが200OK(INVITE)の受信によりACKを着信側移動端末14aに返し、これにより両移動端末4a,14a間で通信が可能になる。
図２１は着信側端末14aが圏外でaGW12aがPagingしても応答がない場合のシーケンスであり、CSCF 8はINVITEをaGW12aに送ってからの経過時間を監視し、経過時間が設定時間より大きくなっても100Tryingメッセージが返らなければタイムアウトとなり、408 Request
Timeoutで着信側移動端末14aが応答しない旨を発信側移動端末４aに通知し、発信側移動
端末４aはACKをCSCF 8に送信して処理を終了する。【０００７】
図２２は着信側端末14aがbusy状態にある場合のシーケンスであり、着信側端末14a はCSCF 8からINVITEを受信したときbusy状態であれば486 Busy Hereメッセージを返す。これにより、CSCF 8は486 Busy Hereメッセージを発信側移動端末４aに送って着信側移動端末14aがbusy状態であることを通知し、発信側移動端末４aはACKをCSCF 8に送信して処理を終了する。【０００８】
図２３は処理の呼接続手順の途中でエラーが発生した場合のシーケンスである。着信側移動端末14aはUPDATEの受信に対して200OKメッセージを発生した後で何らかのエラーが発生すると、XXX(error)メッセージ例えば一時的に利用不可能を示すエラーメッセージ480 Temporarily UnavailableをCSCF 8を介して発信側移動端末４aに送り、発信側移動端末４aはACKをCSCF 8に送信して処理を終了する。【０００９】
移動通信システムにおいて基地局と移動端末間は無線で通信を行うが、無線は一般に有線に比べてそのデータ通信速度において劣る。高速通信を行うためには無線通信で使用する周波数帯域を多くとる必要があるが、無線資源は有限であり、周波数帯域を多く取ると、その分同時に通信できる呼数（リンク数）が減ってしまう。このため、無線区間でのシグナリング数(送受信メッセージ数)を減らす必要があり、特に携帯電話のような公衆無線通信システムにおいて求められている。しかし、現状のシステムでは図２０〜図２３で説明したように多数のシグナリングが必要となる。図２０の例では無線区間において12回のシグナリングが必要である。
また、Evolved 3GPPシステムにおいて、呼接続時において発呼から通信開始までの時間（呼接続時間）の短縮が求められている。多くのSIPメッセージがエンド−エンド間を流れると、呼接続時間が長くなって通信開始までの待ち時間が長くなり、しかも、その分、周波数帯域を占有してしまうことになり、無線資源をより多く消費してしまう。
従来より、SIPプロトコルを用いたシグナリング方法が提案されている。第1の従来技術(特許文献1参照)は、SIPプロトコルを使用してIMSサービスを提供するシステムにおいて、発信端末と着信端末間でセッションの設定を試み、セッション設定の試みが失敗したとき、課金しないようにして誤課金を防止するものである。
第2の従来技術(特許文献2参照)は、取得したアドレスのサブネットを越えて端末が移動した場合でも、該端末に冗長経路を通ることなくシグナリングの転送を可能にするものである。【００１０】
従来技術は、呼接続時における無線区間でのシグナリング数を削減することを目的とするものではなく、しかも、呼接続時間を短縮することを目的とするものではない。
以上から、本発明の目的は、呼接続時における無線区間でのシグナリング数を削減することである。
本発明の別の目的は、通信開始に先立って行われる呼接続時間を短縮することである。
【非特許文献１】3GPP,TS24.228v5.14.0
【特許文献１】特表2006−506012号公報
【特許文献２】特開2005−64646号公報
【発明の開示】
【００１１】
本発明の第１の態様は、SIPプロトコルを用いてユーザ端末と基幹ネットワークとの間でアクセスネットワークを介して呼接続を行なう呼接続処理方法であり、前記アクセスネットワーク内の装置（代理装置）に所定のSIPシグナリングメッセージの基幹ネットワークへの送信をユーザ端末に代わって行うよう該ユーザ端末より指示するステップ、該指示にしたがって、呼接続時に前記所定のSIPシグナリングメッセージのあるSIPシグナリングメッセージはユーザ端末へ送らず、あるいは他のメッセージはユーザ端末に代わって基
幹ネットワークへ送信するステップ、前記所定のSIPシグナリングメッセージ以外のメッセージはユーザ端末と基幹ネットワークとの間で送受信するステップを有している。
前記第１ステップの指示は、ユーザ端末がSIPプロトコルのINVITEメッセージで、(１)信頼性応答を要求しないこと、(２)ベアラ設定のための前提条件を指定しないこと、を宣言することにより行ない、前記第２ステップにおいて、前記代理装置は信頼性応答に関するSIPシグナリングメッセージの送受信、およびベアラ設定後の所定のSIPシグナリングメッセージの送受信を、ユーザ端末の代わりに行なう。
上記呼接続処理方法は、更に、所定のSIPシグナリングメッセージの送受信をユーザ端末に代わって行うよう該ユーザ端末より指示がなかったとき、前記代理装置は、所定のSIPシグナリングメッセージの送受信をユーザ端末に代わって行なうことを該ユーザ端末に通知するステップ、前記SIPシグナリングメッセージの送受信をユーザ端末に代わって行なうステップを有している。
上記呼接続処理方法は、更に、呼接続時に発信側ユーザ端末がSIPプロトコルのINVITEメッセージを発信してから、該INVITEメッセージに対する200OKを着信側ユーザ端末が応答する直前までの呼接続処理シーケンスを、該着信側ユーザ端末のネットワークへの接続状態に関係なく、発信側において独自に進めるステップ、発信側ユーザ端末が着信側ユーザ端末より前記200OKを受信後、前記基幹ネットワークを介して発信側ユーザ端末と着信側ユーザ端末間で通信を行うステップを有している。
本発明の第２の態様は、SIPプロトコルを用いてユーザ端末との間で呼接続処理を行う基幹ネットワークにアクセスするアクセスネットワーク内に設けられ、呼接続時にユーザ端末を代理して基幹ネットワークとの間でSIPシグナリングメッセージの送受信を行なうメッセージ送受信代理装置であり、ユーザ端末の能力情報情報や加入者情報を取得して蓄積するユーザ情報蓄積部、SIPシグナリングメッセージを受信して解析する処理、前記蓄積情報を用いたベアラ設定処理、移動端末と基地局間のSIPシグナリングメッセージの中継処理、移動端末に代わってSIPシグナリングメッセージ作成して送信する処理を行なう処理部、ユーザ端末とメッセージの送受信を行なう送受信部、基幹ネットワーク側とメッセージの送受信を行なう送受信部を備えている。
【図面の簡単な説明】
【００１２】
【図１】本発明の原理説明図である。
【図２】本発明を適用できる通信システムの構成図である。
【図３】IMS端末にSIPが搭載されているか否かによりどのシーケンス処理を実行するか決定する処理フローである。
【図４】Evolved 3GPP用に改良したSIPを搭載したIMS端末を購入後にIMSに登録する手順説明図である。
【図５】Evolved 3GPP用に改良したSIPを搭載したIMS移動端末の発呼時における呼接続シーケンス(第１実施例)の説明図である。
【図６】第１実施例の呼接続シーケンスの変形例の説明図である。
【図７】Evolved 3GPP用に改良したSIPを搭載したIMS移動端末の発呼時の別の呼接続シーケンス(第２実施例)である。
【図８】第２実施例の呼接続シーケンスの変形例の説明図である。
【図９】Evolved 3GPP用に改良したSIPを搭載しない通常のIMS移動端末 の発呼時における呼接続シーケンス(第１実施例)の説明図である。
【図１０】第１実施例の呼接続シーケンスの変形例の説明図である。
【図１１】通常のIMS移動端末の発呼時の別の呼接続シーケンス(第２実施例)である。
【図１２】第２実施例の呼接続シーケンスの変形例の説明図である。
【図１３】Evolved 3GPP用に改良したSIPを搭載したIMS端末の呼接続シーケンス(圏外)である。
【図１４】Evolved 3GPP用に改良したSIPを搭載したIMS端末の呼接続シーケンス(圏外)である。
【図１５】Evolved 3GPP用に改良したSIPを搭載したIMS端末の呼接続シーケンス(ビジー状態)である。
【図１６】Evolved 3GPP用に改良したSIPを搭載したIMS端末の呼接続シーケンス(ビジー状態)である。
【図１７】INVITEに対する正常応答200OK(INVITE)を発生する前にError発生メッセージXXX(error)が発生してエラーとなる場合の処理シーケンスである。
【図１８】IMSに接続する次世代ネットワークシステムであるEvolved 3GPPシステムの構成例である。
【図１９】IMS端末である移動端末を購入した時に該移動端末をIMSに登録する手順説明図である。
【図２０】IMS端末の発呼手順説明図である。
【図２１】着信側端末が圏外でaGWがPagingしても応答がない場合のシーケンスである。
【図２２】着信側端末がbusy状態にある場合のシーケンスである。
【図２３】処理の呼接続手順の途中でエラーが発生した場合のシーケンスである。
【発明を実施するための最良の形態】
【００１３】
(A）本発明の原理
本発明は、移動端末とIMS間のSIPプロトコルのメッセージ数を無線区間において減らすことで、無線区間のデータ数を削減し、周波数帯域の占有時間を減らす。また、本発明は、着信側端末の呼出中に中間ノードが先行して接続処理を行うこと、メッセージが通過するノード数を減少させ、これにより呼接続時間の短縮を図る。
ところで、IMS(基幹ネットワーク)側は、仕様によりすでに決められたSIPメッセージを送受信しないと呼制御ができないように決められている。このため、IMSに届くメッセージの数や、IMSから送られるメッセージの数を削減することはできない。そこで、本発明では、無線通信を行う基地局eNBとIMSとの間の中間ノード（代理装置と呼ぶ）に、該IMSと移動端末UE(User Equipment)間で本来送受信されるSIPメッセージの一部の送受信を代行させる。このようにすれば、移動端末に送信し、及び移動端末から受信するSIPメッセージを必要最小限にすることができ、これにより無線区間におけるメッセージ数を削減できる。代理装置は基地局eNBでも良いが、実施例ではaGWを代理装置にしている。
図１は本発明の原理説明図であり、図１（A）は本発明におけるSIPメッセージのフロー
を示し、図１（B）は従来のSIPメッセージのフローを示している。図１（A）において、代理装置であるaGW2a,2ｂは、基幹ネットワークであるIMS 5のCSCF 8と移動端末4a,4b間で本来送受信されるSIPメッセージの一部の送受信を移動端末に代わって行なう。そして、aGW2a,2ｂは、CSCF 8から受信した必要最小限のSIPメッセージのみを移動端末4a,4bに送出し、また、該移動端末から必要最小限のSIPメッセージのみを受信してCSCF 8に送る。この結果、無線区間におけるメッセージ数を削減できる。図１（B）の従来方式では、すべてのSIPメッセージをaGW2a,2bを介してCSCF 8と移動端末4a,4b間で送受信するため無線区間におけるメッセージ数が非常に多くなる。
また、CSCF 8と着信側移動端末間で本来送受信されるSIPメッセージの一部の送受信を着信側aGW（図示せず）に代行可能なように構成する。これにより、着信側aGWと着信側移動端末間の接続を行なっている間に、発信側の呼接続シーケンスを進めることができ、呼接続時間を短縮することが可能になる。【００１４】
（B）システム構成
図２は本発明を適用できる通信システムの構成図であり、基幹ネットワークであるIMS5の左側が送信側のEvolved 3GPPシステムであり、基地局１a、aGW2a、IASA3,移動端末4a、PCRF/PCEF７を備えている。IMS5の右側が受信側のEvolved 3GPPシステムであり、基地局1１a、aGW12a、IASA13,移動端末14a、PCRF/PCEF1７を備えている。
IMS5は呼接続シーケンス処理を行なうために送信側にCSCF8及びAF (Application Function)9を備え、受信側にCSCF18及びAF19を備えている。呼接続時、CSCFが後述する呼接続シーケンス処理を行い、AFがCSCFから提示されたベアラ設定に必要な情報を分析してPCRF/PCEFにベアラ設定を指示する。IMS5は呼接続完了後にデータを図示しないルータを介しては発信側と受信側との間で送受信する。
発信側aGW2aは、各移動端末の端末情報や加入者情報を取得して蓄積するユーザ情報蓄積部51、SIPシグナリングメッセージを受信して解析する処理MAL、前記蓄積情報を用いたベアラ設定処理BST、移動端末と基地局間のSIPシグナリングメッセージの中継処理MRL、移動端末に代わってSIPシグナリングメッセージ作成して送信する処理SAPを行なう処理部52、移動端末とメッセージの送受信を行なう送受信部53、基幹ネットワーク側とメッセージの送受信を行なう送受信部54を備えている。なお、着信側aGW12aも同様の構成を備えている。【００１５】
（Ｃ）呼接続シーケンス
IMS端末としてEvolved 3GPP用に改良したSIPを搭載したIMS端末と,該改良したSIPを搭載しないIMS端末があり、それぞれによりシーケンス処理が異なる。図３はIMS端末にSIPが搭載されているか否かによりどのシーケンス処理を実行するか決定する処理フローである。
GW2aは呼接続の最初に行なわれる認証処理において(ステップ101)、移動端末がEvolved
3GPP用に改良したSIPを搭載したIMS端末であるか判断し(ステップ102)、「YES」であれば第１のシーケンス処理(例えば図５のシーケンス処理)を実行し(ステップ103)、Evolved 3GPP用に改良したSIPを搭載したIMS端末でなければ第２のシーケンス処理(例えば図９のシーケンス処理)を実行する(ステップ104)。【００１６】
（Ｃ−１）Evolved 3GPP用に改良したSIPを搭載したIMS端末のシーケンス
（ａ）登録シーケンス
図４はEvolved 3GPP用に改良したSIPを搭載したIMS端末4aを購入後にIMS5に登録する手順説明図である。登録のための要求があると移動端末4aとeNB 1a間がRRC(Radio Resource
Control)により接続され、しかる後、Attachにより移動端末4aとaGW2a間が接続され、移動端末4aの固有の番号(端末ID)及び該端末の能力情報(メディア情報、コーデック情報)がaGW2aに通知される。メディア情報とは、移動端末が扱えるメディア情報であり、例えば、移動端末が音声情報のみを扱えるか、音声情報とビデオ情報の両方を扱えるかを指示す
る。コーデック情報は音声、ビデオ情報の符号化方法を指示するものである。
RRC接続が完了するとHSS 6はIASA 3,aGW2aを介して移動端末4aの認証を行い、aGW2aは移動端末4aが自分の担当端末である旨をHSS6に登録する。また、aGW2aは前記通知された端末情報(メディア情報、コーデック情報)に加えてHSS 6から取得した加入者情報(例えば加入者サービス情報)を移動端末に対応させて保存する。これにより、aGW2aは呼接続時に発信側移動端末に設定すべきQoSを認識できるようになる。
以上の認証、登録、秘匿処理が終了すれば、移動端末4aはIMSサービスを受けるためにIMS5のCSCF8に登録を要求する（Register）。CSCF8は移動端末4aが未登録であるため、401
Unauthorized を返す。これにより、移動端末4aは認証データを付して再度登録を要請する（Register）。CSCFは該認証データを参照して正当であれば該移動端末4aを登録し、登録した旨を示す200OKメッセージを移動端末4aに送信する。以上により、移動端末4aはIMSサービスを受けられるようになる。【００１７】
（ｂ）第1実施例の呼接続シーケンス
図５はEvolved 3GPP用に改良したSIPを搭載したIMS移動端末4aの発呼時における呼接続シーケンスの説明図である。
移動端末4aが発呼すると該移動端末とeNB11a間がRRCによりが接続され、しかる後、Attachにより移動端末とaGW間が接続されると共に、移動端末の固有の番号(端末ID)がaGWに通知される。RRC接続が完了するとHSS 6はIASA 3,aGW2aを介して移動端末4aの認証を行う。認証処理が終了すれば、移動端末4aはINVITEメッセージをCSCF8,18に送信する。発信側のaGW2aはINVITEメッセージを解釈/中継する。INVITEメッセージは通常表１に示す内容を備えている。
【表１】
2008044265.tif 000003
INVITEメッセージにおいて、“Require: precondition"は、ベアラ設定に際してINVITEメッセージ内のQoS前提条件に従うよう指示するものである。また、
"a=curr.qos local none
a=curr.qos remote none
a=des.qos mandatory local sendrecv
a=des.qos mandatory remote sendrecv"
はQoS前提条件を特定するものであり、2つ存在するが、最初のQoS前提条件はビデオに関して現在自分も相手もQoSが設定されていないが、双方向通信を希望することを意味し、第2番目のQoS前提条件は音声に関して現在自分も相手もQoSが設定されていないが、双方向通信を希望することを意味している。
"Supported:100rel"は確認応答が必要なことを指示するもの、"Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE"は移動端末4aが使用するSIPメッセージを
意味する。【００１８】
通常のIMS移動端末は表１のINVITEメッセージを発生するが、Evolved 3GPP用に改良したSIPを搭載した移動端末4aが発生するINVITEメッセージは表１中の下線で示すメッセージを含まない。INVITEメッセージに"precondition"が含まれないということは、移動端末4aがQoSの前提条件の指定を行なわないことを意味し、INVITEメッセージに"Supported:100rel"が含まれないということは、移動端末4aが確認応答を必要としないことを意味し、PRACK, UPDATEが含まれないことは移動端末4aがPRACK, UPDATEを使用しないことを意味する。
したがって、aGW2aは以降のベアラ設定に際してINVITEメッセージ内の前提条件を参照せず、予め登録されている端末情報、加入者情報に基づいてベアラ設定を行なう。また、aGW2aは確認応答を移動端末4aに送らず、しかも、移動端末4aに代行してPRACK, UPDATEを発行する。【００１９】
図５に戻り、aGW2aは受信したINVITEメッセージをCSCF 8に送り、CSCF 8はINVITEメッセージを受け付けた旨の100 TryingメッセージをaGW2aを介して移動端末4aに返す。また、CSCF 8はINVITEメッセージを着信側の移動端末14aに送るが、着信側の移動端末とaGW間が接続されていない場合、aGW 12aは一斉呼び出し（paging）する。このpagingにより着信側の移動端末14aが応答すれば、発信側と同様にRRC接続、認証/秘匿処理が行なわれ、認証が終了すれば、aGW12aはINVITEメッセージを移動端末14aに送る。移動端末14aはINVITEメッセージを受信すれば、受け付けた旨を示す100 Tryingメッセージを返すと共に、セッションの進捗情況を示す183 Session ProgressメッセージをCSCF8,18に送る。発信側aGW12aは183 Session Progressメッセージを解釈/中継する。183 Session Progressメッセージは表２に示す内容を備えている。
【表２】
2008044265.tif 000004
183 Session Progress メッセージにおいて、"Require:100rel"は確認応答が必要なことを指示するもの、"Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE"は移動端末4aが使用可能なSIPメッセージを意味するものである。また、
"a=curr.qos local none
a=curr.qos remote none
a=des.qos mandatory local sendrecv
a=des.qos mandatory remote sendrecv"
はQoS前提条件を特定するものであり、2つ存在するが、最初のQoS前提条件はビデオに関して現在自分も相手もQoSが設定されていないが、双方向通信を希望することを意味し
、第2番目のQoS前提条件は音声に関して現在自分も相手もQoSが設定されていないが、双方向通信を希望することを意味している。【００２０】
通常のIMS移動端末は表２の183 Session Progress メッセージを発生するが、Evolved 3GPP用に改良したSIPを搭載した移動端末14aが発生する183 Session Progress メッセーは表２中の下線で示すメッセージを含まない。INVITEに"Require:100rel"が含まれないということは、移動端末14aが確認応答を必要としないことを意味し、PRACK, UPDATEが含まれないことは移動端末14aがPRACK, UPDATEを使用しないことを意味し、QoSの前提条件が含まれないということは、移動端末１４aがQoSの前提条件の指定を183 Session Progressで行なわないことを意味する。
したがって、aGW12aは以降のベアラ設定に際して183 Session Progressメッセージの前提条件を参照せず、予め登録されている端末情報、加入者情報に基づいてベアラ設定を行なう。また、aGW12aは確認応答を移動端末14aに送らず、しかも、移動端末14aに代行してPRACK, UPDATEを発行する。【００２１】
図5に戻って、aGW12aは受信した183 Session ProgressメッセージをCSCF8，18に送り、CSCF8，18は183 Session Progressメッセージを、発信側aGW2aを介して発信側移動端末4aに通知する。このとき、aGW2aは移動端末4aに代行して確認応答であるPRACKを、CSCF8，18を介して着信側aGW12aに送る。着信側aGW12aはPRACKを受信すれば着信側移動端末14aに代行して200OKをCSCF8，18 を介して発信側aGW2aに通知する。この場合、発信側aGW2aは該確認応答200OKを着信側移動端末14aへ送信しない。
CSCF8，18のAFは200OKの受信により、予め登録されている端末情報、加入者情報に基づいて端末4a,14aのベアラ設定に必要な情報を決定してPCRF/PCEF7,17に渡し、PCRF/PCEF7、17は発信側aGW2a、着信側aGW12aとの間でベアラ設定を行ない、また、発信側aGW2a及び着信側aGW12aは、移動端末4a,14aとの間でベアラ設定を行なう。
ベアラ設定の完了により、発信側aGW2aは発信側移動端末4aに代行してUPDATEをCSCF 8,18を介して着信側aGW12aに送る。着信側aGW12aはUPDATEを受信したとき、該UPDATEを着信側移動端末14aに送らない。そして、着信側aGW12aは移動端末14aとの間でベアラ設定が完了していれば、該移動端末14aに代行して200OKメッセージをCSCF 8,18を介して発信側aGW2aに送る。発信側aGW2aは200OKメッセージを受信しても移動端末4aに送信しない。【００２２】
着信側移動端末14aはベアラ設定が完了すれば、呼び出し音発生後、Ringingメッセージを、着信側aGW12a,CSCF8,18,発信側aGW2aを介して発信側移動端末4aに送る。発信側aGW2aはRingingメッセージを発信側移動端末4aに送信すれば、移動端末4aに代行してPRACKをCSCF8,18を介して着信側移動端末14aに送信し、着信側移動端末14aはPRACKを受信しても着信側移動端末14aに送らず、直ちに移動端末14aに代行して200OKを送信する。
かかる状態において、着信側移動端末14aのユーザが例えば受話機を取り上げれば（Off
Hook）、着信側移動端末14aは着信側aGW12a,CSCF8,18,発信側aGW2aを介して200OK(INVITE)を発信側移動端末4aに送り、発信側移動端末4aは200OK(INVITE)の受信によりACKを着信側移動端末14aに返す。以上により、両移動端末4a,14a間で通信が可能になる。
第１実施例によれば、送信側の無線区間における呼接続時におけるメッセージ数が12個から6個に半減し、また、受信側の無線区間における呼接続時におけるメッセージ数も12個から6個に半減する。このように、無線区間でのシグナリング数を削減できるため、高速通信を可能にしつつ、同時により多くの呼接続が可能になる。【００２３】
（ｃ）第１実施例の呼接続シーケンスの変形例
図６は第１実施例の呼接続シーケンスの変形例の説明図である。図５の第１実施例において、発信側aGW2aは183 Session Progressメッセージを受信すれば、直ちに、該メッセージを発信側移動端末4aに送信するが、図６の変形例では200OKを受信してから183 Session Progressメッセージを発信側移動端末4aに送信する。
着信側移動端末14aの端末情報や加入者情報によっては、発信側移動端末4aが望むメディアやQoSを正常に選択できない場合がある。かかる場合、着信側aGW12aやCSCF8,18は200OK を出さず、NGを出し、エラーとなることがある。そこで、発信側aGW2aは200OKを受信してから183 Session Progressメッセージを発信側移動端末4aに送信し、NGを受信すれば発信側移動端末4aにエラー通知する。このようにすれば、メディアやQoSなどを正常に選択できたことを確認してから183 Session Progress応答を端末に送信することできる。また、メディアやQoSなどを正常に選択できずに各種エラーが発生しても、発信側移動端末４aから見て183 Session Progress受信前に該エラーメッセージを受信でき、通常のエラーが発生した場合に移動端末が受けるメッセージ順に一致させることができる。【００２４】
（ｄ）呼接続時間を短縮する第2実施例の呼接続シーケンス
図７はEvolved 3GPP用に改良したSIPを搭載したIMS移動端末4aの発呼時の別の呼接続シーケンスであり、呼接続時間を短縮することができる。
図５の呼接続シーケンスと異なる点は、
(1)pagingにより着信側aGW12aと着信側移動端末14a間の接続制御(RRC接続、認証処理など)を行なっている間に、着信側aGW12aが183 Session Progress メッセージを発行する点、
(2)以後、発信側は、着信側移動端末14aに関係なく、接続完了/通信開始を表わす200OK（INVITE）までの呼接続シーケンス処理500を実施する点、
(3)着信側aGW12aと着信側移動端末14a間の接続が完了後、着信側aGW12aと着信側移動端末14a間で独自に200OK（INVITE）までの呼接続シーケンス処理を実施する点、
である。
着信側移動端末14aはRingingを送信後、着信側移動端末14aのユーザが例えば受話機を取り上げれば（Off Hook）、着信側移動端末14aは着信側aGW12a,CSCF8,18,発信側aGW2aを介して200OK(INVITE)を発信側移動端末4aに送り、発信側移動端末4aは200OK(INVITE)の受信によりACKを着信側移動端末14aに返す。以上により、両移動端末4a,14a間で通信が可能になる。
第2実施例によれば、着信側aGW12aと着信側移動端末14a間の接続制御が完了する前に200OK（INVITE）までの呼接続シーケンス処理を実施するため、呼接続処理を短時間で行なうことが可能になる。【００２５】
（ｅ）第２実施例呼接続シーケンスの変形例
図８は第２実施例の呼接続シーケンスの変形例の説明図である。図７の第２実施例において、発信側aGW2aは183 Session Progressメッセージを受信すれば、直ちに、該メッセージを発信側移動端末4aに送信するが、図８の変形例では200OKを受信してから183 Session Progressメッセージを発信側移動端末4aに送信する。
着信側移動端末14aの端末情報や加入者情報によっては、発信側移動端末4aが望むメディアやQoSを正常に選択できない場合がある。かかる場合、着信側aGW12aやCSCF8,18は200OK を出さず、NGを出し、エラーとなることがある。そこで、発信側aGW2aは200OKを受信してから183 Session Progressメッセージを発信側移動端末4aに送信し、NGを受信すれば発信側移動端末4aにエラー通知する。このようにすれば、メディアやQoSなどを正常に選択できたことを確認してから183 Session Progress応答を端末に送信することできる。また、メディアやQoSなどを正常に選択できずに各種エラーが発生しても、発信側移動端末４aから見て183 Session Progress受信前に該エラーメッセージを受信でき、通常のエラーが発生した場合に移動端末が受けるメッセージ順に一致させることができる。【００２６】
(Ｃ-2)通常のIMS端末の呼接続シーケンス
（ａ）登録シーケンス
Evolved 3GPP用に改良したSIPを搭載しない通常のIMS端末4aの登録手順は図１９の従来例と同じである。
（ｂ）通常のIMS端末の第1実施例の呼接続シーケンス
図９はEvolved 3GPP用に改良したSIPを搭載しない通常のIMS移動端末4a の発呼時における呼接続シーケンスの説明図である。
移動端末4aが発呼すると該移動端末とeNB11a間がRRC(Radio Resource Control)によりが接続され、しかる後、Attachにより移動端末とaGW間が接続されると共に、移動端末の固有の番号(端末ID)がaGWに通知される。RRC接続が完了するとHSS 6はIASA 3,aGW2aを介して移動端末4aの認証を行う。認証処理が終了すれば、移動端末4aはINVITEメッセージをCSCF8,18に送信する。通常のIMS移動端末4a が送信するINVITEメッセージは表１に示す内容を備えている。
発信側aGW2aはINVITEメッセージを解釈/中継しCSCF 8、18に送り、CSCF 8、18はINVITEを受け付けた旨の100 TryingメッセージをaGW2aを介して移動端末4aに返す。また、CSCF 8,18はINVITEメッセージを着信側の移動端末14aに送るが、着信側の移動端末とaGW間が接続されていない場合、aGW 12aは一斉呼び出し（paging）をする。このpagingにより着信側の移動端末14aが応答すれば、発信側と同様にRRC接続、認証/秘匿処理が行なわれ、認証が終了すれば、着信側aGW12aはINVITEを着信側移動端末14aに送る。移動端末14aはINVITEメッセージを受信すれば、受け付けた旨を示す100 Tryingメッセージを返すと共に、セッションの進捗情況を示す183 Session ProgressをCSCF8,18に送る。183 Session Progressは表２に示す内容を備えている。【００２７】
着信側aGW12aは183 Session Progressメッセージを中継/解釈し、CSCF8，18に送り、CSCF8，18は183 Session Progressメッセージを発信側の移動端末4aに送る。発信側aGW2aは183 Session Progressメッセージを受信すると、183 Session Progressメッセージ内の信頼性応答に関する項目を削除して発信側移動端末4aに通知する。信頼性応答に関する項目は、"Require:100rel"と"PRACK"である。これにより、発信側移動端末4aは183 Session Progressメッセージを受信してもPRACKを送らない。
発信側aGW2aは183 Session Progressメッセージを発信側移動端末4aに送出後、発信側移動端末4aに代行して183 Session Progressメッセージの確認応答であるPRACKを、CSCF8，18、着信側aGW12aを介して着信側移動端末14aに送る。着信側移動端末14a はPRACKを受信すれば、200OKメッセージをCSCF 8、18を介して発信側aGW2aに送る。発信側aGW2aは200OKメッセージを受信しても発信側衣合端末4aに送らない。
以上の処理が終了すれば、CSCF 8,18のAFは、INVITEメッセージや183 Session Progressメッセージ内のQoS情報および各移動端末の契約情報を参照し、ベアラ設定に必要な情報をPCRF/PCEF7,17に渡し、PCRF/PCEF7,17は発信側aGW2a、着信側aGW12aとの間でベアラ設定を行ない、各aGW2a、12aは移動端末4a,14aとの間でベアラ設定を行なう。【００２８】
発信側の移動端末4aはベアラ設定に基づいて更新すれば、発信側aGW2a、CSCF 8,18、着信側aGW12aを介してUPDATEを着信側移動端末14aに送る。着信側移動端末14aもベアラ設定に基づいて更新を完了していれば200OKメッセージを着信側aGW12a ,CSCF 8,18, 発信側aGW2aを介して発信側移動端末4aに送ると共に呼び出し音発生メッセージ（Ringing）を送る。
発信側aGW2aは、Ringingメッセージを受信すると、該Ringingメッセージ内の信頼性応答に関する項目を削除して発信側移動端末4aに通知する。これにより、発信側移動端末4aはRingingメッセージを受信してもPRACKを送らない。
発信側aGW2aはRingingメッセージを発信側移動端末4aに送出後、該発信側移動端末4aに代行して確認応答であるPRACKを、CSCF8，18、着信側aGW12aを介して着信側移動端末14aに送る。着信側移動端末14a はPRACKを受信すれば、200OKメッセージをCSCF 8、18を介して発信側の移動端末4aに送る。発信側aGW2aは200OKメッセージを受信しても発信側移動端末4aに送らない。
かかる状態において、着信側移動端末14aのユーザが例えば受話機を取り上げれば（Off
Hook）、着信側移動端末14aはCSCF 8を介して200OK(INVITE)を発信側移動端末4aに送り
、発信側移動端末4aが200OK(INVITE)の受信によりACKを着信側移動端末14aに返せば、両移動端末4a,14a間で通信が可能になる。
第１実施例によれば、送信側の無線区間における呼接続時におけるメッセージ数が12個から８個に減少する。このように、無線区間でのシグナリング数を削減できるため、通常のIMS端末であっても高速通信を可能にしつつ、同時により多くの呼接続が可能になる。【００２９】
（ｃ）第１実施例の呼接続シーケンスの変形例
図１０は第１実施例の呼接続シーケンスの変形例の説明図である。図９の第１実施例において、発信側aGW2aは183 Session Progressメッセージを受信すれば、直ちに、該メッセージを発信側移動端末4aに送信するが、図10の変形例では200OKを受信してから183 Session Progressメッセージを発信側移動端末4aに送信する。
着信側移動端末14aの端末情報や加入者情報によっては、発信側移動端末4aが望むメディアやQoSを正常に選択できない場合がある。かかる場合、着信側aGW12aやCSCF8,18は200OK を出さず、NGを出し、エラーとなることがある。そこで、発信側aGW2aは200OKを受信してから183 Session Progressメッセージを発信側移動端末4aに送信し、NGを受信すれば発信側移動端末4aにエラー通知する。このようにすれば、メディアやQoSなどを正常に選択できたことを確認してから183 Session Progress応答を端末に送信することできる。また、メディアやQoSなどを正常に選択できずに各種エラーが発生しても、発信側移動端末４aから見て183 Session Progress受信前に該エラーメッセージを受信でき、通常のエラーが発生した場合に移動端末が受けるメッセージ順に一致させることができる。【００３０】
（d）呼接続時間を短縮する第2実施例の呼接続シーケンス
図１１は通常のIMS移動端末4aの発呼時の別の呼接続シーケンスであり、呼接続時間を短縮することができる。
図９の呼接続シーケンスと異なる点は、
(1)pagingにより着信側aGW12aと着信側移動端末14a間の接続制御(RRC接続、認証処理など)を行なっている間に、着信側aGW12aが移動端末１４ａに代行して183 Session Progress メッセージを発行する点、
(2)以後、着信側移動端末14aに関係なく、接続完了/通信開始を表わす200OK（INVITE）までの呼接続シーケンス処理501を実施する点、
(3)着信側aGW12aと着信側移動端末14a間の接続が完了後、着信側aGW12aと着信側移動端末14a間で独自に200OK（INVITE）までの呼接続シーケンス処理を実施する点、
である。
着信側移動端末14aがRingingを送信後、着信側移動端末14aのユーザが例えば受話機を取り上げれば（Off Hook）、着信側移動端末14aは着信側aGW12a,CSCF8,18,発信側aGW2aを介して200OK(INVITE)を発信側移動端末4aに送り、発信側移動端末4aは200OK(INVITE)の受信によりACKを着信側移動端末14aに返す。以上により、両移動端末4a,14a間で通信が可能になる。
第2実施例によれば、着信側aGW12aと着信側移動端末14a間の接続制御が完了する前に200OK（INVITE）までの呼接続シーケンス処理を実施するため、呼接続処理を短時間で行なうことが可能になる。【００３１】
（ｅ）第２実施例呼接続シーケンスの変形例
図１２は第２実施例の呼接続シーケンスの変形例の説明図である。図１１の第２実施例において、発信側aGW2aは183 Session Progressメッセージを受信すれば、直ちに、該メッセージを発信側移動端末4aに送信するが、図１２の変形例では200OKを受信してから183
Session Progressメッセージを発信側移動端末4aに送信する。
着信側移動端末14aの端末情報や加入者情報によっては、発信側移動端末4aが望むメディア通信あるいはQoSサービスができない場合がある。かかる場合には、CSCF8,18は200OK
を出さず、NGを出し、エラーとなることがある。そこで、発信側aGW2aは200OKを受信し
てから183 Session Progressメッセージを発信側移動端末4aに送信し、NGを受信すれば発信側移動端末4aにエラー通知する。発信側移動端末4aは183 Session Progressメッセージを受信していないからエラー通知により呼接続を直ちに終了できる。【００３２】
（Ｄ）圏外、ビジー状態時における処理シーケンス
図１３〜図１６は、Evolved 3GPP用に改良したSIPを搭載したIMS端末の呼接続シーケンス(図７の第２実施例)において、着信側移動端末が圏外の場合、busy状態の場合における処理シーケンスである。
図１３は発信側移動端末4aへ183 Session Progressメッセージを送信後に、着信側移動端末14aが圏外のため応答がなくタイムアウトとなり、着信側aGW12aが406Request Timeoutを発生してエラーとなる場合の処理シーケンスである。
図１４は発信側移動端末4aへ183 Session Progressメッセージを送信前に、着信側移動端末14aが圏外のため応答がなくタイムアウトとなり、着信側aGW12aが406Request Timeoutを発生してエラーとなる場合の処理シーケンスである。
図１５は発信側移動端末4aへ183 Session Progressメッセージを送信後に、着信側移動端末14aがbusy状態のため、着信側aGW12aが486 Busy Here を発生してエラーとなる場合の処理シーケンスである。
図１6は発信側移動端末4aへ183 Session Progressメッセージを送信前に、着信側移動端末14aがbusy状態のため、着信側aGW12aが486 Busy Here を発生してエラーとなる場合の処理シーケンスである。
図１７はINVITEに対する正常応答200OK(INVITE)を発生する前にError発生メッセージXXX(error)が発生してエラーとなる場合の処理シーケンスである。発信側移動端末4a は200OK(INVITE)を受信していないので通常の発呼時のエラーとなる。【００３３】
・発明の効果
以上本発明によれば、多様なサービスを享受しながら無線区間のシグナリング数を削減することができ、同時により多くのリンクが通信可能となる。また、エンドーエンド間を流れるSIPメッセージを削減することにより、呼接続時間の短縮を図ることができ、周波数帯域を占有することなく、無線資源の有効活用ができるようになる。
【図１】
2008044265.tif 000005
【図２】
2008044265.tif 000006
【図３】
2008044265.tif 000007
【図４】
2008044265.tif 000008
【図５】
2008044265.tif 000009
【図６】
2008044265.tif 000010
【図７】
2008044265.tif 000011
【図８】
2008044265.tif 000012
【図９】
2008044265.tif 000013
【図１０】
2008044265.tif 000014
【図１１】
2008044265.tif 000015
【図１２】
2008044265.tif 000016
【図１３】
2008044265.tif 000017
【図１４】
2008044265.tif 000018
【図１５】
2008044265.tif 000019
【図１６】
2008044265.tif 000020
【図１７】
2008044265.tif 000021
【図１８】
2008044265.tif 000022
【図１９】
2008044265.tif 000023
【図２０】
2008044265.tif 000024
【図２１】
2008044265.tif 000025
【図２２】
2008044265.tif 000026
【図２３】
2008044265.tif 000027
【国際調査報告】
2008044265.tif 000028
2008044265.tif 000029
2008044265.tif 000030
2008044265.tif 000031