WO2007139161A1

WO2007139161A1 - 移動端末及び通信方法

Info

Publication number: WO2007139161A1
Application number: PCT/JP2007/061017
Authority: WO
Inventors: Naoya Seta; Haruya Miyajima; Hideki Hayashi; Teruya Fujii
Original assignee: Softbank Bb Corp.
Priority date: 2006-05-31
Filing date: 2007-05-30
Publication date: 2007-12-06
Also published as: US20100015980A1; EP2034671A1; JP2007324788A; CN101455117A; EP2034671A4

Abstract

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

Description

明細書

移動端末及び通信方法

技術分野

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

背景技術

[0002] 近年、無線通信技術の発展により、 W— CDMAなどのセルラーネットワークといつた代表的な通信メディアに加えて、例えば無線 LAN (Local Area Network)や PHS ( Personal Handyphone System)ネットワークといった他の通信メディアも普及している。このため、移動先の電波条件やユーザの必要とする通信条件に応じてこれらの通信方式の中の 1つを自在に選択して通信することができるようになった。

[0003] 図 13は、モパイル IPを用いた通信方法を説明するための説明図である。図 13は、移動端末 laと移動端末 lb間で通信を行なう場合を示している。通信網 202上に設けられたセンターサーバであるホームエージェント（HA) 201に、ホームアドレス（Ho A) 206と気付けアドレス（CoA) 205との対応関係が登録されている。ホームアドレス 206は、各移動端末に割り当てられ、移動しても変更されることのないアドレスである。気付けアドレス 205は、移動端末が移動先において利用することのできる通信メディァ (ネットワークカード）に割り当てられ、移動に伴って変更されるアドレスである。

[0004] 図 13に示されるように、移動端末 laが通信網 203から他の通信網 204に移動したときには、ホームエージェント 201において、この移動端末 laに対するホームアドレス 206は不変である力気付けアドレス 205は、気付けアドレス 205aから気付けァドレス 205bに変更される。移動端末 lbから送信されたデータパケットは、ホームエージヱント 201力 S受け取り、このホームエージェント 201から図示しないフォーリンエージヱントに転送され、フォーリンエージェントは、これを移動端末 laに送信する。

[0005] このように、不変のホームアドレス 206と可変の気付けアドレス 205とを関連付けてホームエージェント 201に登録しておくことにより、この登録された移動端末 laと通信する相手方端末は、この移動端末がどこへ移動しょうとも、ホームエージェント 201においてホームアドレス 206と関連付けられた気付けアドレス 205を参照すれば、当該移動端末との間の当該通信をそのまま継続させることができる。

特許文献 1 :特開 2006— 80981号公報

特許文献 2：特開 2001— 237869号公報

発明の開示

発明が解決しょうとする課題

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

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

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

課題を解決するための手段

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

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

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

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

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

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

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

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

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

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

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

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

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

図面の簡単な説明

[0022] [図 1]本発明にかかる通信方法が適用される無線通信システムの構成図である。

[図 2]本発明にかかる移動端末の構成を示すブロック図である。

[図 3]本発明にかかる移動端末の具体的なソフトウェア構成を示すブロック図である。

[図 4]本発明にかかる通信方法を実現するための接続方式を示す説明図である。

[図 5]本発明にかかる通信方法を実現するための接続方式を示す説明図である。

[図 6]本発明にかかる通信システムにおけるネットワーク接続形態を示す図である。

[図 7]本発明にかかる通信システムにおけるネットワーク接続形態を示す図である。

[図 8]本発明にかかる通信方法を示すシーケンス図である。

[図 9]本発明にかかる通信方法を示すシーケンス図である。

[図 10]本発明に力かる通信方法を示すシーケンス図である。 [図 11]本発明にかかる通信方法を示すシーケンス図である。

[図 12A]本発明にかかる通信方法を説明するための説明図である。

[図 12B]本発明にかかる通信方法を説明するための説明図である。

[図 13]従来の通信方法を説明するための説明図である。

符号の説明

[0023] 1 移動端末

3 呼制御装置

11 TCPアプリケーション

12 UDPアプリケーション

101 通信アプリケーション処理部

102 セッション.モビリティ制御部

103 呼制御部

104 インターフェイス選択 $Μ卸咅

105 通信インターフェイス群

131 セッション'モビリティコントローラ

発明を実施するための最良の形態

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

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

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

[0027] さらに、パケット交換網 2には、無線回線交換網 4a， 4b、無線パケット交換網（無線 LAN) 5a, 5b, 5c、 IP電話網 6が接続されている。無線回線交換網 4a等は、ゲートウェイ装置 41a等を介して当該パケット交換網 2と接続され、移動端末 1と通信可能な基地局 42a等を備えている。無線パケット交換網 5a等は、ルータ 51a等を介して当該パケット交換網 2と接続され、移動端末 1と通信可能なアクセスポイント 52a等を備えている。 IP電話網 6は、ルータ 61を介してパケット交換網 2と接続されている。移動端末 1が各通信網間を移動する場合には、ハンドオーバが実行される。

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

