JP4457098B2 - 移動通信端末 - Google Patents

Description

本発明は、回線交換により通信を行う回線交換ベアラをサポートしているエリアと、回線交換ベアラと、パケット交換により通信を行うパケットベアラとを共にサポートするエリアとが存在している移動通信網における移動通信端末に関するものである。

ディジタル方式の移動通信システム（ＰＤＣ（Personal Digital Cellular telecommunication system），ＧＳＭ（global system for mobile communication），ＩＳ−５４，ＩＳ−９５など）の普及はめざましく、移動通信においてデータ通信のサポートが重要視されるようになっている。このため、パケット交換方式を使用するＰＤＣ−Ｐ（PDC Packet）方式、ＧＳＭに基づくＧＰＲＳ（General Packet Radio System）方式やＩＳ−９５に基づくＨＤＲ（High Data Rate）方式等が開発されている。このようなパケットを用いる通信を利用することにより、電子メールの授受やインターネットにアクセスすることが可能とされている。また、現行の回線交換方式を利用して電子メールの授受やインターネットにアクセスすることも行われている。

回線交換方式は、通信をするときに端末の間に専用の通信チャネルを設定し、通信が終わるまでそのチャネルを占有する交換接続方式であり、代表的な回線交換システムは固定電話機における電話網である。回線交換では、設定した通信チャネルの伝送速度（帯域幅）がネットワーク全体のトラフィック状態に関係なく確保されるので、端末間のエンド・ツー・エンドの伝送遅延時間の変動がない特徴を有しており、電話やテレビ会議のような、伝送遅延時間の変動によるサービス品質の劣化に敏感なサービスに適している。さらに、一度に大量のデータを送信する場合にも適しているが、回線を長時間使用するような利用法にはトラヒックの頻度が高くなることから適していない。

また、パケット交換方式は、一定の形式のパケットを使ってデータを伝送する交換方式である。パケット交換では、パケットの中継ノードとして蓄積送出方式のパケット交換機が用いられ、パケット交換機間の中継回線を多数の利用者のパケットで多重利用するので、回線使用率が高く、その結果通信コストを低下させることができる。また、ある通信区間が混んでいたり、故障になっているときは、パケット単位で自動的に迂回（うかい）ルートをたどるので、通信の信頼性が高くなる。ただし、トラフィック状態によって、エンド・ツー・エンドの伝送遅延時間が変動することになる。

移動通信網において、前記した回線交換を用いると、呼毎に通信チャネルの割り当て処理を実行して通信チャネルを割り当てることから、呼設定に時間を要するようになり、短時間の通信には適さないという問題点が生じる。また、長時間接続しているがデータを送信している実質通信時間が少ないバースト的通信を行う際にも、通信チャネルを有効に使用できないという問題点がある。さらに、トラフィックの頻度が高くなると、全ての通信チャネルが使用中となって新たな呼に空きチャネルを割り当てられず、呼損が生じるという問題点もある。
一方、移動通信網においてパケット交換を用いると、回線使用率を高くすることができるものの、パケット同士の衝突が発生するため、長時間の通信に適さないという問題点が生じる。また、トラフィックの頻度が高くなるとパケットの衝突回数が増加し、再送による伝送遅延が生じるという問題点がある。

現行の移動通信網においては、一般に回線交換を使用していることから移動通信網を構成している基地局や交換局等のノードは回線交換機能を有している。また、パケット交換機能を有しているノードを備える移動通信網も存在している。さらに、移動通信網を構成しているノードの一部に回線交換機能に加えてパケット交換機能を備えさせることが考えられる。この場合は、当該ノードで構成されるサービスエリアと回線交換機能しかサポートしないサービスエリアが存在するようになり、回線交換を使用する通信は、全てのサービスエリアにおいて行うことができるが、パケット交換を使用するパケット通信はパケット交換機能をサポートしているサービスエリアに在圏しないと行うことができないことになる。なお、回線交換機能は回線交換ベアラにより提供され、パケット交換機能はパケットベアラにより提供される。

そこで、本発明は、回線交換ベアラとパケットベアラとの効率的なベアラを選択することのできる移動通信端末を提供することを目的としている。

上記目的を達成することのできる本発明の移動通信端末は、回線交換により通信を行う回線交換ベアラをサポートしている第１のエリアと、前記回線交換ベアラと、パケット交換により通信を行うパケットベアラとを共にサポートする第２のエリアとが存在している移動通信網における移動通信端末であって、初期設定時に前記移動通信網において任意の値の閾値に変更することができるファイルサイズの閾値の情報が前記移動通信網から取得され、属性情報とファイル本体とより構成されるファイルをダウンロードする際に、当該ファイルの前記属性情報だけを最初にダウンロードし、ダウンロードされた前記属性情報を解析することにより、前記ファイル本体のサイズ情報を少なくとも得て、得られたサイズ情報における前記ファイル本体のサイズが、前記取得された前記ファイルサイズの閾値を超えるまではパケットベアラを選択すると共に、前記ファイルサイズの閾値を超えた場合は回線交換ベアラを選択し、該選択されたベアラを使用して前記ファイル本体をダウンロードするようにしている。

さらにまた、上記本発明の移動通信端末において、前記属性情報を解析することにより、前記ファイル本体のダウンロード元情報をも得るようにして、得られたダウンロード元情報で示されるサーバから前記ファイル本体をダウンロードするようにしてもよい。
さらにまた、上記本発明の移動通信端末において、前記ファイル本体をダウンロードしている途中で障害が発生した場合には、前記ファイル本体の前記サイズ情報と障害発生時までのダウンロードサイズとを比較して不足分を検出し、障害が復旧した際に検出された不足分のみをダウンロードするようにしてもよい。

このような本発明によれば、ロードするファイルのサイズに応じてベアラを選択することにより、効率的なベアラ選択を可能とすることができる。このように効率的なベアラ選択を行うことにより、移動通信網のパフォーマンスが向上し、少ないリソースで多くのユーザを収容することができるようになる。

本発明の移動通信端末を有する本発明の実施の形態における移動通信網の構成の概要を図１に示す。
本発明にかかる移動通信網は多数のセルを有しているが、図１ではその内のセルＡとセルＢとの２つだけを示している。さらに、移動通信網を構成しているノードが示されているが、セルＡとセルＢに関連するノードだけが示されている。セルＡには基地局（ＢＳ）２が設けられており、セルＡに在圏している移動通信端末である移動機の通信制御は基地局２が行っている。基地局２は回線交換ベアラ２ａを備えており、回線交換ベアラ２ａにより回線交換機能が提供されている。また、セルＡに隣接するセルＢには基地局（ＢＳ）３が設けられており、セルＢに在圏している移動通信端末である移動機の通信制御は基地局３が行っている。基地局３は回線交換ベアラ３ａおよびパケットベアラ３ｂを有しており、回線交換ベアラ３ａにより回線交換機能が提供され、パケットベアラ３ｂによりパケット交換機能が提供されている。すなわち、基地局２はパケット交換機能を備えていないが、基地局３はパケット交換機能を備えている。なお、図示していない基地局も含めて、全ての基地局は回線交換機能を備えているが、パケット交換機能をも備える基地局はその一部とされている。

ここで、移動機１が、回線交換機能しかサポートしていない基地局２を備えるセルＡに在圏すると、データ通信を行う際には回線交換ベアラ２ａを使用してデータ通信を行うことになる。従って、データ通信を行う毎に通信チャネルの割り当て処理を実行して通信チャネルを割り当ててデータ通信を行う必要があり、大きなサイズのデータの通信は効率的に行えるもの、サイズの小さいデータの通信は効率的な通信ができないことになる。これに対して、移動機１が、回線交換機能およびパケット交換機能を共にサポートしている基地局３を備えるセルＢに在圏すると、データ通信を行う際に回線交換ベアラ３ａあるいはパケットベアラ３ｂのいずれかを選択してデータ通信を行うことができる。従って、大きなサイズのデータの通信は回線交換ベアラを使用して効率的に行えると共に、サイズの小さいデータの通信はパケットベアラ３ｂを使用して効率的にデータ通信を行うことができるようになる。

そこで、本発明にかかる移動通信網では、図２および図３に示すフローチャートで示される移動機在圏処理を移動機１が実行することにより、セルＢ等の回線交換機能およびパケット交換機能をサポートしているセルに移動機１を極力在圏させるようにしている。
図２および図３に示す移動機在圏処理のフローチャートを説明する前に、前提となる移動機と基地局との接続の確立について説明する。移動通信端末である移動機において電源が投入された際には、基地局との制御を確立するために、最初に基地局から送信されている報知チャネル（ＢＣＣＨ）がサーチされる。この場合、移動機の周囲には複数の基地局（セル）が存在していることから、移動機は複数の基地局からの報知チャネルを受信することができる。この報知チャネルの候補チャネルはとまり木チャネルといわれ、とまり木チャネルの候補となる複数のチャネルが移動機を製造する段階で予め移動機内に記憶されている。そこで、電源を投入した際に移動機はとまり木チャネルをスキャンすることにより、それぞれのとまり木チャネルの搬送波電力レベルを検出する。次いで、搬送波電力のレベル順とされたとまり木チャネルのレベル順テーブルを作成し、このレベル順テーブルの順番で該当するチャネルに同期し、共通制御チャネルであることの確認を行い報知チャネルを受信することにより、移動機と基地局との接続を確立するようにしている。

そして、本発明にかかる移動通信網においては、回線交換機能およびパケット交換機能をサポートしているセルに移動機を極力在圏させるために、受信した報知チャネルの報知情報メッセージから、報知チャネルを送信している基地局がパケット交換機能をサポートしているか否かを認識する。ここで、接続の確立された基地局がパケット交換機能をサポートしている場合は、そのまま当該基地局におけるセルに在圏すればよい。また、パケット交換機能をサポートしていない場合は、レベル順テーブルにおける次の順番のとまり木チャネルの報知チャネルを受信して、当該報知チャネルを送信している基地局がパケット交換機能をサポートしているか否かを認識する。この処理においても、報知チャネルを送信している基地局がパケット交換機能をもサポートしていない場合は、繰り返し上記処理を行う。これにより、周辺に位置するパケット交換機能をもサポートしているセルが存在すれば、そのセルに在圏することができるようになる。しかしながら、上記処理を実行することによりパケット交換機能をもサポートしているセルに在圏させるには、電源投入した時点からユーザが違和感を覚えるほどの処理時間がかかる場合が生じるおそれがある。

