JP2007324788A - 移動端末及び通信方法 - Google Patents

Abstract

【課題】
通信の継続性を高め、リアルタイム通信の通信品質を維持可能な移動端末及び通信方法を提供すること。
【解決手段】
本発明にかかる通信方法は、複数の通信網において無線通信可能な第１の移動端末１ａと、第２の移動端末１ｂ間の通信方法である。まず、第１の移動端末１ａと第２の移動端末１ｂとの間で、通信を行なう通信セッションを確立するために必要な情報を呼制御装置３を介して交換する。次に、交換した必要情報に基づいて、通信セッションを確立するセッションを確立する。確立された通信セッションにより第１の移動端末１ａと第１の移動端末１ｂとの間で通信を実行する。
【選択図】 図８

Description

本発明は、移動端末及び通信方法に関し、特に、アクセス網間を移動端末が移動した場合であっても通信状態を継続するための通信技術に関する。

近年、無線通信技術の発展により、Ｗ−ＣＤＭＡなどのセルラーネットワークといった代表的な通信メディアに加えて、例えば無線ＬＡＮ（Local Area Network）やＰＨＳ（Personal Handyphone System）ネットワークといった他の通信メディアも普及している。このため、移動先の電波条件やユーザの必要とする通信条件に応じてこれらの通信方式の中の１つを自在に選択して通信することができるようになった。

図１３は、モバイルＩＰを用いた通信方法を説明するための説明図である。図１３は、移動端末１ａと移動端末１ｂ間で通信を行なう場合を示している。通信網２０２上に設けられたセンターサーバであるホームエージェント（ＨＡ）２０１に、ホームアドレス（ＨｏＡ）２０６と気付けアドレス（ＣｏＡ）２０５との対応関係が登録されている。ホームアドレス２０６は、各移動端末に割り当てられ、移動しても変更されることのないアドレスである。気付けアドレス２０５は、移動端末が移動先において利用することのできる通信メディア（ネットワークカード）に割り当てられ、移動に伴って変更されるアドレスである。

図１３に示されるように、移動端末１ａが通信網２０３から他の通信網２０４に移動したときには、ホームエージェント２０１において、この移動端末１ａに対するホームアドレス２０６は不変であるが、気付けアドレス２０５は、気付けアドレス２０５ａから気付けアドレス２０５ｂに変更される。移動端末１ｂから送信されたデータパケットは、ホームエージェント２０１が受け取り、このホームエージェント２０１から図示しないフォーリンエージェントに転送され、フォーリンエージェントは、これを移動端末１ａに送信する。

このように、不変のホームアドレス２０６と可変の気付けアドレス２０５とを関連付けてホームエージェント２０１に登録しておくことにより、この登録された移動端末１aと通信する相手方端末は、この移動端末がどこへ移動しようとも、ホームエージェント２０１においてホームアドレス２０６と関連付けられた気付けアドレス２０５を参照すれば、当該移動端末との間の当該通信をそのまま継続させることができる。
特開２００６−８０９８１号公報 特開２００１−２３７８６９号公報

モバイルＩＰを用いた通信方法では、常にホームエージェント経由で通信を行なうため、経路が冗長であり、また、移動端末と通信相手の直接通信には不要なはずのホームエージェントとフォーリンエージェント間の転送トラフィックが余分に発生する。さらに、ホームエージェントとフォーリンエージェント間のトラフィックは、ＩＰパケットをカプセル化して転送しているため、追加されたＩＰヘッダ分だけ通常のＩＰパケットよりも情報量が多い。このような理由から、パケット損失や伝送遅延が発生するという問題が発生していた。この問題は当然、通信品質（ＱｏＳ）の劣化をひき起こし、例えばＩＰ電話などのようにリアルタイム通信が要求される場合には支障をきたす。

なお、特許文献２には、プロキシ[k4]を用いて通信中断時に通信データの送受信を行なう技術が開示されているが、この通信システムは、移動端末において位置管理を実行するものであり、本発明が対象とする通信システムとは異なる。

本発明は以上のような事情を背景としてなされたものであって、本発明は[k5]、通信の継続性を高め、リアルタイム通信の通信品質を維持可能な移動端末及び通信方法を提供することを目的とする。

本発明にかかる移動端末は、複数の通信網において無線通信可能な移動端末であって、通信相手との間で通信を行なう通信セッションを確立するために必要な情報を交換するコントローラと、交換した必要情報に基づいて、前記通信セッションを確立し、確立された通信セッションにより通信相手との間で通信を実行する通信手段とを備え、前記コントローラは、前記呼制御装置を介して通信相手との間で呼制御を実行することによって、前記必要情報を取得するものである。

ここで、前記コントローラは、通信アプリケーションの要求に応じて、当該通信アプリケーションとの間でローカルセッションを確立するものであることが望ましい。

また、前記コントローラは、ハンドオーバを行なうときに、情報交換を実行し、新たな通信セッションに移行することが好ましい。

さらに、前記コントローラは、通信相手からデータを正常に受信したことを示す信号を、通信相手に対して送信することが望ましい。

また、前記コントローラは、通信相手との通信セッションが切断された場合に、正常に受信したデータを特定する情報を、通信相手に対して送信することが好ましい。

また、前記コントローラは、コントローラ上の送信バッファから、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに対してデータを書き込むことができたか否かに応じて、正常送信済みのデータの有無について判定し、正常送信済みのデータがあると判定した場合には、そのデータについて当該コントローラ上の送信バッファから破棄するようにするとよい。また、前記移動端末のコントローラは、前記通信相手のコントローラとの間で前記通信セッションを確立するために必要な情報を交換し、かつ、確立された通信セッションにより通信を実行することが望ましい。