[0029] 図 2は、本発明に力かる移動端末の構成を示すブロック図である。図に示されるように、移動端末 1は、通信アプリケーション処理部 101、セッション'モビリティ制御部 10 2、呼制御部 103、インターフェイス選択制御部 104、通信インターフェイス群 105を備えている。

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

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

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

[0033] 呼制御部 103は、セッション'モビリティ制御部 102内に設けられ、呼制御装置 3との間で呼制御に関する処理を実行する。

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

[0035] 通信インターフェイス群 105には、例えば無線回線交換網 4用のインターフェイスである CSR— IF (Circuit Switch Radio Interface)や、無線パケット交換網 5用のインタ一フェイスである PSR— IF (Packet Switch Radio Interface)等、各種の通信網に対応したインターフェイスが含まれる。この通信インターフェイス群 105に含まれる通信ィンターフェイスは、物理ネットワークインターフェイス及びこの物理ネットワークインターフェイスに対応するデバイスドライバ、ダイアルアップ機能等の網制御機能 (NCU) や基本プロトコルスタック (TCP/UDP/IP)等を備えてレ、る。

[0036] 図 3は、本発明に力かる移動端末の具体的なソフトウェア構成を示すブロック図である。アプリケーション部 11に対応するソフトウェアには、 TCPベースのクライアントァプリケーシヨン (以下、単に「TCPアプリケーション」とする場合がある） 11と、 UDPベースのクライアントアプリケーション（以下、単に「UDPアプリケーション」とする場合がある） 12が含まれる。 UDPアプリケーション 12には、プレゼンスソフトウェア 121、 IM ( Instant Messaging)ソフトウェア 122、 PTT (Push To Talk)ソフトウェア 123、 Videoソフトウェア 124、 VoIP (Voice Over Internet Protocol)ソフトウェア 125が含まれ、リアルタイム通信が実現される。

[0037] ミドルウェア 13には、セッション'モビリティコントローラ（以下、単に「SMS」とする場合がある） 131と SIP処理プログラム 132が含まれる。 SMS131は、図 2のセッション' モビリティ制御部 102に相当するミドルウェアからなる通信用コンピュータプログラムである。また、 SIP処理プログラム 132が呼制御部 103に相当する。 SMC131とデータのやり取りが可能にダイアラー 14が設けられている。ダイアラー 14は、 CCS (Cellul ar CS Network)インターフェイス 17が設けられている。

[0038] OS (Operating System)である基本ソフトウェア 15には、 TCP/IP処理プログラム 1 51、 UDPZIP処理プログラム 152及びインターフェイス選択及びハンドオーバ制御プログラム 153が含まれる。インターフェイス選択及びハンドオーバ制御プログラム 15 3がインターフェイス選択制御部 104に相当する。通信インターフェイス 16には、 WiF iインターフェース 161、 CPS (Cellular PS Network)インターフェイス 162、 PHSインターフェイス 163、 Wireインターフェイス 164、 WiMAXィンターフェィス165等が含まれる。

[0039] このようなソフトウェア構成において、 SMC131は、アプリケーション 11と TCP/IP 処理プログラム 151や UDP/IP処理プログラム 152の間に設けられている。また、 S MC131は、 TCP/IP処理プログラム 151や UDP/IP処理プログラム 152との間でデータのやり取りを実行する。ミドルウェア 13と基本ソフトウェア 15間は、ソケットインターフェイスを介してデータのやり取りが実行される。 SMC131は、インターフェイス選択及びハンドオーバ制御プログラム 153との間で IPS (Inter-Process Communicati on)を実行する。 SIP処理プログラム 132は、 UDP/IP処理プログラム 152を利用して、通信相手との間でシグナリングのやり取りを実行する。

[0040] 続いて、図 4を用いて、本発明にかかる通信方法を実現するための接続方式の一例として、 ALG (Application Level Gateway)方式について説明する。図 4では、クライアントとして機能する移動端末 laと、サーバとして機能する移動端末 Idとの間で、パケット交換網 2を含む各種の通信網を介して通信が行なわれる場合を示している。

[0041] 移動端末 laの呼制御部 132は、 UDP処理プログラム 1521及び IP処理プログラム 1512を介して呼制御装置 3との間で SIPを利用したシグナリングを行レ、、移動端末間で通信を開始若しくは再開する場合に、通信セッションの確立のために必要な情報の交換を呼制御装置 3を介して実行する。移動端末 la, Idの TCPアプリケーション 11は、それぞれ SMC131を認識せずに、相互に通信しているものとして通常の処理を行っている。

[0042] また、移動端末 laのウェブブラウザ等の TCPアプリケーション 11は、 TCP処理プログラム 1511や IP処理プログラム 1512を介して SMC131との間で、アプリケーションデータ D1の送受信を行なう。このとき、 TCPアプリケーション 11では、ローカルァドレスにプロキシ設定を行なう必要がある。 SMC131は、アドレス対応表 1311を備えており、これに基づいて SIPと URI間でアドレス変換等を実行し、 TCP処理プログラム 1 511や IP処理プログラム 1512を介して、通信相手である移動端末 1 dと通信を行なう。移動端末 Idも、移動端末 laと同様の処理を実行する。

[0043] 移動端末 1内でのロー力ノレ TCPコネクションは、移動による切断が発生しないが、特に SMC131間で TCP通信を行う場合は、通信網の切替時、即ちハンドオーバ処理時に通信状態が切断される。図 4に示す ALG方式では、 SMC131がアプリケーシヨンレベルで実装が可能であるため、比較的に容易に実現できる。ただし、 SMC1 31内に ΗΤΤΡ/FTP/POP/Telnet等、アプリケーションプロトコル毎に該当モジユールを実装しなければならなレ、。

[0044] 図 5は、他の接続方式である TCP over UDP方式を示す説明図である。移動端末 1 aの呼制御部 132は、 UDP処理プログラム 1521及び IP処理プログラム 1522を介して呼制御装置 3との間で SIPを利用したシグナリングを行レ、、 TCPの再接続や再送制御等を行う。

[0045] また、移動端末 laの TCPアプリケーション 11は、 TCP処理プログラム 1511や Virt ual IP処理プログラム 1513を介して SMC131との間で、 TCP/IPパケットデータ D 3の送受信を行なう。このとき、 TCPアプリケーション 11では、仮想 IFアドレスにプロキシ設定を行なう必要がある。 SMC131は、アドレス対応表 1311を備えており、これに基づいてアドレス変換等を実行し、 UDP処理プログラム 1521や IP処理プログラム 1522を介して、 TCP/IPパケットデータ D3を UDP/IPでカプセル化して、通信相手である移動端末 Idと通信を行なう。移動端末 laと移動端末 Id間は、外部 UDPセッションが確立する力通信網を移動した場合のアドレス変更は SIPモビリティで対応する。移動端末 Idも、移動端末 laと同様の処理を実行する。

[0046] 図 5に示す方式は、 SMC131内にアプリケーションプロトコル毎に実装する必要性がないという利点を有する。

[0047] 続いて、図 6を用いて、本発明に力かる通信システムにおけるネットワーク接続形態を説明する。図 6に示す各構成は、図 1や図 2において説明したものと同様であるため説明を省略する。この例では、移動端末 laと移動端末 Idのそれぞれにリソース 10 が設けられおり、移動端末 laと移動端末 Idとが通信状態にある。移動端末 laは無線パケット交換網 5bに収容され、移動端末 Idは IP電話網 6に収容された状態にある力移動して他の通信網に収容されうる。

[0048] 図 7に示すネットワーク接続形態では、移動端末 laにリソース 10aが設けられ、パケット交換網 2とルータ 71cを介して接続されたインタネット網 7cに接続されたゥヱブサーバ 72にリソース 10bが設けられている。移動端末 laは無線パケット交換網 5bに収容された状態にある力移動して他の通信網に収容されうる。中継装置 lcは、ルータ 61を介してパケット交換網 2に接続された有線網 6に収容されている。移動端末 laは、この中継装置 lcを介してウェブサーバ 72と通信することができ、リソース 10bのデータを取得することができる。

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

[0050] 最初に、クライアント側の TCPアプリケーション 11a (ここでは、ウェブブラウザ）は、クライアント側の SMC131aとの間で TCPローカルセッションを確立する（S101)。次に、 TCPアプリケーション 11aは、 SMC131aに対して所定の URLのデータを要求する（S102)。