そこで、本発明にかかる移動通信網においては、図２および図３のフローチャートで示す移動機在圏処理を移動機１が実行するようにしている。この場合、移動機１は以前在圏したパケット交換機能をもサポートしている基地局のとまり木チャネル番号を記憶していることが前提とされている。
図２および図３のフローチャートで示す移動機在圏処理を説明すると、電源を投入した際やタイマ起動により移動機在圏処理はスタートされ、ステップＳ１にて電源投入あるいは通信終了後の通常待ち受け時か否かが判断される。ここで、電源投入あるいは通常待ち受け時と判断されるとステップＳ２に進んで現在在圏しているセルはパケット交換機能をもサポートしているか否かが判断される。この場合、在圏しているセルの基地局が送信している報知チャネルの報知情報メッセージから、パケット交換機能をサポートしているか否かを判断する。ここで、在圏しているセルがパケット交換機能をサポートしていると判断された場合は、ステップＳ９に分岐してパケット交換機能をサポートしている現在在圏しているセルにそのまま在圏するようにして移動機在圏処理は終了する。

また、ステップＳ２にて在圏しているセルがパケット交換機能をサポートしていないと判断された場合は、ステップＳ３に進んでとまり木チャネル番号ｎを１に設定し、ステップＳ４にて記憶されている最初のとまり木チャネル番号「１」における搬送波電力のレベルが検出される。次いで、ステップＳ５にて検出されたレベルがパケット待ち受け許可レベル差以内か否かが判断される。ここで、検出されたレベルがパケット待ち受け許可レベル差以内であれば、ステップＳ１０に分岐してそのとまり木チャネル番号に対応するパケット交換機能をサポートしているセルに在圏するようにする。具体的に例を上げて説明すると、図１に示す移動機１は、例えばセルＢに在圏したことがあり移動機１には少なくともセルＢのとまり木チャネルが記憶されているものとする。そこで、移動機１において電源を投入した際や通信終了後の通常待ち受け時において、記憶されているセルＢのとまり木チャネルにおける搬送波電力レベルを検出する。この際、移動機１は図１に示すようにセルＢの周縁部に位置しているため、セルＡのレベルより若干小さいもののパケット待ち受け許可レベル差以内の十分なレベルが得られる。これにより、移動機１はセルＢに在圏することができるようになる。このように、移動機１はわずかな処理時間を費やすだけでパケット交換機能をもサポートしているセルＢに直ちに在圏することができ、回線交換ベアラ３ａあるいはパケットベアラ３ｂを選択して効率的にデータ通信を行うことができるようになる。

また、ステップＳ５にて設定されたとまり木チャネルの検出されたレベルがパケット待ち受け許可レベル差以内でないと判断された場合は、ステップＳ６に進んで設定されているとまり木チャネルが記憶されている最後のチャネルか否かが判断される。ここでは、ｎ＝１に設定されているので最後のチャネルではないと判断されてステップＳ７に進みｎが１だけインクリメントされとまり木チャネル番号ｎが次のとまり木チャネルの番号とされる。そして、ステップＳ４に戻り上述したパケット交換機能をサポートするセルをサーチする処理が繰り返し行われるようになる。この処理において、順次インクリメントされたいずれかのとまり木チャネル番号において検出されたレベルがパケット待ち受け許可レベル差以内と判断された場合は、ステップＳ１０に分岐してそのとまり木チャネル番号に対応するパケット交換機能をサポートしているセルに在圏して移動機在圏処理は終了する。また、記憶されている最後のとまり木チャネル番号まで処理しても検出されたレベルがパケット待ち受け許可レベル差以内でないと判断された場合は、ステップＳ６からステップＳ１１に分岐して、在圏するパケット交換機能の未サポートセルに在圏するようにされる。このように、以前在圏したことのあるパケット交換機能のサポートセルのとまり木チャネルをスキャンしていくようにしたので、移動機１はユーザに違和感を与えることなくわずかな処理時間を費やすだけで、パケット交換機能をもサポートしているセルに在圏できる確率を高くすることができるようになる。

ところで、ステップＳ１にて通常待ち受け時ではないと判断された場合は、ステップＳ８に進んでユーザがデータ通信の起動要求をしているか判断される。ここで、データ通信の起動要求をしていないと判断された場合は、ステップＳ１に戻り通常待ち受けになるかデータ通信の起動要求が発生するまで待機される。
また、ステップＳ８にてユーザがデータ通信の起動要求をしていると判断された場合は、図３に示すステップＳ１２に進む。このステップＳ１２にて現在在圏しているセルはパケット交換機能をもサポートしているか否かが判断される。この場合、在圏しているセルの基地局が送信している報知チャネルの報知情報メッセージから、パケット交換機能をサポートしているか否かを判断する。ここで、在圏しているセルがパケット交換機能をサポートしていると判断された場合は、ステップＳ１８に分岐してパケット交換機能をサポートしている現在在圏しているセルにそのまま在圏するようにして移動機在圏処理は終了する。

また、ステップＳ１２にて在圏しているセルがパケット交換機能をサポートしていないあるいはパケット交換機能をサポートしているがパケットベアラの使用が規制されているパケット規制セルと判断された場合は、ステップＳ１３に進んでタイマが起動される。次いで、ステップＳ１４にてとまり木チャネル番号をスキャンしてパケット待ち受け許可レベル差以内のパケット交換機能をサポートしているセルをサーチし、該当するセルがサーチできたか否かがステップＳ１５にて判断される。ここで、パケット待ち受け許可レベル差以内のパケット交換機能をサポートしているセルがサーチできたと判断された場合は、ステップＳ１９に分岐してパケット交換機能をサポートしているサーチされたセルに在圏する。そして、移動機在圏処理は終了する。

具体的に例を上げて説明すると、図１に示すように移動機１はセルＡに在圏しており、移動機１においてデータ通信の起動要求ボタンをユーザが操作したとする。この場合、セルＡはパケット交換機能をサポートしていないので、移動機１はとまり木チャネルをスキャンしてセルＢにおけるとまり木チャネルを受信し、その搬送波電力レベルを検出する。この際、移動機１は図１に示すようにセルＢの周縁部に位置しているため、セルＡのレベルより若干小さいもののパケット待ち受け許可レベル差以内の十分なレベルが得られる。さらに、その報知チャネルの報知情報メッセージからセルＢがパケット交換機能をサポートしていることを認識することができ、この結果、移動機１はセルＢに在圏することができるようになる。これにより、移動機１はわずかな処理時間を費やすだけでパケット交換機能をもサポートしているセルＢに在圏することができ、回線交換ベアラ３ａあるいはパケットベアラ３ｂを選択して効率的にデータ通信を行うことができるようになる。

また、ステップＳ１５にてサーチできなかったと判断された場合はステップＳ１６にてタイマ時間が終了したか否かが判断されて、タイマ時間が終了するまでステップＳ１４およびステップＳ１５の処理が繰り返し行われる。そして、ステップＳ１９へ分岐することなくタイマ時間が終了した場合は、ステップＳ１７に進んで在圏するパケット交換機能の未サポートセルに在圏するようにされる。そして、移動機在圏処理は終了する。移動機在圏処理が終了すると、ユーザが起動要求したデータ通信がスタートされ、例えば、メールの送信処理や受信処理あるいはウェブへのアクセスが行われるようになる。このように、データ通信起動要求がされた場合はタイマ時間中だけパケット交換機能をサポートするセルのサーチを行うようにしたので、移動機１はユーザに違和感を与えることなく、パケット交換機能をもサポートしているセルに在圏するための処理を行うことができるようになる。

このようにして、移動機１を回線交換機能に加えてパケット交換機能をもサポートするセルに極力在圏させることができるようになる。図１に戻り、基地局２および基地局３は、ＭＳＣ（Mobile Switching Center）４に接続されている。ＭＳＣ４は、ＳＭＳＣ５、ＤＡＳ７、ＰＭＳＣ９の各ベアラ交換機と基地局２，３，・・・とを中継する交換機である。ＳＭＳＣ（Short Message Service Center）５はショートメッセージベアラをサポートするショートメッセージ用の交換機であり、ＭＭＴＡ（Mobile Message Transfer Agent）１０がメールを受信したとするとメール着信を通知するためのNotificationを作成し、そのNotificationをＳＭＳＣ５が中継してＭＳＣ４および基地局３を介してメール相手先である、例えばセルＢに在圏する移動機１に送信する。なお、ＭＭＴＡ１０はメールを受信するメール受信サーバであり、他の移動機からのショートメッセージやインターネット１３から送られたＥ−メールのメールデータをメールボックス（ＭＳＳ）１１に格納している。ＤＡＳ（Direct Access System）７は、回線交換ベアラをサポートする交換機であり、例えばセルＢに在圏する移動機１との間で回線交換ベアラを使用して通信する際に、移動機１−基地局３−ＭＳＣ４−ＤＡＳ７のルートで接続される。この場合、移動機１，基地局３，ＭＳＣ４およびＤＡＳ７における回線交換ベアラによりノード間が相互に接続されるようになる。

ＰＭＳＣ（Packet Mobile Switching Center）９は、パケットベアラをサポートする交換機であり、例えばセルＢに在圏する移動機１との間でパケットベアラを使用してデータ通信する際に、移動機１−基地局３−ＭＳＣ４−ＰＭＳＣ９のルートで接続される。この場合、移動機１，基地局３，ＭＳＣ４およびＤＡＳ７におけるパケットベアラによりノード間が相互に接続されるようになる。ＳＭＳＣ５，ＤＡＳ７およびＰＭＳＣ９が接続されているＭＭＡＰ（Mobile Message Access Protocol）６は移動機へのメール送信サーバであり、移動機からのメール受信要求時にメールボックス１１に格納されているメールデータを移動機１へ配信している。また、ＷＧＷ（Web Gateway System）８はＤＡＳ７およびＰＭＳＣ９とインターネット１３との間に配置されており、移動通信網のプロトコルとインターネットプロトコルとのゲートウェイの役割を果たしており、これにより移動機においてインターネット１３から種々のサービスを受けることが可能となる。