本発明にかかる通信方法は、複数の通信網において無線通信可能な第１の移動端末と、第２の移動端末間の通信方法であって、前記第１の移動端末と前記第２の移動端末との間で、通信を行なう通信セッションを確立するために必要な情報を呼制御装置を介して交換する情報交換ステップと、交換した必要情報に基づいて、前記通信セッションを確立するセッション確立ステップと、確立された通信セッションにより前記第１の移動端末と前記第２の移動端末との間で前記呼制御装置を介さずに通信を実行する通信実行ステップとを備えたものである。

ここで、前記情報交換ステップは、通信アプリケーションの要求に応じて、当該通信アプリケーションとの間でローカルセッションを確立するコントローラによって実行するものとすることが望ましい。

また、前記情報取得ステップは、ハンドオーバを行なうときに実行することが好ましい。

また、前記第１の移動端末が、前記第２の移動端末からの正常受信を示す信号を、前記第２の移動端末に対して送信するステップと、前記第２の移動端末が、前記正常受信を示す信号に応じて、送信バッファのデータを破棄するステップをさらに備えるとよい。

さらに、前記第１の移動端末が、通信セッションが切断された場合に、正常に受信したデータを特定する情報を、前記第２の移動端末に対して送信するステップと、前記第２の移動端末が、前記正常に受信したデータを特定する情報に基づいて、送信バッファのデータを破棄するステップとを備えるとよい。

また、前記コントローラ上の送信バッファから、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに対してデータを書き込むことができたか否かに応じて、正常送信済みのデータの有無について判定し、正常送信済みのデータがあると判定した場合には、そのデータについて当該コントローラ上の送信バッファから破棄するステップをさらに備えるようにするとよい。また、前記情報交換ステップ、セッション確立ステップ及び通信実行ステップは、前記第１の移動端末のコントローラと前記第２の移動端末のコントローラ間で実行されることが望ましい。

本発明によれば、コネクション型通信の継続性を高め、リアルタイム通信の通信品質を維持可能な移動端末及び通信方法を提供することができる。

最初に、図１を用いて、本発明にかかる通信方法が適用される無線通信システムの構成について説明する。

図１に示されるように、当該通信システムにおいては、パケット交換網（ＩＰ網）２に呼制御装置３が接続されている。パケット交換網２は、パケット交換方式により音声又はデータ通信を行なうコア（核）となる通信網である。呼制御装置３は、ＳＩＰサーバ装置（ＳＩＰ：Session Initiation Protocol）とも呼ばれ、移動端末の位置登録等の呼制御を実行する。なお、ＳＩＰは、ＩＰ電話、ビデオ会議などのセッションに関するシグナリングを行うプロトコルであり、ＲＦＣ３２６１に規定されている。なお、H.323等の他のプロトコルによる実装も可能である。

呼制御装置３は、例えば、ネットワークインターフェイス、呼制御部、ハンドオーバ処理部、位置登録処理部及び登録データベース３１を備えている。ネットワークインターフェイスは、物理ネットワークインターフェイス及び物理ネットワークインターフェイスに対応するデバイスドライバ、ダイアルアップ機能等の網制御機能や基本プロトコルスタック（ＴＣＰ／ＵＤＰ／ＩＰ等）を備えている。呼制御部は、移動端末１ａとの間で呼制御メッセージを送受信し、この呼制御メッセージを着信先となる移動端末１ｂに対して送信することにより発呼・着呼処理を実行する。ハンドオーバ処理部は、無線回線網及びパケット交換網等の異種網間の音声ハンドオーバ処理を行う。位置登録処理部は、ユーザの移動端末１の位置登録を実行する。登録データベース３１には、各ユーザの位置情報及び接続状態に関する情報が格納されている。

さらに、パケット交換網２には、無線回線交換網４ａ，４ｂ、無線パケット交換網（無線ＬＡＮ）５ａ，５ｂ，５ｃ、ＩＰ電話網６が接続されている。無線回線交換網４ａ等は、ゲートウェイ装置４１ａ等を介して当該パケット交換網２と接続され、移動端末１と通信可能な基地局４２ａ等を備えている。無線パケット交換網５ａ等は、ルータ５１ａ等を介して当該パケット交換網２と接続され、移動端末１と通信可能なアクセスポイント５２ａ等を備えている。ＩＰ電話網６は、ルータ６１を介してパケット交換網２と接続されている。移動端末１が各通信網間を移動する場合には、ハンドオーバが実行される。

図１に示されるように、本発明にかかる通信方法を実行することによって、移動端末１は、音声やデータ通信を継続しながらシームレスに通信網間を移動することができる。本発明にかかる移動端末１は、後に詳述するセッション・モビリティ制御を実行するミドルウェアプログラム１０２がインストールされている。

図２は、本発明にかかる移動端末の構成を示すブロック図である。図に示されるように、移動端末１は、通信アプリケーション処理部１０１、セッション・モビリティ制御部１０２、呼制御部１０３、インターフェイス選択制御部１０４、通信インターフェイス群１０５を備えている。

通信アプリケーション処理部１０１は、ウェブブラウザ、メールソフトウェア等の各種の通信を実現するためのアプリケーションプログラムにより実行される機能ブロックである。

セッション・モビリティ制御部１０２は、本発明の特徴的な構成であるセッション・モビリティコントローラに相当する。セッション・モビリティ制御部１０２は、移動端末間で通信を開始若しくは再開する場合に、通信セッションの確立のために必要な情報の交換を呼制御装置３を介して実行する。

通信アプリケーション処理部１０１によって実行される通信処理は、このセッション・モビリティ制御部１０２が介在し、通信相手との間では当該セッション・モビリティ制御部１０２同士が通信を行なう。通信アプリケーション処理部１０１は、通信相手と通信しているのと同様の処理により当該セッション・モビリティ制御部１０２との間で通信処理を行う。

呼制御部１０３は、セッション・モビリティ制御部１０２内に設けられ、呼制御装置３との間で呼制御に関する処理を実行する。

インターフェイス選択制御部１０４は、ユーザの要求、通信コスト、通信品質（電界強度）等に基づいて、通信インターフェイス群１０５より任意の通信インターフェイスを選択する処理を実行する。