[0051] SMC131aの呼制御部 103aは、受け取った URLを SIPに変換する（S103)。さらに、 SMC131aの呼制御部 103aは、対応表のエントリを作成する（S104)。例えば、 TCP接続ソースアドレス 'ポートやウィンドウサイズやセグメントサイズを対応表に書き込む。

[0052] SMC 131 aの呼制御部 103aは、 INVITEメッセージを呼制御装置 3に対して送信する（S105)。ここで、 INVITEメッセージは、 SIP上での接続要求であり、この INVI TEメッセージ中には、 SMC131aと SMC131b (ここでは、ウェブサーバ）間で直接通信を行なうための通信セッションを確立するために必要な情報が含まれる。通信セッシヨンを確立するために必要な情報としては、クライアント側の SMC131aの TCP 接続ソースアドレス 'ポート、ウィンドウサイズ、セグメントサイズがある。

[0053] 呼制御装置 3は、受信した INVITEメッセージを通信相手方の移動端末 1にインストールされたサーバ側の SMC131bに送信する（S106)。このとき、呼制御装置 3は、各移動端末の位置登録管理を行なっているため、その位置登録情報に基づき、当該 INVITEメッセージを通信相手方の移動端末 1が収容された通信網を介して当該通信相手方の移動端末 1に対して送信することができる。