例えば、移動機１がインターネット１３上にあるコンテンツのアドレスをＵＲＬ（Uniform Resource Locator）によって指定することにより、移動機１上にインターネットのコンテンツを取得することができる。この場合のコンテンツの大きさは２０kByteまでとされており、移動機１に対してより表現力の高いコンテンツをダウンロードすることができる。また、比較的小容量のデータは、パケットベアラを使用してコンテンツを取得することにより、短時間で取得できるようになる。さらに、移動機１に対してＪａｖａ（登録商標：ＴＭ）アプリケーションプログラムのダウンロードをすることによって、ゲームを始めとする各種アプリケーションのダウンロードが可能となる。なお、移動機が初めて電源を投入した際には、ＭＳＩＡ（Mobile Station Information Agent）１２に自動的に接続されて、制御情報をＭＳＩＡ１２からダウンロードすることにより移動機の初期設定が自動的に行われる。この初期設定の１つではファイルサイズの閾値が設定される。そして、閾値までの大きさのサイズのファイルを移動機がダウンロードする際は、パケットベアラを選択して接続し、閾値を超えた場合に回線交換ベアラを選択して接続するようにしている。そこで、ＭＳＩＡ１２はパケットベアラと回線交換ベアラとの使用の振り分けを任意の値の閾値に変更することにより移動機毎に自在に行うことができる。この場合、移動通信網の全体の通信状況を見てパケットベアラおよび回線交換ベアラの使用頻度が最適化されるように閾値を決定することが好適とされる。

次に、移動機１が移動機１が図２および図３に示す移動機在圏処理を実行することにより、回線交換機能に加えてパケット交換機能をもサポートするセルＢに在圏した場合の本発明にかかるベアラ選択方法を説明する。
移動機１が使用するベアラを選択する場合は、在圏しているセルの状態と起動されたアプリケーションの種類により効率的にベアラを選択するようにしている。以下に、メールを扱う場合とＨＴＴＰ（Hypertext Transfer Protocol）を使用してアクセスする場合とを具体的に説明する。

１．メール
メールを受信する際に移動機１が使用するベアラは、原則としてメールアプリケーションあるいはメール着信を移動機１に通知するNotificationで通知されたベアラを使用する。例えば、移動機１はNotification 受信時にそのベアラコントロールフィールドをチェックし、ベアラコントロールフィールドで指定されているベアラを優先的に使用して、着信されたメールを受信するようにする。Notification のデータ構造の概要を図１２に示す。この図に示すように、Notification はUser Information Data BlockとLS6Information Data Blockとからなり、User Information Data Blockの一部を構成しているEMMTP内にベアラコントロールフィールド（Bearer Control）が定義されている。このベアラコントロールフィールドで指定されたベアラでの接続失敗時（パケット交換機能網外、パケット交換規制中、ＡＲＱ（Automatic Repeat reQuest） 起動失敗）には、ユーザインタフェース上に再接続を行う画面が用意されている。

この画面からユーザが再接続を要求した場合には、前回使用していないもう一方のベアラを使用して接続するようにする。また、再接続を要求しなかった場合の、次回使用ベアラはNotification で通知されたベアラとする。ＡＲＱとは、受信側において誤りを検出した際に、送信側に再送要求を送り誤りの生じたデータを再度送信させるようにする制御である。なお、移動機１における工場出荷時に設定されている優先ベアラは、メールをメール受信サーバであるＭＭＴＡ１０へ送信する際の接続は回線交換ベアラ（ＤＡＳ）とされ、メール送信サーバであるＭＭＡＰ６からメールを受信する際の接続はパケットベアラとされている。

設定された優先ベアラを使用する際の動作について、以下に説明する。
１．１ メール送信：パケットベアラ優先
ＭＭＴＡ１０へ接続してメールを送信する際に、メールアプリケーションによりパケットベアラで接続することが優先されている場合は、パケットベアラを使用してメールをＭＭＴＡ１０へ送信する。一般に、メールのサイズはあまり大きくないことからパケットベアラを使用すると効率的にメールを送信することができる。この場合のシーケンスを図１０に示す。図１０に示すパケットベアラを使用するシーケンスにおいて、メール送信を開始する際には、移動機（ＭＳ）１はパケットチャネルによりパケットベアラを使用することを移動通信網に通知する。これにより、移動機１とＰＭＳＣ９間におけるデータ通信用のパケットチャネルが登録される（Packet Channel Registration）。次いで、一方のエンドである移動機１と、他方のエンドであるＭＭＴＡ１０とのＴＣＰ（Transmission Control Protocol）によるコネクションが確立される（TCP Connection Open）。

これにより、移動機１とＰＭＳＣ９間においてパケットベアラを使用してメールを送信する準備ができたことになり、移動機１からパケットベアラを使用してパケット化されたメールが、基地局３およびＭＳＣ４を介してＰＭＳＣ９に送信される。ＰＭＳＣ９はそのメールをメール受信サーバであるＭＭＴＡ１０に送信する。ＭＭＴＡ１０は、メールを正常に受信すると、メール送信が完了したことを通知する（Mail Submit Complete）。この通知は、ＰＭＳＣ９，ＭＳＣ４，基地局３を介して移動機１に送られる。この通知を移動機１が受信すると、ＭＭＴＡ１０とのＴＣＰコネクションが解除され（TCP Connection Close）、さらに移動機１とＰＭＳＣ９間におけるパケットチャネルが開放される（Packet Channel Release）。これにより、パケットベアラを使用するメール送信は終了する。

ここで、図１０に示すパケットベアラを使用するシーケンスにおいてメール送信する場合の移動機（ＭＳ）１とメール受信サーバであるＭＭＴＡ１０とのプロトコル階層で示した接続モデルを図４に示す。移動機（ＭＳ）１のプロトコル階層は、ＯＳＩ（Open Systems Interconnection）参照モデルにおけるデータリンク層に相当する回線交換ベアラ１ａとパケットベアラ１ｂ、ＳＭＳベアラ１ｃとが最下層とされ、その上の階層がＯＳＩ参照モデルにおけるネットワーク層に相当するＩＰ（Internet Protocol）層１ｄとされ、さらにその上の階層がＯＳＩ参照モデルにおけるトランスポート層に相当するＴＣＰ層１ｅとされている。ＴＣＰ層１ｅの上の階層は、インターネット上で電子メールの転送に利用されているメール送信用のＳＭＴＰ（Simple Mail Transfer Protocol）とメール受信用のＭＭＡＰ（Mobile IMAP4 rev1）のプロトコルとされている。このＳＭＴＰ＋ＭＭＡＰ１ｆは、ＯＳＩ参照モデルにおけるセッション層、プレゼンテーション層およびアプリケーション層に相当している。なお、ＳＭＳベアラはＳＭＳＣ５が移動機へNotificationを通知したり、あるいはショートメッセージの送受信に用いるベアラである。

また、基地局（ＢＳ）３およびＭＳＣ４はデータリンク層に相当する回線交換ベアラ３ａ、４ａとパケットベアラ３ｂ、４ｂおよびＳＭＳベアラ３ｃ、４ｃとをそれぞれ備えている。さらに、ＰＭＳＣ９はデータリンク層に相当するパケットベアラ９ａとイーサネット用のＬＡＮ（Local Area Network）インタフェース９ｂを備えている。メール受信サーバであるＭＭＴＡ１０は、データリンク層に相当するＬＡＮインタフェース１０ａが最下層とされ、その上の階層がネットワーク層に相当するＩＰ（Internet Protocol）層１０ｂとされ、さらにその上の階層がトランスポート層に相当するＴＣＰ層１０ｃとされている。ＴＣＰ層１０ｃの上の階層はメールの転送に用いられるプロトコルＳＭＴＰ１０ｄとされている。

ところで、パケットベアラ、回線交換ベアラあるいはＬＡＮインタフェースであるデータリンク層は、図４に示すように隣り合うノードとの間で情報転送を行う層であり、制御情報のやりとりやデータの受け渡しが行われる層とされている。すなわち、このデータリンク層を使用して移動機１からＭＭＴＡ１０までデータが転送されるようになる。また、ネットワーク層であるＩＰ層では、移動機１とＭＭＴＡ１０との間のルートの制御を行っており、ネットワーク層により移動機１とＭＭＴＡ１０との間の通信路が確定する。さらに、トランスポート層であるＴＣＰ層では、移動機１とＭＭＴＡ１０との間の論理的な通信路が形成され、見かけ上移動機１とＭＭＴＡ１０との間は１本の回線で接続されているかのようになる。さらにまた、セッション層、プレゼンテーション層およびアプリケーション層に相当しているＳＭＴＰ層では、移動機１とＭＭＴＡ１０との通信ルールや、データの形式が規定されていると共に、アプリケーションの整合が図られている。なお、移動機１の階層におけるMailer１ｇは、メール送信やメール受信を行えるメールアプリケーションである。

図４に示す例において、移動機１がメール受信サーバであるＭＭＴＡ１０へパケットベアラを使用してメールを送信する際には、移動機１と基地局（ＢＳ）３との間、基地局３とＭＳＣ４との間、ＭＳＣ４とＰＭＳＣ９との間がパケットベアラにより接続され、ＰＭＳＣ９とＭＭＴＡ１０との間がイーサネット等のＬＡＮにより接続される。これにより、移動機１とＭＭＴＡ１０との間のルートが確定されて、さらに、移動機１におけるＴＣＰ層１ｅとＭＭＴＡ１０におけるＴＣＰ層６ｃとの間が論理的な通信路で接続されるようになる。この結果、移動機１におけるＳＭＴＰ１ｇによりメールを送信すると、このメールをＭＭＴＡ１０のＳＭＴＰ１０ｄにより受け取れるようになる。

１．２ メール送信：回線交換ベアラ（ＤＡＳ）優先
ＭＭＴＡ１０へ接続してメールを送信する際に、メールアプリケーションにより回線交換ベアラ（ＤＡＳ）で接続することが優先されている場合は、回線交換ベアラ（ＤＡＳ）を使用してメールをＭＭＴＡ１０へ送信する。この場合、大きなサイズのメールを効率的に送信することができる。この場合のシーケンスを図１１に示す。図１１に示す回線交換ベアラを使用するシーケンスにおいて、メール送信を開始する際には、移動機（ＭＳ）１とＤＡＳ７との間において占有する通信チャネルが設定されて、移動機（ＭＳ）１とＤＡＳ７との間の回線が確立される（Call Establish）。次いで、一方のエンドである移動機１と、他方のエンドであるＭＭＴＡ１０とのＴＣＰによるコネクションが確立される（TCP Connection Open）。

これにより、回線交換ベアラを使用してメールを送信する準備ができたことになり、移動機１から回線交換ベアラを使用してパケット化されたメールが、基地局３およびＭＳＣ４を介してＤＡＳ７に送信される。ＤＡＳ７はそのメールをメール受信サーバであるＭＭＴＡ１０に送信する。ＭＭＴＡ１０は、メールを正常に受信すると、メール送信が完了したことを通知する（Mail Submit Complete）。この通知は、ＤＡＳ７，ＭＳＣ４，基地局３を介して移動機１に送られる。この通知を移動機１が受信すると、ＭＭＴＡ１０とのＴＣＰコネクションが解除され（TCP Connection Close）、さらに移動機１とＤＡＳ７間に設定されていた通信チャネルが解放される（Call Release）。これにより、回線交換ベアラを使用するメール送信は終了する。