通信インターフェイス群１０５には、例えば無線回線交換網４用のインターフェイスであるＣＳＲ−ＩＦ（Circuit Switch Radio Interface）や、無線パケット交換網５用のインターフェイスであるＰＳＲ−ＩＦ（Packet Switch Radio Interface）等、各種の通信網に対応したインターフェイスが含まれる。この通信インターフェイス群１０５に含まれる通信インターフェイスは、物理ネットワークインターフェイス及びこの物理ネットワークインターフェイスに対応するデバイスドライバ、ダイアルアップ機能等の網制御機能（ＮＣＵ）や基本プロトコルスタック（ＴＣＰ／ＵＤＰ／ＩＰ）等を備えている。

図３は、本発明にかかる移動端末の具体的なソフトウェア構成を示すブロック図である。アプリケーション部１１に対応するソフトウェアには、ＴＣＰベースのクライアントアプリケーション(以下、単に「ＴＣＰアプリケーション」とする場合がある）１１と、ＵＤＰベースのクライアントアプリケーション（以下、単に「ＵＤＰアプリケーション」とする場合がある）１２が含まれる。ＵＤＰアプリケーション１２には、プレゼンスソフトウェア１２１、ＩＭ（Instant Messaging）ソフトウェア１２２、ＰＴＴ（Push To Talk）ソフトウェア１２３、Ｖｉｄｅｏソフトウェア１２４、ＶｏＩＰ（Voice Over Internet Protocol）ソフトウェア１２５が含まれ、リアルタイム通信が実現される。

ミドルウェア１３には、セッション・モビリティコントローラ（以下、単に「ＳＭＳ」とする場合がある）１３１とＳＩＰ処理プログラム１３２が含まれる。ＳＭＳ１３１は、図２のセッション・モビリティ制御部１０２に相当するミドルウェアからなる通信用コンピュータプログラムである。また、ＳＩＰ処理プログラム１３２が呼制御部１０３に相当する。ＳＭＣ１３１とデータのやり取りが可能にダイアラー１４が設けられている。ダイアラー１４は、ＣＣＳ（Cellular CS Network）インターフェイス１７が設けられている。

ＯＳ（Operating System）である基本ソフトウェア１５には、ＴＣＰ／ＩＰ処理プログラム１５１、ＵＤＰ／ＩＰ処理プログラム１５２及びインターフェイス選択及びハンドオーバ制御プログラム１５３が含まれる。インターフェイス選択及びハンドオーバ制御プログラム１５３がインターフェイス選択制御部１０４に相当する。通信インターフェイス１６には、ＷｉＦｉインターフェース１６１、ＣＰＳ（Cellular PS Network）インターフェイス１６２、ＰＨＳインターフェイス１６３、Ｗｉｒｅインターフェイス１６４、ＷｉＭＡＸインターフェイス１６５等が含まれる。

このようなソフトウェア構成において、ＳＭＣ１３１は、アプリケーション１１とＴＣＰ／ＩＰ処理プログラム１５１やＵＤＰ／ＩＰ処理プログラム１５２の間に設けられている。また、ＳＭＣ１３１は、ＴＣＰ／ＩＰ処理プログラム１５１やＵＤＰ／ＩＰ処理プログラム１５２との間でデータのやり取りを実行する。ミドルウェア１３と基本ソフトウェア１５間は、ソケットインターフェイスを介してデータのやり取りが実行される。ＳＭＣ１３１は、インターフェイス選択及びハンドオーバ制御プログラム１５３との間でＩＰＳ（Inter-Process Communication）を実行する。ＳＩＰ処理プログラム１３２は、ＵＤＰ／ＩＰ処理プログラム１５２を利用して、通信相手との間でシグナリングのやり取りを実行する。

続いて、図４を用いて、本発明にかかる通信方法を実現するための接続方式の一例として、ＡＬＧ（Application Level Gateway）方式について説明する。図４では、クライアントとして機能する移動端末１ａと、サーバとして機能する移動端末１ｄとの間で、パケット交換網２を含む各種の通信網を介して通信が行なわれる場合を示している。

移動端末１ａの呼制御部１３２は、ＵＤＰ処理プログラム１５２１及びＩＰ処理プログラム１５１２を介して呼制御装置３との間でＳＩＰを利用したシグナリングを行い、移動端末間で通信を開始若しくは再開する場合に、通信セッションの確立のために必要な情報の交換を呼制御装置３を介して実行する。移動端末１ａ，１ｄのＴＣＰアプリケーション１１は、それぞれＳＭＣ１３１を認識せずに、相互に通信しているものとして通常の処理を行っている。

また、移動端末１ａのウェブブラウザ等のＴＣＰアプリケーション１１は、ＴＣＰ処理プログラム１５１１やＩＰ処理プログラム１５１２を介してＳＭＣ１３１との間で、アプリケーションデータＤ１の送受信を行なう。このとき、ＴＣＰアプリケーション１１では、ローカルアドレスにプロキシ[k6]設定を行なう必要がある。ＳＭＣ１３１は、アドレス対応表１３１１を備えており、これに基づいてＳＩＰとＵＲＩ間でアドレス変換等を実行し、ＴＣＰ処理プログラム１５１１やＩＰ処理プログラム１５１２を介して、通信相手である移動端末１ｄと通信を行なう。移動端末１ｄも、移動端末１ａと同様の処理を実行する。

移動端末１内でのローカルＴＣＰコネクションは、移動による切断が発生しないが、特にＳＭＣ１３１間でTCP通信を行う場合は、通信網の切替時、即ちハンドオーバ処理時に通信状態が切断される。図４に示すＡＬＧ方式では、ＳＭＣ１３１がアプリケーションレベルで実装が可能であるため、比較的に容易に実現できる。ただし、ＳＭＣ１３１内にＨＴＴＰ／ＦＴＰ／ＰＯＰ／Ｔｅｌｎｅｔ等、アプリケーションプロトコル毎に該当モジュールを実装しなければならない。

図５は、他の接続方式であるTCP over UDP方式を示す説明図である。移動端末１ａの呼制御部１３２は、ＵＤＰ処理プログラム１５２１及びＩＰ処理プログラム１５２２を介して呼制御装置３との間でＳＩＰを利用したシグナリングを行い、ＴＣＰの再接続や再送制御等を行う。

また、移動端末１ａのＴＣＰアプリケーション１１は、ＴＣＰ処理プログラム１５１１やＶｉｒｔｕａｌ ＩＰ処理プログラム１５１３を介してＳＭＣ１３１との間で、ＴＣＰ／ＩＰパケットデータＤ３の送受信を行なう。このとき、ＴＣＰアプリケーション１１では、仮想ＩＦアドレスにプロキシ[k7]設定を行なう必要がある。ＳＭＣ１３１は、アドレス対応表１３１１を備えており、これに基づいてアドレス変換等を実行し、ＵＤＰ処理プログラム１５２１やＩＰ処理プログラム１５２２を介して、TCP/IPパケットデータD3をUDP/IPでカプセル化して、通信相手である移動端末１ｄと通信を行なう。移動端末１ａと移動端末１ｄ間は、外部ＵＤＰセッションが確立するが、通信網を移動した場合のアドレス変更はＳＩＰモビリティで対応する。移動端末１ｄも、移動端末１ａと同様の処理を実行する。

図５に示す方式は、ＳＭＣ１３１内にアプリケーションプロトコル毎に実装する必要性がないという利点を有する。

続いて、図６を用いて、本発明にかかる通信システムにおけるネットワーク接続形態を説明する。図６に示す各構成は、図１や図２において説明したものと同様であるため説明を省略する。この例では、移動端末１ａと移動端末１ｄのそれぞれにリソース１０が設けられおり、移動端末１ａと移動端末１ｄとが通信状態にある。移動端末１ａは無線パケット交換網５ｂに収容され、移動端末１ｄはＩＰ電話網６に収容された状態にあるが、移動して他の通信網に収容されうる。

図７に示すネットワーク接続形態では、移動端末１ａにリソース１０ａが設けられ、パケット交換網２とルータ７１ｃを介して接続されたインタネット網７ｃに接続されたウェブサーバ７２にリソース１０ｂが設けられている。移動端末１ａは無線パケット交換網５ｂに収容された状態にあるが、移動して他の通信網に収容されうる。中継装置１ｃは、ルータ６１を介してパケット交換網２に接続された有線網６に収容されている。移動端末１ａは、この中継装置１ｃを介してウェブサーバ７２と通信することができ、リソース１０ｂのデータを取得することができる。

続いて、図８を用いて、本発明にかかる通信方法を説明する。図８のシーケンス図では、端末間（クライアントとサーバ間）の通信で最初に実行される初期シグナリング処理を示している。この例では、クライアントがウェブブラウザによりウェブサーバよりウェブデータを取得している。

最初に、クライアント側のＴＣＰアプリケーション１１ａ（ここでは、ウェブブラウザ）は、クライアント側のＳＭＣ１３１ａとの間でＴＣＰローカルセッションを確立する（Ｓ１０１）。次に、ＴＣＰアプリケーション１１ａは、ＳＭＣ１３１ａに対して所定のＵＲＬのデータを要求する（Ｓ１０２）。

ＳＭＣ１３１ａの呼制御部１０３ａは、受け取ったＵＲＬをＳＩＰに変換する（Ｓ１０３）。さらに、ＳＭＣ１３１ａの呼制御部１０３ａは、対応表のエントリを作成する（Ｓ１０４）。例えば、ＴＣＰ接続ソースアドレス・ポートやウィンドウサイズやセグメントサイズを対応表に書き込む。

ＳＭＣ１３１ａの呼制御部１０３ａは、ＩＮＶＩＴＥメッセージを呼制御装置３に対して送信する（Ｓ１０５）。ここで、ＩＮＶＩＴＥメッセージは、ＳＩＰ上での接続要求であり、このＩＮＶＩＴＥメッセージ中には、ＳＭＣ１３１ａとＳＭＣ１３１ｂ（ここでは、ウェブサーバ）間で直接通信を行なうための通信セッションを確立するために必要な情報が含まれる。通信セッションを確立するために必要な情報としては、クライアント側のＳＭＣ１３１ａのＴＣＰ接続ソースアドレス・ポート、ウィンドウサイズ、セグメントサイズがある。

呼制御装置３は、受信したＩＮＶＩＴＥメッセージを通信相手方の移動端末１にインストールされたサーバ側のＳＭＣ１３１ｂに送信する（Ｓ１０６）。このとき、呼制御装置３は、各移動端末の位置登録管理を行なっているため、その位置登録情報に基づき、当該ＩＮＶＩＴＥメッセージを通信相手方の移動端末１が収容された通信網を介して当該通信相手方の移動端末１に対して送信することができる。

サーバ側のＳＭＣ１３１ｂは、ＩＮＶＩＴＥメッセージを受信し、少なくとも通信セッション（ＴＣＰ／ＵＤＰセッション）の確立に必要な情報を所定の記憶領域に格納しておく。ＳＭＣ１３１ｂの呼制御部１０３ｂは、さらにＩＮＶＩＴＥメッセージの受信に応じて対応表のエントリを作成する（Ｓ１０７）。さらに、ＳＭＣ１３１ｂとサーバ側のＴＣＰアプリケーション１１ｂとの間で、ＴＣＰローカルセッションを確立する（Ｓ１０８）。

その後、ＳＭＣ１３１ｂの呼制御部１０３ｂは、呼制御装置３に対して、サーバ側のＳＭＣ１３１ｂのＴＣＰ接続ソースアドレス・ポート、ウィンドウサイズ、セグメントサイズ等の通信セッションの確立に必要な情報を含む応答信号を送信する（Ｓ１０９）。呼制御装置３は、応答信号を受信して、クライアント側のＳＭＣ１３１ａに送信する（Ｓ１１０）。クライアント側のＳＭＣ１３１ａは応答信号を受信して、少なくとも通信セッションの確立に必要な情報を所定の記憶領域に格納しておく。

次に、ＳＭＣ１３１ａとＳＭＣ１３１ｂ間で直接にＴＣＰ若しくはＵＤＰのセッションを確立する（Ｓ１１１）。このように、本発明にかかる通信方法では、最初に、ＳＭＣ１３１ａ，ｂの呼制御部１０３ａ，ｂの間で呼制御装置３を介して通信を行なうことにより通信セッションの確立に必要な情報を取得し、取得した情報に基づいて、ＳＭＣ１３１ａとＳＭＣ１３１ｂ間で直接、呼制御装置３を介さずに、通信セッションを確立する。

そして、ＳＭＣ１３１ａ及びＳＭＣ１３１ｂのそれぞれにおいて対応表を作成する（Ｓ１１２，Ｓ１１３）。

ＳＭＣ１３１ａは、ＳＭＣ１３１ｂに対して、Ｓ１０２においてＴＣＰアプリケーション１１ａから受信した要求信号と同じ内容の要求信号を送信する（Ｓ１１４）。ＳＭＣ１３１ｂは、この要求信号をＴＣＰアプリケーション１１ｂに対して転送する（Ｓ１１５）。

これに応じてＴＣＰアプリケーション１１ｂは、応答信号をＳＭＣ１３１ｂに送信する（Ｓ１１６）。ＳＭＣ１３１ｂは、クライアント側のＳＭＣ１３１ａに対して応答信号を送信する（Ｓ１１７）。ＳＭＣ１３１ａは、当該応答信号をＴＣＰアプリケーション１１ａに転送する（Ｓ１１８）。

その後、サーバ側のＴＣＰアプリケーション１１ｂから、要求信号に対応したウェブデータがＳＭＣ１３１ｂに送信される（Ｓ１１９）。ＳＭＣ１３１ｂは、受信したウェブデータをクライアント側のＳＭＣ１３１ａに送信する（Ｓ１２０）。ＳＭＣ１３１ａは、受信したウェブデータをＴＣＰアプリケーション１１ａに転送する（Ｓ１２１）。

続いて、図９を用いて、ハンドオーバの場合のシグナリングについて説明する。初期状態として、クライアント側のＴＣＰアプリケーション１１ａとクライアント側のＳＭＣ１３１ａとの間で第１のＴＣＰローカルセッションが確立され（Ｓ２０１）、ＳＭＣ１３１ａとサーバ側のＳＭＣ１３１ｂとの間で第１のＴＣＰ若しくはＵＤＰセッションが確立され（Ｓ２０２）、さらに、ＳＭＣ１３１ｂとサーバ側のＴＣＰアプリケーション１１ｂとの間で第１のＴＣＰローカルセッションが確立されている（Ｓ２０３）。

このような初期状態において、クライアントである移動端末１が移動してハンドオーバ処理を行い、他の通信網との間で２つめの通信リンクを実現するための新ＩＰアドレスの取得完了の通知を当該他の通信網との接続に利用されるインターフェイスにより受信したものとする（Ｓ２０４）。

クライアント側のＳＭＣ１３１ａは、新ＩＰアドレスの取得完了通知の受信に応じて新しい通信網を介した通信セッションへ変更するために、呼制御装置３に対してＲＥ−ＩＮＶＩＴＥ ＳＩＰ信号（再接続信号）を送信する（Ｓ２０５）。ここで、ＲＥ−ＩＮＶＩＴＥ ＳＩＰ信号には、クライアント側のＳＭＣ１３１ａのＴＣＰ接続ソースアドレス・ポート、ウィンドウサイズ、セグメントサイズ、応答信号等が含まれ、これらによって、通信の属性を変更することができる。この例では、ＩＰアドレスを新しく割り当てられたＩＰアドレスに変更する。呼制御装置３はこの信号を受信して、サーバ側のＳＭＣ１３１ｂに転送する（Ｓ２０６）。

サーバ側のＳＭＣ１３１ｂは、ＲＥ−ＩＮＶＩＴＥ ＳＩＰ信号を受信し、これに含まれる新しい通信の属性（ここでは、変更された新しいＩＰアドレス）を認識して、これに基づき応答信号を呼制御装置３に送信する（Ｓ２０７）。応答信号には、サーバ側のＳＭＣ１３１ｂのＴＣＰ接続ソースアドレス・ポート、ウィンドウサイズ、セグメントサイズ等が含まれている。呼制御装置３は、この応答信号を受信して、クライアント側のＳＭＣ１３１ａに転送する（Ｓ２０８）。このようにして、クライント側のＳＭＣ１３１ａとサーバ側のＳＭＣ１３１ｂとの間において、新ＩＰアドレスによる第２のＴＣＰ（ＵＤＰ）セッションが確立する（Ｓ２０９）。

第２のＴＣＰ（ＵＤＰ）セッションの確立に応じて、ＳＭＣ１３１ａ，１３１ｂのそれぞれは、対応表エントリを追加する（Ｓ２１０，Ｓ２１１）。その後に、サーバ側のＴＣＰアプリケーション１１ｂからＳＭＣ１３１ｂに対してウェブデータが送信されたものとする（Ｓ２１２）。

このとき、ＴＣＰアプリケーション１１ａ，１１ｂは、第１のＴＣＰローカルセッションが確立した状態をリモートセッションとして認識しているに過ぎないから、ＳＭＣ131間で行なわれている処理については認識しない。

ＳＭＣ１３１ｂは、第２のＴＣＰ（ＵＤＰ）セッションを利用してウェブデータを呼制御装置３を介さずにクライアント側のＳＭＣ１３１ａに対して直接送信する（Ｓ２１３）。サーバ側のＳＭＣ１３１ｂは、対応表の旧エントリを削除する（Ｓ２１４）。

クライアント側のＳＭＣ１３１ａは、受信したウェブデータをＴＣＰアプリケーション１１ａに対して送信する（Ｓ２１５）。クライアント側のＴＣＰアプリケーション１１ａは当該ウェブデータを受信し、所定の処理を行う。

クライアント側のＴＣＰアプリケーション１１ａからデータを送信する場合（Ｓ２１６）には、クライアント側のＳＭＣ１３１ａがこのデータを受信する。クライアント側のＳＭＣ１３１ａは、第２のＴＣＰ（ＵＤＰ）セッションを利用してサーバ側のＳＭＣ１３１ｂに当該データを送信する（Ｓ２１７）。クライアント側のＳＭＣ１３１ａは、対応表の旧エントリを削除する（Ｓ２１８）。[J8]

サーバ側のＳＭＣ１３１ｂは、受信したデータをＴＣＰアプリケーション１１ｂに対して送信する（Ｓ２１９）。サーバ側のＴＣＰアプリケーション１１ｂは当該データを受信し、所定の処理を行う。

続いて、ＳＭＣ間でデータ通信を行っている場合に、移動端末が移動して通信切断状態に至ったときのデータ転送処理について、図１０に示すシーケンス図を用いて説明する。ＴＣＰ通信には、本来信頼性があるが、移動端末の移動により通信切断の状態にいたった場合には、ＴＣＰの送信バッファ内には、未送信のデータセグメントと、正常に送信されたデータセグメントとが混在した状態で格納され、SMCではどのデータセグメントまで正常に送信されたかを判定することができない。このため、正常に送信されたデータセグメントまでも再度送信してしまう不具合が発生し、これにより、最終的にＴＣＰアプリケーションが受信するデータが元々送信されたものと異なってしまう場合がある（即ち、データ量が増減してしまう）。また、ＳＭＣを用いた通信においては、ＳＭＣの送信バッファのデータをＴＣＰの送信バッファに転送して通信相手に送信するが、再送の発生を考慮すると、ＴＣＰの送信バッファへの転送したデータをＳＭＣの送信バッファから転送と同時に破棄するべきではない。しかしながら、ＳＭＣの送信バッファに過去のデータの全てを格納しておくことは、ＳＭＣの送信バッファに割り当てられる記憶領域は可能な限り少ない方が好ましいことから困難である。本発明では、以下に示す通信方法により、これらの問題を解決した。

サーバ側のＳＭＣ１３１ｂから呼制御装置３を介さずにクライアント側のＳＭＣ１３１ａに対して例えばそれぞれ1024バイトからなるデータセグメント（１）（２）・・・（Ｋ）が連続的にＴＣＰ又はＵＤＰにより送信される（Ｓ３０１〜Ｓ３０３）。なお、データセグメントに含まれるデータ量を定めるセグメントサイズは、図８で説明した初期シグナリングにおいて指定することができる。

クライント側のＳＭＣ１３１ａはこれらのデータセグメント（１）〜（Ｋ）を受信して、最後に受信が成功したデータセグメント（Ｋ）を示す情報をＳＩＰ−ＩＮＦＯ信号に含ませて、このＳＩＰ−ＩＮＦＯ信号を呼制御装置３に対して送信する（Ｓ３０４）。このとき、クライアント側のＳＭＣ１３１ａは、予め定められたウィンドウサイズ数のデータセグメントを受信した場合に、ＡＣＫ信号（データの正常受信を示す信号）を含むＳＩＰ−ＩＮＦＯ信号を送信する。呼制御装置３は、当該ＳＩＰ−ＩＮＦＯ信号を受信して、サーバ側のＳＭＣ１３１ｂに対して転送する（Ｓ３０５）。なお、このウィンドウサイズは、図８及び図９で説明したシグナリングにおいて指定することができる。

サーバ側のＳＭＣ１３１ｂは、転送されたＳＩＰ−ＩＮＦＯ信号を受信して、クライアント側のＳＭＣ１３１ａが受信した最後のデータセグメント（Ｋ）を認識して、サーバ側の送信バッファ内に格納されたデータセグメント（１）〜（Ｋ）を破棄することが可能となる。サーバ側のＳＭＣ１３１ｂは、データセグメント（１）〜（Ｋ）の破棄の後、応答信号を呼制御装置３に送信する（Ｓ３０６）。呼制御装置３は、当該応答信号を受信し、クライアント側のＳＭＣ１３１ａに対して転送する（Ｓ３０７）。クライアント側のＳＭＣ１３１ａは、応答信号を受信する。

その後、サーバ側のＳＭＣ１３１ｂは、データの送信を再開し、データセグメント（Ｋ＋１），（Ｋ＋２）を送信する（Ｓ３０８，Ｓ３０９）。その後、移動端末１の移動によって通信切断の状態に至り、データセグメント（Ｋ＋３），（Ｋ＋４）の送信が途中で切断されたものとする（Ｓ３１０，Ｓ３１１）。この場合に、クライアント側のＳＭＣ１３１ａは、再接続信号であるＲｅ−ＩＮＶＩＴＥ信号中に、移動先の通信網により新たに割り当てられた新ＩＰアドレスに加えて、最後に受信に成功したデータセグメント（Ｋ＋２）を示す情報を含ませて当該Ｒｅ−ＩＮＶＩＴＥ信号を呼制御装置３に送信する（Ｓ３１２）。呼制御装置３は、当該Ｒｅ−ＩＮＶＩＴＥ信号を受信して、サーバ側のＳＭＣ１３１ｂに転送する（Ｓ３１３）。

サーバ側のＳＭＣ１３１ｂは、Ｒｅ−ＩＮＶＩＴＥ信号を受信して、データセグメント（Ｋ＋２）まで正常に送信されたことを認識し、送信バッファ内に格納されたデータセグメント（Ｋ＋１），（Ｋ＋２）を破棄することができる。そして、サーバ側のＳＭＣ１３１ｂは、データの送信を再開し、データセグメント（Ｋ＋３），（Ｋ＋４）を送信する（Ｓ３１４，Ｓ３１５）。

このように、図１０に示す通信方法によれば、受信側のＳＭＣ１３１が予め定められた量のデータを受信したと判定した場合に、最後に受信に成功したデータを識別する情報を送信側のＳＭＣ１３１に対して送信するようにしたので、送信側のＳＭＣ１３１は、送信に成功したデータまでを送信バッファから破棄することが可能となる。さらに、最後に受信に成功したデータを識別する情報を、再接続時に、受信側のＳＭＣ１３１から送信側のＳＭＣ１３１に対して送信するようにしたので、送信側のＳＭＣ１３１は、送信に成功したデータの後に送信すべきデータを送信することが可能となる。なお、図１０に示す例では、データセグメント数を管理するようにしたが、これに限らずバイト数等のデータ量に関する情報を管理するようにしてもよい。

続いて、同一の課題について図１０に示す通信方法とは別の方式により解決する通信方法を、図１１のシーケンス図及び図１２の説明図を用いて説明する。

図１１に示されるように、サーバ側のＳＭＣ１３１ｂから呼制御装置３を介さずにクライアント側のＳＭＣ１３１ａに対してデータセグメント（１）（２）・・・（Ｋ＋２）が連続的にＴＣＰにより送信される（Ｓ４０１〜Ｓ４０５）。クライント側のＳＭＣ１３１ａはこれらのデータセグメント（１）〜（Ｋ＋２）を受信するが、ＡＣＫ信号はサーバ側のＳＭＣ１３１ｂに対して送信しない。

このとき、所定のアルゴリズムに従い、送信バッファ内のデータセグメントを順次廃棄する。図１２（ａ）では、サーバ側のＳＭＣ１３１ｂの送信バッファ（以下、単に「ＳＭＣ送信バッファ」とする）にデータセグメント（１）〜（２０）が格納されている。このうち、ＴＣＰによって規定されるトランスポート層上の送信バッファ（以下、単に「ＴＣＰ送信バッファ」とする）に、データセグメント（１）〜（１０）までが書き込まれている。ＴＣＰ送信バッファに格納されたデータセグメントが正常に送信され、送信した相手方からＴＣＰによるＡＣＫ信号を受信した場合には、ＴＣＰ送信バッファから、正常送信されたデータセグメントが削除される。

このような状態で、ＳＭＣ送信バッファより、データセグメント（１１）をＴＣＰ送信バッファに対して書き込もうとしたとしても、ＴＣＰ送信バッファは既にフルの状態であるため、書き込みに失敗する。ＳＭＣ１３１ｂは、ＳＭＣ送信バッファからＴＣＰ送信バッファへの書込みに失敗すると、ＴＣＰ送信バッファの容量が１０個のデータセグメント分であることを把握しているため、これによりＴＣＰ送信バッファからは最初に書き込んだデータセグメント１を含むデータセグメント１０までが未だクライアント側のＳＭＣ１３１ａに対して正常に送信されていないことを認識する。この場合に、ＳＭＣ１３１ｂは、ＳＭＣ送信バッファに格納されたデータセグメント（１）〜（１０）までは、再送の可能性があるため、破棄しない。ここで、更にクライアント側のTCP受信バッファに到達したセグメントの全てをクライアント側のSMCが取得できることが保証されていない場合は、クライアント側TCP受信バッファ内のセグメントも再送要求の対象となる可能性がある。この場合、例えばクライアント側のTCP受信バッファ容量が５セグメント分である場合は、サーバ側のTCP送信バッファ容量の１０を加え、１５セグメント分が再送要求対象と考えることで解決可能である。この場合１６個目のセグメントが書き込みできた時点で１個目のセグメントは確実にクライアント側のSMCに到達していることになる。なお、クライアント側のTCP受信バッファサイズは、図８、図９に示すシグナリングで通知することが可能であ[家入9]る。[J10][k11]

他方、図１２（ｂ）で示されるように、ＳＭＣ１３１ｂがＳＭＣ送信バッファからデータセグメント（１１）をＴＣＰ送信バッファに書き込むことができた場合には、そのデータセグメント（１１）の分だけＴＣＰ送信バッファに空きが生じていた、即ち、その空き分と同一のデータ量のデータセグメント（１）が既にクライアント側のＳＭＣ１３１ａに正常送信されたことを認識することができる。この場合には、ＳＭＣ１３１ｂは、正常に送信されたデータセグメント（１）を、ＳＭＣ送信バッファから破棄することができる。

このような方式により、正常送信されたかどうかを確認できるのは、ＴＣＰがデータの送信先よりＡＣＫを受信して初めて正常送信が完了したものと判定してＴＣＰ送信バッファからデータを削除することを規定しているからである。即ち、この方式は、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに適用しうる。

その後、サーバ側のＳＭＣ１３１ｂは、データの送信を再開し、データセグメント（Ｋ＋３），（Ｋ＋４）を送信するが（Ｓ４０６，Ｓ４０７）、移動端末１の移動によって通信切断の状態に至り、データセグメント（Ｋ＋３），（Ｋ＋４）の送信が途中で切断されたものとする（Ｓ４０６，Ｓ４０７）。この場合に、クライアント側のＳＭＣ１３１ａは、再接続信号であるＲｅ−ＩＮＶＩＴＥ信号中に、移動先の通信網により新たに割り当てられた新ＩＰアドレスに加えて、最後に受信に成功したデータセグメント（Ｋ＋２）を示す情報を含ませて当該Ｒｅ−ＩＮＶＩＴＥ信号を呼制御装置３に送信する（Ｓ４０８）。呼制御装置３は、当該Ｒｅ−ＩＮＶＩＴＥ信号を受信して、サーバ側のＳＭＣ１３１ｂに転送する（Ｓ４０９）。

サーバ側のＳＭＣ１３１ｂは、Ｒｅ−ＩＮＶＩＴＥ信号を受信して、データセグメント（Ｋ＋２）まで正常に送信されたことを認識し、データの送信を再開し、データセグメント（Ｋ＋２）の次に送信すべきデータセグメント（Ｋ＋３），（Ｋ＋４）を送信する（Ｓ４１０，Ｓ４１１）。

このように、図１１に示す通信方法によれば、ＴＣＰ送信バッファへのデータの書き込み可能か否かに応じて、データの送信が成功したかどうかを判定するようにしたので、送信側のＳＭＣ１３１は、送信に成功したデータまでを送信バッファから破棄することが可能となる。さらに、最後に受信に成功したデータを識別する情報を、再接続時に、受信側のＳＭＣ１３１から送信側のＳＭＣ１３１に対して送信するようにしたので、送信側のＳＭＣ１３１は、送信に成功したデータの後に送信すべきデータを送信することが可能となる。

本発明にかかる通信方法が適用される無線通信システムの構成図である。 本発明にかかる移動端末の構成を示すブロック図である。 本発明にかかる移動端末の具体的なソフトウェア構成を示すブロック図である。 本発明にかかる通信方法を実現するための接続方式を示す説明図である。 本発明にかかる通信方法を実現するための接続方式を示す説明図である。 本発明にかかる通信システムにおけるネットワーク接続形態を示す図である。 本発明にかかる通信システムにおけるネットワーク接続形態を示す図である。 本発明にかかる通信方法を示すシーケンス図である。 本発明にかかる通信方法を示すシーケンス図である。 本発明にかかる通信方法を示すシーケンス図である。 本発明にかかる通信方法を示すシーケンス図である。 本発明にかかる通信方法を説明するための説明図である。 従来の通信方法を説明するための説明図である。

符号の説明

１ 移動端末
３ 呼制御装置
１１ ＴＣＰアプリケーション
１２ ＵＤＰアプリケーション
１０１ 通信アプリケーション処理部
１０２ セッション・モビリティ制御部
１０３ 呼制御部
１０４ インターフェイス選択制御部
１０５ 通信インターフェイス群
１３１ セッション・モビリティコントローラ

Claims (14)

1. 複数の通信網において無線通信可能な移動端末であって、
   通信相手との間で通信を行なう通信セッションを確立するために必要な情報を交換するコントローラと、
   交換した必要情報に基づいて、前記通信セッションを確立し、確立された通信セッションにより通信相手との間で通信を実行する通信手段とを備え、
   前記コントローラは、前記呼制御装置を介して通信相手との間で呼制御を実行することによって、前記必要情報を取得する移動端末。
2. 前記コントローラは、通信アプリケーションの要求に応じて、当該通信アプリケーションとの間でローカルセッションを確立することを特徴とする請求項１記載の移動端末。
3. 前記コントローラは、ハンドオーバを行なうときに、情報交換を実行し、新たな通信セッションに移行することを特徴とする請求項１記載の移動端末。
4. 前記コントローラは、通信相手からデータを正常に受信したことを示す信号を、[k1]通信相手に対して送信することを特徴とする請求項１記載の移動端末。
5. 前記コントローラは、通信相手との通信セッションが切断された場合に、正常に受信したデータを特定する情報を、[k2]通信相手に対して送信することを特徴とする請求項１〜４いずれかに記載の移動端末。
6. 前記コントローラは、コントローラ上の送信バッファから、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに対してデータを書き込むことができたか否かに応じて、正常送信済みのデータの有無について判定し、正常送信済みのデータがあると判定した場合には、そのデータについて当該コントローラ上の送信バッファから破棄することを特徴とする請求項１記載の移動端末。
7. 前記移動端末のコントローラは、前記通信相手のコントローラとの間で前記通信セッションを確立するために必要な情報を交換し、かつ、確立された通信セッションにより通信を実行することを特徴とする請求項１〜６いずれかに記載の移動端末。
8. 複数の通信網において無線通信可能な第１の移動端末と、第２の移動端末間の通信方法であって、
   前記第１の移動端末と前記第２の移動端末との間で、[k3]通信を行なう通信セッションを確立するために必要な情報を呼制御装置を介して交換する情報交換ステップと、
   交換した必要情報に基づいて、前記通信セッションを確立するセッション確立ステップと、
   確立された通信セッションにより前記第１の移動端末と前記第２の移動端末との間で前記呼制御装置を介さずに通信を実行する通信実行ステップとを備えた通信方法。
9. 前記情報交換ステップは、通信アプリケーションの要求に応じて、当該通信アプリケーションとの間でローカルセッションを確立するコントローラによって実行することを特徴とする請求項８記載の通信方法。
10. 前記情報交換ステップは、ハンドオーバを行なうときに実行し、新たな通信セッションに移行することを特徴とする請求項８記載の通信方法。
11. 前記第１の移動端末が、前記第２の移動端末からの正常受信を示す信号を、前記第２の移動端末に対して送信するステップと、
    前記第２の移動端末が、前記正常受信を示す信号に応じて、送信バッファのデータを破棄するステップをさらに備えたことを特徴とする請求項８記載の通信方法。
12. 前記第１の移動端末が、通信セッションが切断された場合に、正常に受信したデータを特定する情報を、前記第２の移動端末に対して送信するステップと、
    前記第２の移動端末が、前記正常に受信したデータを特定する情報に基づいて、送信バッファのデータを破棄するステップとをさらに備えたことを特徴とする請求項８〜１１いずれかに記載の通信方法。
13. 前記コントローラ上の送信バッファから、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに対してデータを書き込むことができたか否かに応じて、正常送信済みのデータの有無について判定し、正常送信済みのデータがあると判定した場合には、そのデータについて当該コントローラ上の送信バッファから破棄するステップをさらに備えたことを特徴とする請求項８記載の通信方法。
14. 前記情報交換ステップ、セッション確立ステップ及び通信実行ステップは、前記第１の移動端末のコントローラと前記第２の移動端末のコントローラ間で実行されることを特徴とする請求項８〜１３いずれかに記載の通信方法。
    

Images