[0054] サーバ側の SMC131bは、 INVITEメッセージを受信し、少なくとも通信セッション（ TCP/UDPセッション）の確立に必要な情報を所定の記憶領域に格納しておく。 S MC131bの呼制御部 103bは、さらに INVITEメッセージの受信に応じて対応表のエントリを作成する（S107)。さらに、 SMC131bとサーバ側の TCPアプリケーション 1 lbとの間で、 TCPローカルセッションを確立する（S108)。

[0055] その後、 SMC131bの呼制御部 103bは、呼制御装置 3に対して、サーバ側の SM C131bの TCP接続ソースアドレス 'ポート、ウィンドウサイズ、セグメントサイズ等の通信セッションの確立に必要な情報を含む応答信号を送信する（S109)。呼制御装置 3は、応答信号を受信して、クライアント側の SMC131aに送信する（S110)。クライアント側の SMC131aは応答信号を受信して、少なくとも通信セッションの確立に必要な情報を所定の記憶領域に格納しておく。

[0056] 次に、 SMC131aと SMC131b間で直接に TCP若しくは UDPのセッションを確立する（Sl l l)。このように、本発明にかかる通信方法では、最初に、 SMC131a, の呼制御部 103a， bの間で呼制御装置 3を介して通信を行なうことにより通信セッションの確立に必要な情報を取得し、取得した情報に基づいて、 SMC131aと SMC131b 間で直接、呼制御装置 3を介さずに、通信セッションを確立する。