ここで、図１１に示す回線交換ベアラを使用するシーケンスにおいてメール送信する場合の移動機（ＭＳ）１とメール受信サーバであるＭＭＴＡ１０とのプロトコル階層で示した接続モデルを図５に示す。図５に示す接続モデルにおいて、図４に示す接続モデルと異なるのはパケットベアラに替えて回線交換ベアラを用いる構成だけであるので、この構成について説明する。
図５に示す例において、ＤＡＳ７は回線交換ベアラ７ａとＬＡＮインタフェース７ｂとを備えている。移動機１がメール受信サーバであるＭＭＴＡ１０へ回線交換ベアラを使用してメールを送信する際には、移動機１と基地局（ＢＳ）３との間、基地局３とＭＳＣ４との間、ＭＳＣ４とＤＡＳ７との間がデータリンク層である回線交換ベアラ１ａ、３ａ、４ａ、７ａにより接続され、ＤＡＳ７とＭＭＴＡ１０との間がイーサネット等のＬＡＮ Ｉ／Ｆ７ｂ、１０ａにより接続される。これにより、移動機１とＭＭＴＡ１０との間のルートが確定されて、さらに、移動機１におけるＴＣＰ層１ｅとＭＭＴＡ１０におけるＴＣＰ層１０ｃとの間が論理的な通信路で接続されるようになる。この結果、移動機１におけるＳＭＴＰ１ｇによりメールを送信すると、このメールをＭＭＴＡ１０のＳＭＴＰ１０ｄにより受け取れるようになる。

１．３ メール受信：パケットベアラ優先
移動機１がメールを受信する際に使用するベアラは、メールアプリケーションあるいはNotificationによりパケットベアラで接続することが優先されている場合は、パケットベアラを原則として使用する。ただし、以下の条件でパケットベアラと回線交換ベアラとを使い分けるようにする。パケット交換機能をサポートするセル内で、かつ、基地局から送信される報知情報で示されるパケットチャネルで使用可能なタイムスロット数が３タイムスロットとされている場合は、パケットベアラを使用して接続する。また、報知情報で示されるパケットチャネルで使用可能なタイムスロット数が２タイムスロットとされている場合も、パケットベアラを使用して接続する。そして、報知情報で示されるパケットチャネルで使用可能なタイムスロット数が１タイムスロットとされている場合は、伝送速度が限られるため回線交換ベアラを使用して接続する。ただし、送信サーバ（ＭＭＡＰ６）へのコマンドがDELETEまたはALLDELTEの場合は、パケットベアラで接続してそのコマンドを送るようにする。さらに、パケット交換機能をサポートしているエリア外に位置している際や、パケットベアラを使用して接続することが規制されている場合は、回線交換ベアラを使用して接続する。

次に、パケットベアラを使用して接続するシーケンスを図１３に示す。
図１３に示すパケットベアラを使用するシーケンスにおいて、メールがＭＭＴＡ１０で受け取られると、メール受信サーバであるＭＭＴＡ１０はメール着信を通知するためのNotificationを作成し、そのNotificationをＳＭＳＣ５が中継してＳＭＳベアラを使用してＭＳＣ４および基地局３を介してメールの宛先である移動機１に送信する。同時に、ＭＭＴＡ１０はメールデータをＭＳＳ１１に格納する。移動機１はメールの着信があったことを認識し、ユーザがそのメールを受信する操作をした際に、移動機１はパケットチャネルによりパケットベアラを使用することを移動通信網に通知する。これにより、移動機１とＰＭＳＣ９間において使用するパケットチャネルが登録される（Packet Channel Registration）。次いで、一方のエンドである移動機１と、他方のエンドであるＭＭＡＰ６とのＴＣＰ（Transmission Control Protocol）によるコネクションが確立される（TCP Connection Open）。これにより、移動機１のＴＣＰ層とＭＭＡＰ６のＴＣＰ層とが接続され、パケットベアラを使用してメールを受信する準備ができたことになる。

そして、移動機１からパケットベアラを使用してメールを得るＧＥＴコマンドが、基地局３およびＭＳＣ４を介してＰＭＳＣ９に送信される。ＰＭＳＣ９はそのＧＥＴコマンドをメール送信サーバであるＭＭＡＰ６に送信する。ＭＭＡＰ６は、このＧＥＴコマンドを受けて移動機１宛のメールデータをＭＳＳ１１から読み出してＰＭＳＣ９に送る。ＰＭＳＣ９は、このメールデータをパケットベアラを使用してＭＳＣ４および基地局３を介して移動機１へ送る。これにより、移動機１はメールを取得することができ、受け取ったことを通知するG-ACK信号を基地局３およびＭＳＣ４を介してＰＭＳＣ９に送信する。ＰＭＳＣ９はそのG-ACK信号をメール送信サーバであるＭＭＡＰ６に送信する。このG-ACK信号をＭＭＡＰ６が受信すると、ＭＭＡＰ６と移動機１とのＴＣＰコネクションが解除され（TCP Connection Close）、さらに移動機１とＰＭＳＣ９間におけるパケットチャネルが解放される（Packet Channel Release）。これにより、パケットベアラを使用するメール受信は終了する。

ここで、図１３に示すパケットベアラを使用するシーケンスにおいてメール受信する場合の移動機（ＭＳ）１とメール送信サーバであるＭＭＡＰ６とのプロトコル階層で示した接続モデルを図６に示す。
図６に示すようにメール送信サーバであるＭＭＡＰ６は、データリンク層に相当するＬＡＮインタフェース６ａが最下層とされ、その上の階層がＩＰ（Internet Protocol）層６ｂとされ、さらにその上の階層がトランスポート層に相当するＴＣＰ層６ｃとされている。ＴＣＰ層６ｄの上の階層はメールを受信するプロトコルＩＭＡＰ（Internet Messaging Access Protocol）をモバイル用に拡張したプロトコルＭＭＡＰ６ｄとされている。

ところで、パケットベアラ、回線交換ベアラあるいはＬＡＮインタフェースであるデータリンク層は、図６に示すように隣り合うノードとの間で情報転送を行う層であり、制御情報のやりとりやデータの受け渡しが行われる層とされている。すなわち、このデータリンク層を使用して移動機１とＭＭＡＰ６との間でデータが転送されるようになる。また、ネットワーク層であるＩＰ層では、移動機１とＭＭＡＰ６との間のルートの制御を行っており、ネットワーク層により移動機１とＭＭＡＰ６との間の通信路が確定する。さらに、トランスポート層であるＴＣＰ層では、移動機１とＭＭＡＰ６との間の論理的な通信路が形成され、見かけ上移動機１とＭＭＡＰ６との間は１本の回線で接続されているかのようになる。さらにまた、セッション層、プレゼンテーション層およびアプリケーション層に相当しているＭＭＡＰ層では、移動機１とＭＭＡＰ６との通信ルールや、データの形式が規定されていると共に、アプリケーションの整合が図られている。

図４に示す例において、移動機１がメール送信サーバであるＭＭＡＰ６からパケットベアラを使用してメールを受信する際には、移動機１と基地局（ＢＳ）３との間、基地局３とＭＳＣ４との間、ＭＳＣ４とＰＭＳＣ９との間がデータリンク層であるパケットベアラにより接続され、ＰＭＳＣ９とＭＭＡＰ６との間がイーサネット等のＬＡＮ Ｉ／Ｆにより接続される。これにより、移動機１とＭＭＡＰ６との間のルートが確定されて、さらに、移動機１におけるＴＣＰ層１ｅとＭＭＡＰ６におけるＴＣＰ層６ｃとの間が論理的な通信路で接続されるようになる。この結果、ＭＭＡＰ６におけるＭＭＡＰ６ｄより送信されたメールが、移動機１におけるＭＭＡＰ１ｆにより受信されるようになる。

１．４ メール受信：パケットベアラ強制
移動機１がメールを受信する際に、強制的にパケットベアラで接続する。この場合、基地局から送信される報知情報で示されるパケットチャネルで使用可能なタイムスロット数に関わらず、パケットベアラを使用して接続する。この場合のパケットベアラを使用して接続するシーケンスは図１３に示すシーケンスと同様であり、プロトコル階層で示した移動機（ＭＳ）１とメール送信サーバであるＭＭＡＰ６との接続モデルも前記１．３で説明した図６に示す接続モデルと同様になる。

１．５ メール受信：回線交換ベアラ優先
移動機１がメールを受信する際に使用するベアラは、メールアプリケーションあるいはNotificationにより回線交換ベアラで接続することが優先されている場合は、回線交換ベアラを使用する。この場合の回線交換ベアラを使用して接続するシーケンスを図１４に示す。
図１４に示す回線交換ベアラを使用するシーケンスにおいて、メールをＭＭＴＡ１０が受け取ると、メール受信サーバであるＭＭＴＡ１０はメール着信を通知するためのNotificationを作成し、そのNotificationをＳＭＳＣ５が中継してＳＭＳベアラを使用してＭＳＣ４および基地局３を介してメールの宛先である移動機１に送信する。同時に、ＭＭＴＡ１０はメールデータをＭＳＳ１１に格納する。

移動機１はメールの着信があったことを認識し、ユーザがそのメールを受信する操作をした際に、移動機（ＭＳ）１とＤＡＳ７との間において占有する通信チャネルが設定されて、移動機（ＭＳ）１とＤＡＳ７との間の回線が確立される（Call Establish）。次いで、一方のエンドである移動機１と、他方のエンドであるＭＭＡＰ６とのＴＣＰ（Transmission Control Protocol）によるコネクションが確立される（TCP Connection Open）。これにより、移動機１のＴＣＰ層とＭＭＡＰ６のＴＣＰ層とが接続され、回線交換ベアラを使用してメールを受信する準備ができたことになる。