[0057] そして、 SMC131a及び SMC131bのそれぞれにおいて対応表を作成する（S112 , S113)。

[0058] SMC131afま、 SMC131bに対して、 S102におレヽて TCPアプリケーション 1 la力、ら受信した要求信号と同じ内容の要求信号を送信する（SI 14)。 SMC131bは、この要求信号を TCPアプリケーション 1 lbに対して転送する（SI 15)。

[0059] これに応じて TCPアプリケーション l ibは、応答信号を SMC131bに送信する（S1

16)。 SMC131bは、クライアント側の SMC131aに対して応答信号を送信する（S1

17)。 SMC131aは、当該応答信号を TCPアプリケーション 1 laに転送する（S118)

[0060] その後、サーバ側の TCPアプリケーション l ibから、要求信号に対応したウェブデータが SMC131bに送信される（S119)。 SMC131bは、受信したウェブデータをクライアント側の SMC131aに送信する（S120)。 SMC131aは、受信したウェブデータを TCPアプリケーション 11aに転送する（S121)。

[0061] 続いて、図 9を用いて、ハンドオーバの場合のシグナリングについて説明する。初期状態として、クライアント側の TCPアプリケーション 11aとクライアント側の SMC131a との間で第 1の TCPローカルセッションが確立され（S201)、 SMC131aとサーバ側の SMC131bとの間で第 1の TCP若しくは UDPセッションが確立され（S202)、さらに、 SMC131bとサーバ側の TCPアプリケーション l ibとの間で第 1の TCPローカルセッションが確立されてレ、る (S203)。

[0062] このような初期状態において、クライアントである移動端末 1が移動してハンドォーバ処理を行い、他の通信網との間で 2つめの通信リンクを実現するための新 IPァドレスの取得完了の通知を当該他の通信網との接続に利用されるインターフェイスにより受信したものとする（S204)。

[0063] クライアント側の SMC131aは、新 IPアドレスの取得完了通知の受信に応じて新しい通信網を介した通信セッションへ変更するために、呼制御装置 3に対して RE— IN VITE SIP信号（再接続信号）を送信する（S205)。ここで、 RE_INVITE SIP信号には、クライアント側の SMC131aの TCP接続ソースアドレス 'ポート、ウィンドウサィズ、セグメントサイズ、応答信号等が含まれ、これらによって、通信の属性を変更すること力 Sできる。この例では、 IPアドレスを新しく割り当てられた IPアドレスに変更する。呼制御装置 3はこの信号を受信して、サーバ側の SMC131bに転送する（S206)。

[0064] サーバ側の SMC131bは、 RE_INVITE SIP信号を受信し、これに含まれる新しい通信の属性 (ここでは、変更された新しい IPアドレス）を認識して、これに基づき応答信号を呼制御装置 3に送信する（S207)。応答信号には、サーバ側の SMC13 lbの TCP接続ソースアドレス 'ポート、ウィンドウサイズ、セグメントサイズ等が含まれている。呼制御装置 3は、この応答信号を受信して、クライアント側の SMC131aに転送する（S208)。このようにして、クライント側の SMC131aとサーバ側の SMC131b との間において、新 IPアドレスによる第 2の TCP (UDP)セッションが確立する（S209

[0065] 第 2の TCP (UDP)セッションの確立に応じて、 SMC131a, 131bのそれぞれは、対応表エントリを追加する（S210, S211)。その後に、サーバ側の TCPアプリケーシヨン l ibから SMC131bに対してウェブデータが送信されたものとする（S212)。

[0066] このとき、 TCPアプリケーション 11a, 1 lbは、第 1の TCPローカルセッションが確立した状態をリモートセッションとして認識しているに過ぎないから、 SMC131間で行なわれてレ、る処理にっレ、ては認識しなレ、。

[0067] SMC131bは、第 2の TCP (UDP)セッションを利用してウェブデータを呼制御装置 3を介さずにクライアント側の SMC131aに対して直接送信する（S213)。サーバ側の SMC131bは、対応表の旧エントリを削除する（S214)。