そして、移動機１から回線交換ベアラを使用してメールを得るＧＥＴコマンドが、基地局３およびＭＳＣ４を介してＤＡＳ７に送信される。ＤＡＳ７はそのＧＥＴコマンドをメール送信サーバであるＭＭＡＰ６に送信する。ＭＭＡＰ６は、このＧＥＴコマンドを受けて移動機１宛のメールデータをＭＳＳ１１から読み出してＤＡＳ７に送る。ＤＡＳ７は、このメールデータを回線交換ベアラを使用してＭＳＣ４および基地局３を介して移動機１へ送る。これにより、移動機１はメールを取得することができ、受け取ったことを通知するG-ACK信号を基地局３およびＭＳＣ４を介してＤＡＳ７に送信する。ＤＡＳ７はそのG-ACK信号をメール送信サーバであるＭＭＡＰ６に送信する。このG-ACK信号をＭＭＡＰ６が受信すると、ＭＭＡＰ６と移動機１とのＴＣＰコネクションが解除され（TCP Connection Close）、さらに移動機１とＤＡＳ７間において設定されていた通信チャネルが開放される（Packet Channel Release）。これにより、回線交換ベアラを使用するメール受信は終了する。

ここで、図１４に示す回線交換ベアラを使用するシーケンスにおいてメール受信する場合の移動機（ＭＳ）１とメール送信サーバであるＭＭＡＰ６とのプロトコル階層で示した接続モデルを図７に示す。図７に示す接続モデルにおいて、図６に示す接続モデルと異なる構成はパケットベアラに替えて回線交換ベアラを用いる構成だけであるので、この構成について説明する。
図７に示すように、ＤＡＳ７は回線交換ベアラ７ａとＬＡＮインタフェース７ｂとを備えている。移動機１がメール送信サーバであるＭＭＡＰ６から回線交換ベアラを使用してメールを受信する際には、ＤＡＳ７とＭＳＣ４との間、ＭＳＣ４と基地局３との間、基地局（ＢＳ）３と移動機１との間がデータリンク層である回線交換ベアラ７ａ、４ａ、３ａ、１ａにより接続され、ＤＡＳ７とＭＭＡＰ６との間がイーサネット等のＬＡＮ Ｉ／Ｆにより接続される。これにより、移動機１とＭＭＡＰ６との間のルートが確定されて、さらに、移動機１におけるＴＣＰ層１ｅとＭＭＡＰ６におけるＴＣＰ層６ｃとの間が論理的な通信路で接続されるようになる。この結果、この結果、ＭＭＡＰ６におけるＭＭＡＰ６ｄにより送信されたメールが、移動機１におけるＭＭＡＰ１ｆにより受信されるようになる。

２．ＨＴＴＰ
インターネット上のＷＷＷ（World Wide Web）へのＨＴＴＰ関連アクセスは、基本的にパケットベアラを使用する。また、Ｊａｖａ^TMアプリケーションプログラムは、圧縮形式がＪＡＲ（Java ARchive）とされたプログラム本体であるＪＡＲファイルとＪＡＲファイルに関する情報をふくんでいるＪＡＤ（Java Application Descriptor）ファイルから構成されており、このＪＡＲファイルをＨＴＴＰを使用してダウンロードするダウンロード要求時は、パケット交換において使用可能なタイムスロット数毎にファイルサイズの閾値を定め、ファイルサイズとパケットタイムスロット数に基づいてパケットベアラあるいは回線交換ベアラのいずれかを選択する。この場合、各タイムスロット数における閾値までの大きさのサイズのファイルをダウンロードする際は、パケットベアラを選択して接続し、各タイムスロット数における閾値を超えた場合に回線交換ベアラを選択して接続する。１タイムスロットないし３タイムスロットのタイムスロット数毎に規定されるファイルサイズの閾値は、ＭＳＩＡ（Mobile Station Information Agent）１２から取得された制御情報に基づいて設定される。なお、ＭＳＩＡ１２には移動機が初めて電源を投入した際に自動的に接続されて、制御情報をダウンロードすることにより移動機の初期設定が自動的に行われる。また、上位レイヤ（Markup Language等）よりいずれかのベアラが指定された場合は、指定されたベアラを優先して接続が試みられる。

ここで、パケットベアラを使用して移動機１がインターネット１３上のWebサーバ１４にアクセスする場合の移動機（ＭＳ）１とWebサーバ１４とのプロトコル階層で示した接続モデルを図８に示す。移動機（ＭＳ）１のプロトコル階層は、ＯＳＩ（Open Systems Interconnection）参照モデルにおけるデータリンク層に相当する回線交換ベアラ１ａとパケットベアラ１ｂ、ＳＭＳベアラ１ｃとが最下層とされ、その上の階層がＯＳＩ参照モデルにおけるネットワーク層に相当するＩＰ（Internet Protocol）層１ｄとされ、さらにその上の階層がＯＳＩ参照モデルにおけるトランスポート層に相当するＴＣＰ層１ｅとされている。ＴＣＰ層１ｅの上の階層は、インターネット上でサーバとクライアントとの間の情報転送を行うプロトコルであるＨＴＴＰ１ｈ、モバイル用に拡張されたマークアップ言語ＸＨＴＭＬ１ｉ、Ｊａｖａ^TMの実行環境を提供するＪａｖａ１ｊとされている。このＨＴＴＰ１ｈ、ＸＨＴＭＬ１ｉ、Ｊａｖａ１ｊは、ＯＳＩ参照モデルにおけるセッション層、プレゼンテーション層およびアプリケーション層に相当している。

また、基地局３およびＭＳＣ４はデータリンク層に相当する回線交換ベアラ３ａ、４ａとパケットベアラ３ｂ、４ｂおよびＳＭＳベアラ３ｃ、４ｃとをそれぞれ備えている。さらに、ＰＭＳＣ９はデータリンク層に相当するパケットベアラ９ａとＬＡＮインタフェース９ｂを備えている。移動通信網のプロトコルとインターネットプロトコルとのゲートウェイの役割を果たしているＷＧＷ８は、データリンク層に相当するＬＡＮインタフェース８ａを備えている。なお、ＷＧＷ８は、ＬＡＮ Ｉ／Ｆ８ａにより図１に示すインターネット１３上のWebサーバ１４に接続されている。このWebサーバ１４は、データリンク層に相当するＬＡＮインタフェース１４ａが最下層とされ、その上の階層がネットワーク層に相当するＩＰ層１４ｃとされ、さらにその上の階層がトランスポート層に相当するＴＣＰ層１４ｄとされている。ＴＣＰ層１４ｄの上にはＨＴＴＰ層１４ｅが位置している。

図８に示す例において、移動機１がパケットベアラ１ｂを使用して上位プロトコルとしてＨＴＴＰ１ｈによりWebサーバ１４にアクセスする際には、移動機１と基地局（ＢＳ）３との間、基地局３とＭＳＣ４との間、ＭＳＣ４とＰＭＳＣ９との間がパケットベアラ１ｂ、３ｂ、４ｂ、９ａにより接続され、ＰＭＳＣ９とＷＧＷ８との間、ＷＧＷ８とWebサーバ１４との間がイーサネット等のＬＡＮ Ｉ／Ｆ９ｂ、８ａ、１４ａにより接続される。これにより、移動機１とWebサーバ１４との間のルートが確定されて、さらに、移動機１におけるＴＣＰ層１ｅとWebサーバ１４のＴＣＰ層１４ｄとの間が論理的な通信路で接続されるようになる。この結果、移動機１においてＨＴＴＰを用いてWebサーバ１４にアクセスして、ＸＨＴＭＬで記述されたファイル等をダウンロードすることができる。ダウンロードしたファイルはアプリケーションであるブラウザ１ｋによりディスプレイ上に表示される。また、Webサーバ１４にアクセスして、Webサーバ１４からゲーム等のＪＡＲファイルをダウンロードすることができる。このダウンロードしたゲーム等のＪａｖａ^TMアプリケーションプログラム１ｍを構成しているＪＡＲファイルは、Ｊａｖａ^TM実行環境１ｊ上において実行することができ、移動機１においてダウンロードしたゲームを行うことができるようになる。なお、パケットベアラを使用してWebサーバ１４にアクセスすると、小さなサイズのファイルを効率よくダウンロードすることができるようになる。

次に、回線交換ベアラを使用して移動機１がインターネット１３上のWebサーバ１４にアクセスする場合の移動機（ＭＳ）１とWebサーバ１４とのプロトコル階層で示した接続モデルを図９に示す。この場合は、図８に示す接続モデルと異なるのは、パケットベアラに替えて回線交換ベアラを使用する構成だけであるのでこの構成について説明する。
図９において、ＤＡＳ７は回線交換ベアラ７ａとＬＡＮインタフェース７ｂとを備えている。移動機１がインターネット１３上のWebサーバ１４にアクセスする際には、移動機１と基地局（ＢＳ）３との間、基地局３とＭＳＣ４との間、ＭＳＣ４とＤＡＳ７との間がデータリンク層である回線交換ベアラ１ａ、３ａ、４ａ、７ａにより接続され、ＤＡＳ７とＰＭＳＣ９とＷＧＷ８との間、ＷＧＷ８とWebサーバ１４との間がイーサネット等のＬＡＮ Ｉ／Ｆ７ｂ、８ａ、１４ａにより接続される。

これにより、移動機１とWebサーバ１４との間のルートが確定されて、さらに、移動機１におけるＴＣＰ層１ｅとWebサーバ１４のＴＣＰ層１４ｄとの間が論理的な通信路で接続されるようになる。この結果、移動機１においてＨＴＴＰを用いてWebサーバ１４にアクセスして、Webサーバ１４からＸＨＴＭＬで記述されたファイルやゲーム等のＪＡＲファイルをダウンロードすることができる。ダウンロードしたファイルはアプリケーションであるブラウザ１ｋによりディスプレイ上に表示される。また、ダウンロードしたゲーム等のＪａｖａ^TMアプリケーションプログラム１ｍを構成しているＪＡＲファイルは、Ｊａｖａ^TM実行環境１ｊ上において実行することができ、移動機１においてダウンロードしたゲームを行うことができるようになる。なお、回線交換ベアラを使用してダウンロードすると、大きなサイズのＪＡＲファイル等を効率よくダウンロードすることができるようになる。

以上説明した本発明にかかるベアラ選択方法を適用した移動機１が実行するベアラ選択処理のフローチャートを図１５ないし図１８に示す。この図１５ないし図１８に示すフローチャートを簡単に説明する。
移動機１においては、データ通信に関するイベントが発生した際に図１５ないし図１８に示すフローチャートのベアラ選択処理が起動され、ステップＳ２１にてそのイベントがメール送信のイベントか否かが判断される。ここで、メール送信のイベントと判断されると、ステップＳ３０に分岐してパケットベアラで接続することが優先されている否かが判断される。この場合、メールアプリケーションによりパケットベアラで接続することが優先されている場合は、ステップＳ３１に進み移動機１とＰＭＳＣ９間においてパケットベアラを使用して通信するためのパケットチャネルが登録される。次いで、ステップＳ３２にて移動機１とＭＭＴＡ１０間のＴＣＰコネクションが確立されて、移動機１からパケットベアラを使用してＭＭＴＡ１０へメールデータを送信する準備が整ったことになる。