[0068] クライアント側の SMC131aは、受信したウェブデータを TCPアプリケーション 11a に対して送信する（S215)。クライアント側の TCPアプリケーション 11aは当該ウェブデータを受信し、所定の処理を行う。

[0069] クライアント側の TCPアプリケーション 11aからデータを送信する場合（S216)には、クライアント側の SMC131aがこのデータを受信する。クライアント側の SMC131a は、第 2の TCP (UDP)セッションを利用してサーバ側の SMC131bに当該データを送信する（S217)。クライアント側の SMC131aは、対応表の旧エントリを削除する（S 218)。

[0070] サーバ側の SMC131bは、受信したデータを TCPアプリケーション l ibに対して送信する（S219)。サーバ側の TCPアプリケーション l ibは当該データを受信し、所定の処理を行う。

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

[0072] サーバ側の SMC131bから呼制御装置 3を介さずにクライアント側の SMC131aに対して例えばそれぞれ 1024バイトからなるデータセグメント（1) (2) · · · (K)が連続的に TCP又は UDPにより送信される（S301〜S303)。なお、データセグメントに含まれるデータ量を定めるセグメントサイズは、図 8で説明した初期シグナリングにおいて指定することができる。

[0073] クライント側の SMC131aはこれらのデータセグメント（1)〜（K)を受信して、最後に受信が成功したデータセグメント (Κ)を示す情報を SIP— INFO信号に含ませて、この SIP— INFO信号を呼制御装置 3に対して送信する（S304)。このとき、クライアント側の SMC131aは、予め定められたウィンドウサイズ数のデータセグメントを受信した場合に、 ACK信号 (データの正常受信を示す信号)を含む SIP— INFO信号を送信する。呼制御装置 3は、当該 SIP— INFO信号を受信して、サーバ側の SMC131 bに対して転送する（S305)。なお、このウィンドウサイズは、図 8及び図 9で説明したシグナリングにおいて指定することができる。

[0074] サーバ側の SMC131bは、転送された SIP— INFO信号を受信して、クライアント側の SMC131aが受信した最後のデータセグメント (K)を認識して、サーバ側の送信バッファ内に格納されたデータセグメント（1)〜（K)を破棄することが可能となる。サーバ側の SMC131bは、データセグメント（1)〜（K)の破棄の後、応答信号を呼制御装置 3に送信する（S306)。呼制御装置 3は、当該応答信号を受信し、クライアント側の SMC131aに対して転送する（S307)。クライアント側の SMC131aは、応答信号を受信する。

[0075] その後、サーバ側の SMC131bは、データの送信を再開し、データセグメント（K + 1) , (K + 2)を送信する（S308, S309)。その後、移動端末 1の移動によって通信切断の状態に至り、データセグメント (K + 3)，（K + 4)の送信が途中で切断されたものとする（S310, S311)。この場合に、クライアント側の SMC131aは、再接続信号である Re-INVITE信号中に、移動先の通信網により新たに割り当てられた新 IPアドレスに加えて、最後に受信に成功したデータセグメント (K+ 2)を示す情報を含ませて当該 Re— INVITE信号を呼制御装置 3に送信する（S312)。呼制御装置 3は、当該 Re— INVITE信号を受信して、サーバ側の SMC 13 lbに転送する（S313)。

[0076] サーバ側の SMC131bは、 Re— INVITE信号を受信して、データセグメント（K + 2 )まで正常に送信されたことを認識し、送信バッファ内に格納されたデータセグメント（ K+ 1) , (K+ 2)を破棄することができる。そして、サーバ側の SMC131bは、データの送信を再開し、データセグメント (K+ 3) , (K + 4)を送信する（S314, S315)。

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

[0078] 続いて、同一の課題について図 10に示す通信方法とは別の方式により解決する通信方法を、図 11のシーケンス図及び図 12A, Bの説明図を用いて説明する。

[0079] 図 11に示されるように、サーバ側の SMC131bから呼制御装置 3を介さずにクライアント側の SMC131aに対してデータセグメント（1) (2) · · · (K + 2)が連続的に TCP により送信される（S401〜S405)。クライント側の SMC131aはこれらのデータセグメント（1)〜（K+ 2)を受信する力 ACK信号はサーバ側の SMC131bに対して送信しない。