そこで、ステップＳ３３にて移動機１からＭＭＴＡ１０へメールデータが送信される。この場合、パケットベアラは登録されたパケットチャネルを使用してメールデータをＭＭＴＡ１０まで伝送していく。そして、ＭＭＴＡ１０からメール送信完了通知を受け取ると、移動機１はステップＳ３４にてメール送信が完了したと判断し、ステップＳ３５にてＴＣＰコネクションをクローズし、ステップＳ３６にて登録されたパケットチャネルを解除する。これにより、パケットベアラを使用するメール送信処理は終了してステップＳ２１に戻り、次のイベント待ちの状態となる。なお、ステップＳ３４はＭＭＴＡ１０からメール送信完了通知を受け取るまで待機している処理である。

また、ステップ３０にてパケットベアラが優先されていないと判断された場合は、メールアプリケーションにより回線交換ベアラ（ＤＡＳ）で接続することが優先されていると判断されてステップＳ３７に分岐する。ステップＳ３７では、移動機１とＤＡＳ７との間において回線交換ベアラが占有する回線交換用チャネルが設定されて回線が確立され、移動機１から回線交換ベアラを使用してＭＭＴＡ１０へメール送信する準備が整ったことになる。

そこで、ステップＳ３９にて移動機１からＭＭＴＡ１０へメールデータが送信される。この場合、回線交換ベアラは設定された回線交換チャネルを使用してＭＭＴＡ１０までメールデータを伝送していく。そして、ＭＭＴＡ１０からメール送信完了通知を受け取ると、移動機１はステップＳ４０にてメール送信が完了したと判断し、ステップＳ４１にてＴＣＰコネクションをクローズし、ステップＳ４２にて回線交換用チャネルを解放する。これにより、回線交換ベアラを使用するメール送信処理は終了してステップＳ２１に戻り、次のイベント待ちの状態となる。なお、ステップＳ４０はＭＭＴＡ１０からメール送信完了通知を受け取るまで待機する処理である。

次に、前記したステップＳ２１にて発生したイベントがメール送信ではないと判断された場合は、ステップＳ２２に進んでイベントがメール着信を知らせるNotificationの受信イベントか否かが判断される。ここで、メール着信のNotificationが受信されたと判断された場合は、図１６に示すステップＳ５０に分岐してユーザが着信通知されたメールの受信操作を行うまで待機される。ここで、ユーザが着信通知されたメールの受信操作を行うとステップＳ５１にてメールアプリケーションあるいはNotificationによりパケットベアラで接続することが優先されているか否かが判断される。この場合、パケットベアラで接続することが優先されていると判断された場合は、ステップＳ５２に進みパケットベアラで強制接続と設定されているかが判断される。

ここで、パケットベアラ強制接続と設定されている場合は、パケットベアラを使用してメール受信するようにステップＳ５４にジャンプし、パケットベアラ強制接続と設定されていない場合はステップＳ５３に進み、報知情報で通知されたパケット交換で使用可能なタイムスロット（ＴＳ）数が２タイムスロット以上とされているか否かが判断される。この場合、タイムスロット（ＴＳ）数が２タイムスロット以上とされている場合は、パケットベアラを使用してメール受信するようにステップＳ５４に進む。ステップＳ５４では、移動機１とＰＭＳＣ９間においてパケットベアラを使用して通信するためのパケットチャネルが登録される。次いで、ステップＳ５５にて移動機１とＭＭＡＰ６間のＴＣＰコネクションが確立され、ＭＭＡＰ６からパケットベアラを使用して移動機１がメール受信する準備が整ったことになる。

そこで、ステップＳ５６にて移動機１はメール受信要求のＧＥＴコマンドを送信する。このＧＥＴコマンドを受け取ったＭＭＡＰ６は、ＭＳＳ１１から該当するメールデータを読み出してＰＭＳＣ９に渡す。ＰＭＳＣ９はパケットベアラを使用してこのメールデータを移動機１へ送信する。パケットベアラは登録されたパケットチャネルを使用して移動機１までメールを伝送していく。これにより、移動機１はメールデータを受信するようになる（ステップＳ５７）。メールを受け取った移動機１は、受け取ったことを通知するG-ACK信号をＰＭＳＣ９に送信し、ＰＭＳＣ９はそのG-ACK信号をＭＭＡＰ６に送信する。このG-ACK信号をＭＭＡＰ６が受信すると、ステップＳ５９にてＭＭＡＰ６と移動機１とのＴＣＰコネクションが解除され、さらにステップＳ６０にてステップＳ５４にて登録されたパケットチャネルが解除される。これにより、パケットベアラを使用するメール受信処理は終了し、ステップＳ２１に次の戻ってイベント待ちの状態となる。

また、ステップＳ５１にてNotificationによりパケットベアラを使用することが指定されていないと判断された場合は、回線交換ベアラを使用することが指定されていたとしてステップＳ６１へ分岐する。ステップＳ６１では、ステップＳ５０にて操作したメール受信操作がＭＳＳ１１に格納されている自機のメールのALLDELETEまたはDELETEの操作であったか否かが判断される。この場合、ALLDELETEまたはDELETEの操作でない場合は、ステップＳ６２に進み移動機１とＤＡＳ７との間において回線交換ベアラが占有する回線交換用チャネルが設定されて、移動機１とＤＡＳ７との間の回線が確立される。次いで、ステップＳ６３にて一方のエンドである移動機１と、他方のエンドであるＭＭＡＰ６とのＴＣＰによるコネクションが確立される。これにより、移動機１が回線交換ベアラを使用してＭＭＡＰ６からメールを受信する準備ができたことになる。

そこで、ステップＳ６４にて移動機１はメール受信要求のＧＥＴコマンドを送信する。このＧＥＴコマンドを受け取ったＭＭＡＰ６は、ＭＳＳ１１から該当するメールデータを読み出してＤＡＳ７に渡す。ＤＡＳ７は回線交換ベアラを使用してこのメールデータを移動機１へ送信する。回線交換ベアラは、設定された回線交換用チャネルを使用して移動機１までメールデータを伝送していく。これにより、移動機１はメールデータを受信するようになる（ステップＳ６５）。メールを受け取った移動機１は、受け取ったことを通知するG-ACK信号をＤＡＳ７に送信し、ＤＡＳ７はそのG-ACK信号をＭＭＡＰ６に送信する。このG-ACK信号をＭＭＡＰ６が受信すると、ステップＳ６７にてＭＭＡＰ６と移動機１とのＴＣＰコネクションが解除され、さらにステップＳ６８にてステップＳ６２にて設定された回線交換用チャネルが解放される。これにより、回線交換ベアラを使用するメール受信処理は終了し、ステップＳ２１に戻って次のイベント待ちの状態となる。

なお、ステップＳ６１にてALLDELETEまたはDELETEの操作と判断された場合は、図１７に示すステップＳ８０にジャンプしてＭＳＳ１１に格納されている指定されたメールの削除処理が行われる。この削除処理においては、パケットベアラを使用してALLDELETEまたはDELETEコマンドを送信するようにしている。そこで、ステップＳ８０にて移動機１とＰＭＳＣ９間においてパケットベアラを使用して通信するためのパケットチャネルが登録される。次いで、ステップＳ８１にて移動機１とＭＭＡＰ６間のＴＣＰコネクションが確立される。そこで、ステップＳ８２にて移動機１はメール削除要求のALLDELETEまたはDELETEコマンドをパケットベアラを使用してＭＭＡＰ６へ送信する。

このALLDELETEまたはDELETEコマンドを受け取ったＭＭＡＰ６は、ＭＳＳ１１から該当するメールデータを削除（ALLDELETEの場合は全て削除）する。次いで、ステップＳ８３にてＭＭＡＰ６と移動機１とのＴＣＰコネクションが解除され、さらにステップＳ８４にて移動機１とＰＭＳＣ９間におけるパケットチャネルが解放される。また、ＭＭＡＰ６はメール削除を完了した際に削除完了通知をＳＭＳＣ５へ通知する。ＳＭＳＣ５は、その削除完了通知をＳＭＳベアラを使用して移動機１へ通知する。これにより、パケットベアラを使用するメール削除処理は終了し、ステップＳ２１に戻って次のイベント待ちの状態となる。

次に、前記したステップＳ２１にて発生したイベントがメール送信ではないと判断されると共に、ステップＳ２２にてそのイベントがメール着信を通知するNotificationの受信でもないと判断された場合は、ステップＳ２３に進んでウェブアクセスのイベントか否かが判断される。ここで、ウェブアクセスのイベントと判断された場合は、図１７に示すステップＳ７０に分岐する。ウェブアクセスはパケットベアラを使用してアクセスすることから、ステップＳ７０にて移動機１とＰＭＳＣ９間においてパケットベアラを使用して通信するためのパケットチャネルが登録される。次いで、ステップＳ７１にて移動機１とＵＲＬで示されるWebサーバ１４との間のＴＣＰコネクションが確立される。そこで、ステップＳ７２にて移動機１はＨＴＴＰによりWebサーバ１４にアクセスし、取得したＸＨＴＭＬで記述されたファイルを表示器に表示する。

Webサーバ１４からＪａｖａ^TMアプリケーションプログラム等のファイルをダウンロードすることができる場合は、Webサーバ１４から移動機１へ指定したファイルをダウンロードすることができる。そこで、ステップＳ７３にて移動機１において表示器の表示を見て指定したファイルのダウンロードの操作を行ったか否かが判断される。ここで、その操作を行っていない場合はステップＳ７４に進んでウェブ接続の終了操作を行った否かが判断される。そして、ここで、ウェブ接続の終了操作を行った場合はステップＳ７５にてWebサーバ１４と移動機１とのＴＣＰコネクションが解除され、さらに移動機１とＰＭＳＣ９間において設定されていたパケットチャネルがステップＳ７６にて解放される。これにより、パケットベアラを使用するウェブアクセス処理は終了し、ステップＳ２１に戻って次のイベント待ちの状態となる。なお、ウェブ接続の終了操作を行っていない場合は、ウェブ接続の終了操作を行うまでステップＳ７３およびステップＳ７４の処理が繰り返し行われるようになる。

そして、ステップＳ７３にてダウンロードの操作を行ったと判断された場合は、図１８に示すステップＳ９０へ分岐する。ステップＳ９０では、ダウンロードするファイルのサイズがＭＳＩＡ１２より取得した閾値を超えるか否かが判断され、閾値を超えないと判断された場合はステップＳ９１へ進む。この閾値は、パケット交換において使用可能なタイムスロット数毎に定められたファイルサイズの閾値とされる。ステップＳ９１では、報知情報により通知されているパケット交換において使用可能なタイムスロット数が２以上とされているか否かが判断される。ここで、通知されているタイムスロット数が２以上とされている場合は、ステップＳ９２に進んでパケットベアラが使用されてＨＴＴＰによりWebサーバ１４から指定したファイルが移動機１へダウンロードされる。

そして、ステップＳ９３にてダウンロードが終了するまで待機されて、ダウンロードが終了するとステップＳ９４にてWebサーバ１４と移動機１とのＴＣＰコネクションが解除され、さらにステップＳ９５にて移動機１とＰＭＳＣ９間において設定されていたパケットチャネルが解放される。これにより、パケットベアラを使用するダウンロード処理は終了し、ステップＳ２１に戻って次のイベント待ちの状態となる。なお、ダウンロードが終了した際にステップＳ７３に戻るようにして複数のファイルをダウンロードできるようにしてもよい。

また、ステップＳ９０にてダウンロードするファイルのサイズがＭＳＩＡ１２より取得した閾値を超えていると判断された場合、および、ステップＳ９１にてパケット交換により使用可能なタイムスロット数が１と判断された場合は、回線交換によりファイルのダウンロードを行うようにステップＳ９６へ分岐する。そして、ステップＳ９６にてWebサーバ１４と移動機１とのＴＣＰコネクションが解除され、さらにステップＳ９７にて移動機１とＰＭＳＣ９間において設定されていたパケットチャネルが解放される。続いて、ステップＳ９８にて移動機１とＤＡＳ７との間において回線交換ベアラが占有する回線交換用チャネルが設定されて、移動機１とＤＡＳ７との間の回線が確立される。次いで、ステップＳ９９にて一方のエンドである移動機１と、他方のエンドであるWebサーバ１４とのＴＣＰによるコネクションが確立される。

そして、ステップＳ１００にて回線交換ベアラを使用してＨＴＴＰによりWebサーバ１４から指定したファイルが移動機１へダウンロードされる。そして、ステップＳ１０１にてダウンロードが終了するまで待機されて、ダウンロードが終了するとステップＳ１０２にてWebサーバ１４と移動機１とのＴＣＰコネクションが解除され、さらにステップＳ１０３にて移動機１とＤＡＳ７間に設定されていた回線交換用チャネルが解放される。これにより、回線交換ベアラを使用するダウンロード処理は終了し、ステップＳ２１に戻って次のイベント待ちの状態となる。なお、ダウンロードが終了した際にステップＳ７３に戻るようにして複数のファイルをダウンロードできるようにしてもよい。

ここで、Ｊａｖａ^TMアプリケーションプログラムを移動機にダウンロードする際の付加的な説明を行う。
Ｊａｖａ^TMアプリケーションプログラムは、１つのＪＡＤ（Java Application Descriptor）ファイルとそれに対応する１つのＪＡＲ（Java Archive）ファイルとで構成されている。ＪＡＤファイルは、対応するＪＡＲファイルやＪａｖａ^TMアプリケーションプログラムに関する情報（属性）が示されたテキストファイルであり、アプリケーション名やバージョン、ＪＡＲファイルの存在位置を示すＵＲＬ、ＪＡＲファイルのサイズ等の情報が含まれている。ＪＡＤファイルはアプリケーションマネージャー（ＡＭ）がＪａｖａ^TMアプリケーションプログラムを管理するために使用される。アプリケーションマネージャーは、ＪＡＤファイルの情報を利用し、Ｊａｖａ^TMアプリケーションプログラムファイル（ＪＡＲファイル）をダウンロードする前に、当該Ｊａｖａ^TMアプリケーションプログラムが共通Ｊａｖａ^TM実行環境に適しているか否かを検証する。また、ＪＡＲファイルはＪａｖａ^TMアプリケーションプログラムを実行するために使用される圧縮あるいは非圧縮のバイナリファイルである。ＪＡＲファイルは、マニフェストファイル、Ｊａｖａ^TMアプリケーションプログラムで使用される全クラスファイル、Ｊａｖａ^TMアプリケーションプログラムが使用するリソースファイル（画像、サウンド等）を含んでいる。

Ｊａｖａ^TMアプリケーションプログラムをダウンロードする場合には、Ｊａｖａ^TMアプリケーションプログラムが属性情報を中心としたヘッダ部分（ＪＡＤファイル）とアプリケーション本体（ＪＡＲファイル）の二つで構成されていることを利用する。Ｊａｖａ^TMアプリケーションプログラムをダウンロードする移動機は、内蔵する不揮発性メモリに格納されているネットワーク状態を示すネットワーク情報を移動機から呼び出してそれに応じたベアラ選択を行うようにしている。ネットワーク情報は、ＨＴＴＰに関する情報とされ、基地局から送信される報知情報で示されるパケットチャネルで使用可能なタイムスロット数に対するＪＡＲファイル等のダウンロードサイズの情報等とされている。

Ｊａｖａ^TMアプリケーションプログラムをダウンロードする際の基本的なダウンロード手順を以下に示す。
１．移動機が待受け状態からブラウザーを起動させて、ブラウザーモードとする。
２．ＨＴＴＰを使用して取得した画面に表示されたメインメニューからＪａｖａ^TMアプリケーションプログラムがアンカされているＷｅｂサイトへのアクセスを行う。すなわち、ユーザ操作により、そのＷｅｂサイトにアンカ（＜Ａ＞タグ等により）される所望のＪａｖａ^TMアプリケーションプログラムの選択をブラウザー上において行うことにより、アンカで指定されるＵＲＬのＷｅｂサーバから、当該Ｊａｖａ^TMアプリケーションプログラムに関するＪＡＤファイルのダウンロードが行われる。この場合、ブラウザーモードが持続的接続（Persistent Connection）とされている場合は、ブラウザーモードから継続したＴＣＰトランザクションによりＪＡＤファイルのダウンロードが行われる。また、ブラウザーモードが持続的接続とされていない場合は、ＪＡＤファイルのダウンロード要求時にＴＣＰ接続を確立してそのトランザクションによりＪＡＤファイルのダウンロードが行われる。また、ＪＡＤファイルをダウンロードする際のベアラは、前記した図１５ないし図１８に示すベアラ選択処理におけるＷｅｂアクセス処理（ステップＳ２３）以降の処理で選択されたベアラとされる。

３．移動機は、ユーザが指定したアンカ先のＵＲＬからのＪＡＤファイルのダウンロードが完了した後、共通Ｊａｖａ^TM実行環境から提供されるＪＡＤファイル解析関数をコールする。共通Ｊａｖａ^TM実行環境は、ＪＡＤファイル解析関数内でＪＡＤファイルの内容（属性値）をチェックし、その結果（正常／異常）を移動機のプラットフォームへ戻り値として返す。

４．移動機のプラットフォームは、共通Ｊａｖａ^TM実行環境が提供しているＪＡＤファイル解析関数の結果が正常の場合のみ、ユーザへダウンロード確認画面の通知を行い、ユーザがそれに同意した場合（「ＯＫ」を押下）、ＪＡＲファイルのダウンロードを開始する。また、戻り値が異常であった場合は、ユーザにその旨を通知する。
ＪＡＲファイルをダウンロードする場合は、ＪＡＤファイル内に設定されているＪＡＲファイルのサイズ情報（MIDlet-Jar-Size）の値をチェックし、ＭＳＩＡからネットワーク情報として通知されている閾値との比較を行い、ＪＡＲファイルのサイズの値が閾値を超える場合は、一般の回線番号と異なる回線番号とされた回線交換ベアラ（特殊ＤＡＳ）を用いてＪＡＲファイルの取得処理を行う。ダウンロード元はＪＡＤファイルの解析によって得たＪＡＲファイルの存在位置を示すＵＲＬ、すなわちＪａｖａ^TMアプリケーションプログラムのダウンロード用プロキシサーバ（Java Proxy）とされる。

また、ＪＡＲファイルのサイズの値が閾値以下の場合は、パケットベアラが選択されてＪＡＲファイルをプロキシサーバ（Java Proxy）からパケットベアラを用いてダウンロードする処理が行われる。ただし、移動機が存在するネットワーク環境がパケットベアラをサポートしていない場合は、ＪＡＲファイルのサイズの値が閾値以下であっても回線交換ベアラを使用してＪＡＲファイルのダウンロードを行う。
なお、閾値についてさらに説明すると、パケット交換において使用可能なタイムスロット数毎にＪＡＲファイルサイズの閾値を定め、ファイルサイズとパケットタイムスロット数に基づいてパケットベアラあるいは回線交換ベアラのいずれかを選択する。この場合、各タイムスロット数における閾値までの大きさのサイズのＪＡＲファイルをダウンロードする際は、パケットベアラを選択して接続し、各タイムスロット数における閾値を超えた場合に回線交換ベアラを選択して接続する。１タイムスロットないし３タイムスロットのタイムスロット数毎に規定されるＪＡＲファイルサイズの閾値は、ＭＳＩＡ（Mobile Station Information Agent）１２から取得された制御情報に基づいて設定される。また、Ｊａｖａ^TMアプリケーションプログラムのサイズがダウンロード可能なサイズを超えている場合は、ダウンロードできないことをユーザに通知する。

５．移動機のプラットフォームはＪＡＲファイルの受信完了後、ＪＡＲファイル（マニフェストファイル）の解析を行う。この時エラーがあれば、「Ｊａｖａ^TMアプリケーションの取得に失敗しました」などのエラーメッセージを表示し、取得済みのＪＡＤファイル、ＪＡＲファイルを削除し、ブラウザーの状態に戻る。また、ＪＡＲファイル（マニフェストファイル）の解析結果が正常であり、Ｊａｖａ^TMアプリケーションプログラムが即時起動Ｊａｖａ^TMアプリケーション（MIDlet-Immediate：Ｙ）とされている場合は、ダウンロードしたＪａｖａ^TMアプリケーションを即時起動する。即時起動とされていない場合は、ＪＡＤファイルの保存属性（MIDlet-Save）に従い、Ｊａｖａ^TMアプリケーションプログラムを移動機内のメモリあるいは外部メモリに保存する。
なお、即時起動Ｊａｖａ^TMアプリケーションか否かはＪＡＤファイルのMIDlet-Immediate情報を解析することにより得ることができる。また、Ｊａｖａ^TMアプリケーションプログラムを保存する際に、移動機内のメモリあるいは外部メモリの空き容量が不足する場合は、保存することができない旨をユーザに通知する。