[0080] このとき、所定のアルゴリズムに従レ、、送信バッファ内のデータセグメントを順次廃棄する。図 12Aでは、サーバ側の SMC131bの送信バッファ（以下、単に「SMC送信バッファ」とする）にデータセグメント（1)〜（20)が格納されている。このうち、 TCP によって規定されるトランスポート層上の送信バッファ（以下、単に「TCP送信バッファ」とする）に、データセグメント（1)〜（10)までが書き込まれてレ、る。 TCP送信バッファに格納されたデータセグメントが正常に送信され、送信した相手方から TCPによる A CK信号を受信した場合には、 TCP送信バッファから、正常送信されたデータセグメントが削除される。

[0081] このような状態で、 SMC送信バッファより、データセグメント（11)を TCP送信バッファに対して書き込もうとしたとしても、 TCP送信バッファは既にフルの状態であるため、書き込みに失敗する。 SMC131bは、 SMC送信バッファ力 TCP送信バッファへの書込みに失敗すると、 TCP送信バッファの容量が 10個のデータセグメント分であることを把握しているため、これにより TCP送信バッファからは最初に書き込んだデータセグメント 1を含むデータセグメント 10までが未だクライアント側の SMC131aに対して正常に送信されていないことを認識する。この場合に、 SMC131bは、 SMC送信バッファに格納されたデータセグメント（1)〜（： 10)までは、再送の可能性があるため、破棄しなレ、。ここで、更にクライアント側の TCP受信バッファに到達したセグメントの全てをクライアント側の SMCが取得できることが保証されてレ、なレ、場合は、クライアント側 TCP受信バッファ内のセグメントも再送要求の対象となる可能性がある。この場合、例えばクライアント側の TCP受信バッファ容量が 5セグメント分である場合は、サーバ側の TCP送信バッファ容量の 10をカ卩え、 15セグメント分が再送要求対象と考えることで解決可能である。この場合 16個目のセグメントが書き込みできた時点で 1個目のセグメントは確実にクライアント側の SMCに到達していることになる。なお、クライアント側の TCP受信バッファサイズは、図 8、図 9に示すシグナリングで通知することが可能である。

[0082] 他方、図 12Bで示されるように、 SMC131bが SMC送信バッファからデータセグメント（11)を TCP送信バッファに書き込むことができた場合には、そのデータセグメント（11)の分だけ TCP送信バッファに空きが生じていた、即ち、その空き分と同一のデータ量のデータセグメント（1)が既にクライアント側の SMCl 31aに正常送信されたことを認識すること力 Sできる。この場合には、 SMC131bは、正常に送信されたデータセグメント（1)を、 SMC送信バッファから破棄することができる。

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

[0084] その後、サーバ側の SMC131bは、データの送信を再開し、データセグメント（K + 3) , (K + 4)を送信するが（S406, S407)、移動端末 1の移動によって通信切断の状態に至り、データセグメント (K + 3) , (K + 4)の送信が途中で切断されたものとする（S406, S407)。この場合に、クライアント側の SMCl 31aは、再接続信号である R e— INVITE信号中に、移動先の通信網により新たに割り当てられた新 IPアドレスに加えて、最後に受信に成功したデータセグメント (K + 2)を示す情報を含ませて当該 Re— INVITE信号を呼制御装置 3に送信する（S408)。呼制御装置 3は、当該 Re — INVITE信号を受信して、サーバ側の SMC131bに転送する（S409)。

[0085] サーバ側の SMC131bは、 Re— INVITE信号を受信して、データセグメント（K + 2 )まで正常に送信されたことを認識し、データの送信を再開し、データセグメント (K + 2)の次に送信すべきデータセグメント (K+ 3) , (K + 4)を送信する（S410, S411)

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

産業上の利用可能性

本発明は、複数の通信網において無線通信可能な移動端末に利用することができ、コネクション型通信の継続性を高め、リアルタイム通信の通信品質を維持することに適している。