６．移動機内部のメモリあるいは外部メモリに保存されたＪＡＲファイルは、移動機のＪａｖａ^TMセレクタより、ユーザが選択を行うことができ、選択されたＪａｖａ^TMアプリケーションプログラムを起動することにより、選択されたＪａｖａ^TMアプリケーション（例えば、ゲーム）を実行することができる。
７．Ｊａｖａ^TMアプリケーションの実行を終了し、メモリへの格納等が完了したら、移動機はブラウザーの状態へ戻す。

なお、Ｊａｖａ^TMアプリケーションプログラムのダウンロード中に着信があった場合は、ダウンロードは一時停止させ着信が終了した際に再開させる。また、Ｊａｖａ^TMアプリケーションプログラムが公序良俗を害するコンテンツなどでないかの判断を、ＪＡＤファイルのMIDlet-Codeを利用して認証済みか否かを判断することにより行うことができる。さらに、Ｊａｖａ^TMアプリケーションプログラムを保存する空き容量がメモリにない場合にダウンロード不可の判定を行うようにしてもよい。さらにまた、Ｊａｖａ^TMアプリケーションプログラムが保存や転送が不可とされているコンテンツかどうかの判定を行い、保存や転送が不可とされているＪａｖａ^TMアプリケーションプログラムの保存および転送の処理を禁止する。これらの各制御は、ＪＡＤファイル内の属性情報に基づいて行うことの可能な制御である。

ところで、移動機がＪａｖａ^TMアプリケーションプログラムをダウンロード中において、移動機に着信があった際にはダウンロードが一時停止される。また、ダウンロード中に移動機が圏外に移動した場合等においては物理回線が切断されるようになる。このような場合には、着信が終了して待ち受け状態になった際や通信可能な状態になった際に、改めてＪａｖａ^TMアプリケーションプログラムのダウンロードを最初から行うことになり、効率が悪いと共にネットワークの輻輳やユーザーのストレスを増大させる原因となっていた。そこで、本発明にかかる移動機においては、再度最初からＪａｖａ^TMアプリケーションプログラムを取得するのではなく、用意されているバイトレンジ機能を用いてダウンロードされなかった足りない部分だけを取得できるようにしている。

バイトレンジ機能とは、レスポンス受信中に圏外エリアに移動した場合等によりエンティティの受信が完了しなかった時に、エンティティ全体ではなくその中の受信できなかった１つまたは複数のバイトレンジを要求することができる機能である。この場合、指定できるバイトレンジは１バイト単位とされている。バイト範囲リクエスト機能を使用するときにはRangeヘッダを送出する。また、エンティティの特定のため、RangeヘッダはIf-Rangeヘッダと併用されて使用される。そこで、Ｊａｖａ^TMアプリケーションプログラムのダウンロード中に予期しないネットワークの切断が発生したときなどにおいて、このようなバイトレンジ機能をもちいることにより、再度Ｊａｖａ^TMアプリケーションプログラムの全てを取得しなおすことをせず、足りない部分のみ取得することができるようになる。この場合、回線切断時点でのダウンロードファイルの解析と、ＪＡＤファイルのダウンロードサイズと比較して、不足分を指定してダウンロードする。これによって、無線ネットワークリソースの有効活用、アクセス時間の短縮を行うことができる。特に、障害復旧時に再ダウンロードするときの効率化を図ることができる。

本発明は以上説明したように、パケットサポートエリアのとまり木チャネル番号を記憶しておき、このとまり木チャネル番号に基づいて待ち受けチャネルを選択するようにしたので、移動通信端末を極力パケットサポートエリアに在圏させることができる。これにより、移動通信端末は、ベアラ選択の幅が拡がり効率的なベアラ選択を可能とすることができる。

また、メール着信の際にはその通知情報で指定されたベアラを優先して使用したり、メール送信の際にメールアプリケーションにより指定されたベアラを優先して使用するようにしている。さらに、ウェブにアクセスする際にはパケットベアラが優先的に使用されるようにしているので、アプリケーション毎に効率的なベアラ選択を可能とすることができる。さらにまた、使用可能なタイムスロット数に応じてベアラを選択したり、ロードするファイルのサイズに応じてベアラを選択することにより、効率的なベアラ選択を可能とすることができる。このように効率的なベアラ選択を行うことにより、移動通信網のパフォーマンスが向上し、少ないリソースで多くのユーザを収容することができるようになる。さらにまた、ファイルサイズの閾値情報を移動通信網における回線交換ベアラとパケットベアラとが使用される割合を調整することのできる任意の値とされた閾値情報とすることにより、移動通信網において回線交換ベアラとパケットベアラとが使用される割合を調整することができるようになる。

本発明の移動通信端末を有する本発明の実施の形態における移動通信網の構成の概要を示す図である。 本発明の実施の形態における移動通信網おける移動機が実行する移動機在圏処理の一部のフローチャートである。 本発明の実施の形態における移動通信網おける移動機が実行する移動機在圏処理の残るフローチャートである。 本発明の実施の形態にかかる移動通信網においてパケットベアラを使用してメール送信する場合の移動機とＭＭＴＡとのプロトコル階層で示した接続モデルを示す図である。 本発明の実施の形態にかかる移動通信網において回線交換ベアラを使用してメール送信する場合の移動機とＭＭＴＡとのプロトコル階層で示した接続モデルを示す図である。 本発明の実施の形態にかかる移動通信網においてパケットベアラを使用してメール受信する場合の移動機とＭＭＡＰとのプロトコル階層で示した接続モデルを示す図である。 本発明の実施の形態にかかる移動通信網において回線交換ベアラを使用してメール送信する場合の移動機とＭＭＡＰとのプロトコル階層で示した接続モデルを示す図である。 本発明の実施の形態にかかる移動通信網においてパケットベアラを使用してウェブアクセスする場合の移動機とウェブサーバとのプロトコル階層で示した接続モデルを示す図である。 本発明の実施の形態にかかる移動通信網において回線交換ベアラを使用してウェブアクセスする場合の移動機とウェブサーバとのプロトコル階層で示した接続モデルを示す図である。 本発明の実施の形態にかかる移動通信網においてパケットベアラを使用してメール送信する場合のシーケンスを示す図である。 本発明の実施の形態にかかる移動通信網において回線交換ベアラを使用してメール送信する場合のシーケンスを示す図である。 本発明の実施の形態にかかる移動通信網におけるNotificationのデータ構造を示す図である。 本発明の実施の形態にかかる移動通信網においてパケットベアラを使用してメール受信する場合のシーケンスを示す図である。 本発明の実施の形態にかかる移動通信網において回線交換ベアラを使用してメール送信する場合のシーケンスを示す図である。 本発明の実施の形態における移動通信網おける移動機が実行するベアラ選択処理の一部のフローチャートである。 本発明の実施の形態における移動通信網おける移動機が実行するベアラ選択処理の一部のフローチャートである。 本発明の実施の形態における移動通信網おける移動機が実行するベアラ選択処理の一部のフローチャートである。 本発明の実施の形態における移動通信網おける移動機が実行するベアラ選択処理の残るフローチャートである。

符号の説明

１ 移動機、１ａ 回線交換ベアラ、１ｂ パケットベアラ、１ｃ ＳＭＳベアラ、１ｄ ＩＰ層、１ｅ ＴＣＰ層、１ｆ SMTP＋MMAP、１ｇ Mailer、１ｈ HTTP、１ｉ ＸＨＴＭＬ、１ｊ Ｊａｖａ^TM実行環境、１ｋ ブラウザ、１ｍ Ｊａｖａ^TMアプリケーションプログラム、２ 基地局、２ａ 回線交換ベアラ、３ 基地局、３ａ 回線交換ベアラ、３ｂ パケットベアラ、３ｃ ＳＭＳベアラ、４ ＭＳＣ、５ ＳＭＳＣ、６ ＭＭＡＰ、６ａ ＬＡＮインタフェース、６ｂ ＩＰ層、６ｃ ＴＣＰ層、７ ＤＡＳ、７ａ 回線交換ベアラ、７ｂ ＬＡＮインタフェース、８ ＷＧＷ、８ａ ＬＡＮインタフェース、９ ＰＭＳＣ、９ａ パケットベアラ、９ｂ ＬＡＮインタフェース、１０ ＭＭＴＡ、１０ａ ＬＡＮインタフェース、１０ｂ ＩＰ層、１０ｃ ＴＣＰ層、１１ メールボックス、１３ インターネット、１４ Webサーバ、１４ａ ＬＡＮインタフェース、１４ｃ ＩＰ層、１４ｄ ＴＣＰ層、１４ｅ ＨＴＴＰ層、Ａ セル、Ｂ セル

Claims (3)

1. 回線交換により通信を行う回線交換ベアラをサポートしている第１のエリアと、前記回線交換ベアラと、パケット交換により通信を行うパケットベアラとを共にサポートする第２のエリアとが存在している移動通信網における移動通信端末であって、
   初期設定時に前記移動通信網において任意の値の閾値に変更することができるファイルサイズの閾値の情報が前記移動通信網から取得され、属性情報とファイル本体とより構成されるファイルをダウンロードする際に、当該ファイルの前記属性情報だけを最初にダウンロードし、ダウンロードされた前記属性情報を解析することにより、前記ファイル本体のサイズ情報を少なくとも得て、得られたサイズ情報における前記ファイル本体のサイズが、前記取得された前記ファイルサイズの閾値を超えるまではパケットベアラを選択すると共に、前記ファイルサイズの閾値を超えた場合は回線交換ベアラを選択し、該選択されたベアラを使用して前記ファイル本体をダウンロードするようにしたことを特徴とする移動通信端末。
2. 前記属性情報を解析することにより、前記ファイル本体のダウンロード元情報をも得るようにして、得られたダウンロード元情報で示されるサーバから前記ファイル本体をダウンロードするようにしたことを特徴とする請求項１記載の移動通信端末。
3. 前記ファイル本体をダウンロードしている途中で障害が発生した場合には、前記ファイル本体の前記サイズ情報と障害発生時までのダウンロードサイズとを比較して不足分を検出し、障害が復旧した際に検出された不足分のみをダウンロードするようにしたことを特徴とする請求項１記載の移動通信端末。

Images