Claims

請求の範囲

[1] 複数の通信網において無線通信可能な移動端末であって、

通信相手との間で通信を行なう通信セッションを確立するために必要な情報を交換するコントローラと、

交換した必要情報に基づいて、前記通信セッションを確立し、確立された通信セッシヨンにより通信相手との間で通信を実行する通信手段とを備え、

前記コントローラは、呼制御装置を介して通信相手との間で呼制御を実行することによって、前記必要情報を取得する移動端末。

[2] 前記コントローラは、通信アプリケーションの要求に応じて、当該通信アプリケーションとの間でローカルセッションを確立することを特徴とする請求項 1記載の移動端末。

[3] 前記コントローラは、ハンドオーバを行なうときに、情報交換を実行し、新たな通信セッションに移行することを特徴とする請求項 1記載の移動端末。

[4] 前記コントローラは、通信相手からデータを正常に受信したことを示す信号を、通信相手に対して送信することを特徴とする請求項 1記載の移動端末。

[5] 前記コントローラは、通信相手との通信セッションが切断された場合に、正常に受信したデータを特定する情報を、通信相手に対して送信することを特徴とする請求項 1 〜4レ、ずれかに記載の移動端末。

[6] 前記コントローラは、コントローラ上の送信バッファから、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに対してデータを書き込むことができたか否かに応じて、正常送信済みのデータの有無にっレ、て判定し、正常送信済みのデータがあると判定した場合には、そのデータについて当該コントローラ上の送信バッファから破棄することを特徴とする請求項 1記載の移動端末。

[7] 前記移動端末のコントローラは、前記通信相手のコントローラとの間で前記通信セッシヨンを確立するために必要な情報を交換し、かつ、確立された通信セッションにより通信を実行することを特徴とする請求項：!〜 6いずれかに記載の移動端末。

[8] 複数の通信網において無線通信可能な第 1の移動端末と、第 2の移動端末間の通信方法であって、

前記第 1の移動端末と前記第 2の移動端末との間で、通信を行なう通信セッションを確立するために必要な情報を呼制御装置を介して交換する情報交換ステップと、交換した必要情報に基づレ、て、前記通信セッションを確立するセッション確立ステップと、

確立された通信セッションにより前記第 1の移動端末と前記第 2の移動端末との間で前記呼制御装置を介さずに通信を実行する通信実行ステップとを備えた通信方法前記情報交換ステップは、通信アプリケーションの要求に応じて、当該通信アプリケーシヨンとの間でローカルセッションを確立するコントローラによって実行することを特徴とする請求項 8記載の通信方法。

前記情報交換ステップは、ハンドオーバを行なうときに実行し、新たな通信セッションに移行することを特徴とする請求項 8記載の通信方法。

前記第 1の移動端末が、前記第 2の移動端末からの正常受信を示す信号を、前記第 2の移動端末に対して送信するステップと、

前記第 2の移動端末が、前記正常受信を示す信号に応じて、送信バッファのデータを破棄するステップをさらに備えたことを特徴とする請求項 8記載の通信方法。前記第 1の移動端末が、通信セッションが切断された場合に、正常に受信したデータを特定する情報を、前記第 2の移動端末に対して送信するステップと、

前記第 2の移動端末が、前記正常に受信したデータを特定する情報に基づいて、送信バッファのデータを破棄するステップとをさらに備えたことを特徴とする請求項 8 〜 11いずれかに記載の通信方法。

前記コントローラ上の送信バッファから、送信先からの正常受信を示す信号を受信してデータを削除するよう制御された送信バッファに対してデータを書き込むことができたか否かに応じて、正常送信済みのデータの有無について判定し、正常送信済みのデータがあると判定した場合には、そのデータについて当該コントローラ上の送信バッファから破棄するステップをさらに備えたことを特徴とする請求項 8記載の通信方法。

前記情報交換ステップ、セッション確立ステップ及び通信実行ステップは、前記第 1 の移動端末のコントローラと前記第 2の移動端末のコントローラ間で実行されることを特徴とする請求項 8〜： 13いずれかに記載の通信方法。