(57)【特許請求の範囲】
【請求項１】
パケットを受信し、該パケットを有線または無線により接続されたデータ端末装置に転送する通信端末であって、
パケットに付された圧縮ヘッダの圧縮状態が最大圧縮状態であるか否かを判定する判定手段と、
前記判定の結果、最大圧縮状態であると判定された場合には、前記圧縮ヘッダを疎通させるとともに前記データ端末装置に対してＲｏＨＣルータの起動要求を送信し、最大圧縮状態ではないと判定された場合には、前記圧縮ヘッダを伸長したうえで前記データ端末装置に転送する転送手段と、
を備えることを特徴とする通信端末。
【請求項２】
パケットを受信し、該パケットを有線または無線により接続されたデータ端末装置に転送する通信端末が、
パケットに付された圧縮ヘッダの圧縮状態が最大圧縮状態であるか否かを判定し、
前記判定の結果、最大圧縮状態であると判定された場合には、前記圧縮ヘッダを疎通させるとともに前記データ端末装置に対してＲｏＨＣルータの起動要求を送信し、最大圧縮状態ではないと判定された場合には、前記圧縮ヘッダを伸長したうえで前記データ端末装置に転送し、
前記データ端末装置が、
前記ＲｏＨＣルータの起動要求を受信した場合に、ＲｏＨＣルータを起動するとともに、転送された前記圧縮ヘッダの解凍を実行することを特徴とするデータ転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末およびデータ転送方法に関する。
【背景技術】
【０００２】
携帯電話機などの通信端末を通信用モデムやルータに用いて、基地局側から転送されたデータをパーソナルコンピュータ（ＰＣ）などのデータ端末装置に転送する通信形態が知られている。
【０００３】
通信端末がルータ機能を備えることにより、ＰＤＡ：Personal Digital Assistant：携帯情報端末機）やＰＣに接続され、ＩＰ（Internet Protocol ）アドレスに応じて最適な通信経路を構築することが知られている（たとえば、特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２１７９９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、３ＧＰＰ（３rdGeneration Partnership Project）では、３．９ＧとしてのＬＴＥ（Long Term Evolution ）を規定している。このＬＴＥの通信規格ではレイヤ２〔ＰＤＣＰ（Packet Data Convergence Protocol：パケットデータ収斂プロトコル）〕でＩＰパケットヘッダの圧縮・解凍をすることができる。つまり、通信端末とＬＴＥ基地局との間では圧縮ヘッダによる送受信が可能である。
【０００６】
これに対し、通信端末を通信用モデムとして利用する場合、通信端末やＰＣなどのデータ端末装置と当該通信端末との間には、シリアルバス規格の一つである、ＵＳＢ（Universal Serial Bus：）などの転送プロトコルが用いられる。
【０００７】
このため、通信端末がＬＴＥ基地局との間で圧縮ヘッダを用いた通信が可能であっても、通信端末が接続されたデータ端末装置へのデータ転送は、通信端末を通過させるヘッダ情報を圧縮パケットから非圧縮に伸長させる必要がある。つまり、通信端末とデータ端末装置との間では、ＩＰパケット送受信に合わせるため、圧縮パケットを解凍（伸長）する。
【０００８】
このため、通信端末とデータ端末装置との接続にＰＰＰ（Point to Point Protocol ：２点間接続用プロトコル）を使用するなど、接続の形態によってはデータ転送量が増大し、スループットを悪化させる。
【０００９】
そこで、本開示の通信端末およびデータ転送方法の目的は、上記課題に鑑み、データ端末装置に接続される通信端末のデータ処理を軽減することである。
また、本開示の通信端末およびデータ転送方法の他の目的は、上記課題に鑑み、スループットを向上させることにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本開示の通信端末およびデータ転送方法は、通信端末がパケットを受信し、該パケットを有線または無線により接続されたデータ端末装置に転送する。通信端末は受信した圧縮ヘッダの判定手段と転送手段を備える。判定手段は、パケットに付された圧縮ヘッダの圧縮状態が最大圧縮状態であるか否かを判定する。転送手段は、判定の結果に応じて圧縮ヘッダの疎通およびＲｏＨＣルータの起動要求、または圧縮ヘッダの伸長を行う。すなわち、判定の結果、最大圧縮状態であると判定された場合には、圧縮ヘッダを疎通させるとともにデータ端末装置に対してＲｏＨＣルータの起動要求を送信する。最大圧縮状態ではないと判定された場合には、圧縮ヘッダを伸長したうえでデータ端末装置に転送する。そして、データ端末装置は、ＲｏＨＣルータの起動要求を受信した場合に、ＲｏＨＣルータを起動するとともに、転送された圧縮ヘッダの解凍を実行する。
【発明の効果】
【００１１】
本開示の通信端末またはデータ転送方法によれば、次のいずれかの効果が得られる。
【００１２】
(1) データ端末装置に有線または無線で接続された通信端末が受信した圧縮パケットの復元処理を省略でき、データ処理を軽減できる。
【００１３】
(2) 圧縮ヘッダを通信端末に疎通させることができるので、通信端末でのスループットを向上させることができる。
【００１４】
(3) 通信端末に有線または無線で接続されたデータ端末装置に圧縮ヘッダが転送され、ヘッダのデコード処理を簡易化できる。
【００１５】
そして、本発明の他の目的、特徴及び利点は、添付図面及び各実施の形態を参照することにより、一層明確になるであろう。
【図面の簡単な説明】
【００１６】
【図１】第１の実施の形態に係るパケット通信システムの一例を示す図である。
【図２】パケット処理の処理手順の一例を示すフローチャートである。
【図３】第２の実施の形態に係る通信システムの一例を示す図である。
【図４】パケット構成およびヘッダ処理の一例を示す図である。
【図５】第３の実施の形態に係る通信システムの一例を示す図である。
【図６】通信システムおよびプロトコルスタックの一例を示す図である。
【図７】起動シーケンスの一例を示す図である。
【図８】圧縮パケット転送の解除シーケンスの一例を示す図である。
【図９】ＲｏＨＣルーティング制御（ＬＴＥ機能部側処理）の一例を示すフローチャートである。
【図１０】ＲｏＨＣルーティング制御（ＲＲＣ／ＴＡＦ機能部側処理）の一例を示すフローチャートである。
【図１１】簡易ＲｏＨＣ終端処理の一例を示すフローチャートである。
【図１２】ＲｏＨＣルーティング制御（ＬＴＥ機能部側処理）の一例を示すフローチャートである。
【図１３】ＲｏＨＣルーティング制御（ＲＲＣ／ＴＡＦ機能部側処理）の一例を示すフローチャートである。
【図１４】ＲｏＨＣルーティング制御（外部ＴＥドライバ側処理）の一例を示すフローチャートである。
【図１５】通信端末から外部ＴＥへのデータ転送例（ＲｏＨＣルータＯＦＦの場合）を示す図である。
【図１６】通信端末から外部ＴＥへのデータ転送例（ＲｏＨＣルータＯＮの場合）を示す図である。
【図１７】ＵＥおよび外部ＴＥのハードウェアの一例を示す図である。
【図１８】ＲｏＨＣヘッダの圧縮時の構成例を示す図である。
【図１９】圧縮ヘッダの最大圧縮比率を示す図である。
【図２０】他の実施の形態に係る通信システムを示す図である。
【図２１】他の実施の形態に係る通信システムを示す図である。
【図２２】比較例に係る通信システムの一例を示す図である。
【図２３】パケット構成およびヘッダ処理の一例を示す図である。
【発明を実施するための形態】
【００１７】
〔第１の実施の形態〕
【００１８】
第１の実施の形態について、図１を参照する。図１は通信システムの一例を示している。
【００１９】
図１に示す通信システム２は本開示の通信端末およびデータ転送方法の一例である。この通信システム２は、ＵＥ（User Equipment：ユーザ機器）４と外部ＴＥ（Terminal Equipment：端末機器）６とを備える。この通信システム２ではＵＥ４でパケットを受信し、該パケットをＵＥ４に有線または無線により接続された外部ＴＥ６に転送する。
【００２０】
ＵＥ４は通信端末の一例であって、受信機能８、状態判定機能１０、圧縮ヘッダ疎通機能１２を備える。したがって、ＵＥ４はこれらの機能を備えた機器であればよく、携帯電話機はその一例である。
【００２１】
ＵＥ４の受信機能８は基地局（ＢＳ２２：図３）から送信される圧縮ヘッダを備えるパケットなどのデータを受信する機能である。状態判定機能１０は、ヘッダ情報の圧縮状態を判定する状態判定手段の一例であり、パケットに付された圧縮ヘッダの圧縮状態を判定する機能である。圧縮ヘッダ疎通機能１２は圧縮ヘッダの付されたパケットを疎通させ、外部ＴＥ６に転送する機能である。
【００２２】
外部ＴＥ６は、データ端末装置の一例であり、圧縮ヘッダを元ヘッダに復元するヘッダ復元機能１４を備える。この外部ＴＥ６はＵＥ４と有線または無線により接続され、ＵＥ４から転送された圧縮ヘッダを元ヘッダ情報に復元する。この外部ＴＥ６はたとえば、パーソナルコンピュータで構成され、パケット復元機能１４を備えるモデム（Modem ：信号変換装置）などのデータ処理が可能な機器であればよい。
【００２３】
つぎに、この通信システム２のヘッダ処理について、図２を参照する。図２は処理手順の一例を示している。
【００２４】
図２に示す処理手順は本開示のデータ転送方法の一例である。この処理手順では、ＵＥ４でパケットを受信し、該パケットをＵＥ４から外部ＴＥ６に転送する処理である。
【００２５】
この処理手順では、パケットを受信し（ステップＳ１１）、このパケットに付された圧縮ヘッダの圧縮状態を判定する（ステップＳ１２）。この圧縮状態が安定状態であれば、その判定の結果に応じて、圧縮ヘッダをそのまま疎通させ、外部ＴＥ６に転送する（ステップＳ１３）。
【００２６】
圧縮ヘッダが転送された外部ＴＥ６で圧縮ヘッダのデコード処理が行われる（ステップＳ１４）。
【００２７】
このようなヘッダ処理による効果を以下に列挙する。
【００２８】
(1) ＵＥ４では受信した圧縮パケットの復元処理を省略でき、ＵＥ４での処理を軽減できる。
【００２９】
(2) 圧縮ヘッダをＵＥ４に疎通させるので、ＵＥ４でのスループットを向上させることができる。
【００３０】
(3) ＵＥ４に接続された外部ＴＥ６に圧縮ヘッダが転送されるので、外部ＴＥ６によるヘッダのデコード処理を簡易化できる。
【００３１】
〔第２の実施の形態〕
【００３２】
第２の実施の形態について、図３を参照する。図３は通信システムの一例を示している。図３のＡは通信システムの概要、図３のＢは通信システムのＵーＰｌａｎｅのプロトコル構成を示している。図３に示す構成は一例であって、斯かる構成に本発明は限定されない。図３において、図１と同一部分には同一符号を付してある。
【００３３】
図３のＡに示す通信システム２は、本開示の通信端末およびデータ転送方法の一例である。
【００３４】
ＵＥ４は、無線および有線通信機能、データ処理機能、既述の機能（図１）、状態通知機能などの各種の制御機能を有する。このＵＥ４は無線通信機能によりＬＴＥ基地局（Base Station：ＢＳ）２２に無線により接続される。ＢＳ２２は例えば、ＬＴＥ（Long Term Evolution ）の通信規格のＬＴＥ無線基地局であって、ｅＮｏｄｅＢ（Evolved Node B）とも称されるノードである。したがって、ＵＥ４はＢＳ２２を介して共通の通信規格を持つ他の通信端末（ＳＳ：Subscriber Station）２４（図４）に接続される。
【００３５】
ＵＥ４は、ＬＴＥ−ＲＦ（Long Term Evolution −Radio Frequency ：ＬＴＥ無線部）２６、無線側処理部〔ＭＴ（Ｌ２）：Mobile Terminal 〕としてＣＰＵ（Central Processing Unit ）コア３１、有線側処理部（ＭＴ）としてＣＰＵコア３２を備えている。Ｌ２はレイヤ２である。このＬ２はデータリンク層であり、プロトコル機能を表すＯＳＩ（Open Systems Internetconnection ：データ通信規格）参照モデルにおいて、接続機器が通信を行うための方式が規定され、伝送経路の構成やデータ識別、経路選択などの方法を規定するプロトコルである。このＵＥ４のＣＰＵコア３２には、外部ＴＥ６がケーブル２８により有線接続されている。
【００３６】
図３のＢに示すＢＳ２２は、上位層にＲｏＨＣ（Robust Header Compression ：ヘッダ圧縮アルゴリズム）２４２を備える。さらに、ＲＬＣ（ Radio Link Control ：無線リンク制御）２４４、ＭＡＣ（Medium Access Control ：媒体アクセス制御）２４６、ＬＴＥ−Ｌ１（物理層）２４８が備えられる。ＲｏＨＣ２４２は、ヘッダ圧縮アルゴリズムであり、ＩＰパケットヘッダの圧縮・解凍機能を有する。
【００３７】
ＵＥ４にはＬＴＥ無線機能部４２と、ＲＲＣ（Radio Resource Control：無線リソース制御）／ＴＡＦ（Terminal Adaptation functions ：端末接続機能）機能部４４が備えられる。ＬＴＥ無線機能部４２はデータの受信機能８（図１）、送信機能、圧縮ヘッダの状態判定機能１０（図１）を司る機能部であり、ＢＳ２２と同様にＲｏＨＣ４２１、ＲＬＣ４２２、ＭＡＣ４２３、ＬＴＥ−Ｌ１４２４が備えられている。さらに、ＲｏＨＣルータ４２５、ＣＰＵ間ＩＦ４２６、ＰＨＹ〔Physical Layer：物理層）Ｂｕｓ−ＩＦ〕４２７が備えられる。ＰＨＹ４２７は物理層のインターフェースである。
【００３８】
ＲＲＣ／ＴＡＦ機能部４４は、ＲｏＨＣルータ４４１、ＣＰＵ間ＩＦ４４２、ＰＨＹ（Ｂｕｓ−ＩＦ）４４３、ＰＰＰ（Point-to-Point Protocol ：シリアル回線用通信プロトコル）４４４、ＵＳＢ（Universal Serial Bus：周辺機器用シリアルインターフェース）−ＩＦ（Ｌ２）４４５、ＰＨＹ（Ｂｕｓ−ＩＦ）４４６が備えられている。
【００３９】
外部ＴＥ６にはアプリケーション機能部４６が備えられ、このアプリケーション機能部４６にはアプリケーションデータ４６１、ＵＤＰ（User Datagram Protocol：トランスポート層の通信プロトコル）／ＴＣＰ（Transmission Control Protocol ：ネットワークのトランスポート層の通信プロトコル）４６３が備えられている。さらに、ＩＰｖ４／ｖ６４６４、ＲｏＨＣルータ終端４６５、ＰＰＰ４６６、ＵＳＢ−ＩＦ（Ｌ２）４６７、ＰＨＹ（Ｂｕｓ−ＩＦ）４６８が備えられている。
【００４０】
このように、ＵＥ４から外部ＴＥ６には疎通経路４８が形成され、この疎通経路４８には、ＩＰヘッダ圧縮ルータであるＲｏＨＣルータ４２５、４４１が設置されている。この場合、ＲｏＨＣルータ４４１はＢＳ２２から外部ＴＥ６にデータを流すダウンリンク（ＤＬ：DownLink：下り回線）のみで機能させる。これにより、ＵＥ４〜ＳＳ２４（図４）間で実施されるＬＴＥ用機能だけでヘッダ圧縮を行い、ＵＥ４でのパケット圧縮処理を省略できる。
【００４１】
ＲｏＨＣ処理は無線ハンドシェークと密接に関係する。ＵＥ４とＳＳ２４との間では各々の状態遷移を認識する必要がある。ＵＥ４では、既述のダウンリンクのみでＩＰヘッダを圧縮して疎通させ、最適な機能分割を実現している。
【００４２】
ＲｏＨＣルータ４２５、４４１は、ＲｏＨＣ実施時（ヘッダ圧縮時）、圧縮ＩＰパケットをそのまま疎通させる。また、通信ベアラがデータ圧縮をサポートした場合には、保存中のＩＰヘッダ情報に基づく転送先つまり、外部ＴＥ６に転送する。
【００４３】
外部ＴＥ６内に設置されたＲｏＨＣルータ終端４６５は、セッション開始時に保存中のＩＰヘッダを用いて圧縮ＩＰパケットヘッダを復元する。
【００４４】
そして、ＬＴＥ無線機能部４２ではＩＰヘッダ圧縮の状態が安定しているか否かを判定し、安定した場合にはその状態をＲＲＣ／ＴＡＦ機能部４４に通知する。これにより、ＲＲＣ／ＴＡＦ機能部４４のＲｏＨＣルータ４４１が圧縮ヘッダすなわち、圧縮ＩＰパケットヘッダを持つＩＰパケットを疎通経路４８に疎通させる。このような処理を実現するには、ＵＥ４側から外部ＴＥ６まで、すなわち、のＲｏＨＣルータ４２５、４４１間、これらと外部ＴＥ６側のＲｏＨＣルータ終端４６５までの疎通経路４８で制御用ハンドシェークを確立する必要がある。
【００４５】
ＳＳ２４から外部ＴＥ６までのパケット転送について、図４を参照する。図４はパケットの転送およびヘッダ圧縮を示している。図４において、図３と同一部分には同一符号を付してある。
【００４６】
ＳＳ２４は、アプリケーション・ソフトウェア４８１とともに、プロトコルであるＲＴＰ（Real Time Protocol：リアルタイムプロトコル）４８２、ＵＤＰ（User Datagram Protocol：通信プロトコル）４８３、ＩＰ（Internet Protocol ）４８４、ＲｏＨＣ４８５、ＬＴＥ−ＭＡＣ（Long Term Evolution −Media Access Control：アクセス制御）＆ＲＬＣ（Radio Link Control：無線リンク制御）４８６およびＬＴＥ−ＰＨＹ４８７を備える。
【００４７】
ＳＳ２４から外部ＴＥ６にパケットを流すダウンリンクにおいて、ＳＳ２４側では、アプリケーション・ソフトウェア４８１によりペイロード５０１が生成される。ＲＴＰ４８２、ＵＤＰ４８３、ＩＰ４８４の処理により、ＲＴＰヘッダ５０２、ＵＤＰヘッダ５０３、ＩＰヘッダ５０４が付される。このような複雑なヘッダ部分は、ＲｏＨＣ４８５によりＲｏＨＣヘッダ５０５に圧縮される。つまり、ＩＰ段階でペイロード５０１、ヘッダのＲＴＰヘッダ５０２、ＵＤＰヘッダ５０３、ＩＰヘッダ５０４のパケット構成は、圧縮処理により変換されたＲｏＨＣヘッダ５０５とペイロード（Ｐａｙｌｏａｄ）５０１のパケット構成５０に軽量化される。このＲｏＨＣヘッダ５０５およびペイロード５０１が圧縮ヘッダパケット（ダウンリンクユーザパケット）５０に編成される。
【００４８】
圧縮ヘッダパケット５０は、ＬＴＥ−ＭＡＣ＆ＲＬＣ４８６およびＬＴＥ−ＰＨＹ４８７を経て無線により既述のＢＳ２２を介してＵＥ４に転送される。
【００４９】
ＵＥ４では受信した圧縮ヘッダパケット５０がＬＴＥ−ＰＨＹ（ＬＴＥ−Ｌ１）４２４、ＬＴＥ−ＭＡＣ＆ＲＬＣ４２２、４２３、ＲｏＨＣ４２１およびＩＰルーティング（Routing ）４２８を経てＲｏＨＣルータ４４１に至る。ＩＰルーティング４２８では、圧縮ヘッダパケット５０の圧縮状態が安定しているか否かを判定し、安定していれば圧縮ヘッダを既述の疎通経路４８に疎通させる処理を行う。この処理には、外部ＴＥ６に対するＲｏＨＣルータの起動要求などのルーティング処理が含まれる。つまり、圧縮ヘッダが安定していれば、ＲｏＨＣルータ４４１に圧縮ヘッダパケット５０を疎通させ、ＲｏＨＣルータ４４１からＰＰＰ４４４、ＵＳＢ−ＩＦ（Ｌ２）４４５およびＵＳＢ−ＰＳＹ４４６を経て外部ＴＥ６に転送される。
【００５０】
ＵＥ４から外部ＴＥ６に転送された圧縮ヘッダパケット５０は、ヘッダ部が圧縮状態であり、既述のＲｏＨＣヘッダ５０５とペイロード５０１で構成されている。
【００５１】
この圧縮ヘッダパケット５０が転送されたＴＥ６ではＵＳＢ−ＰＨＹ４６８、ＵＳＢ−ＩＦ（Ｌ２）４６７、ＰＰＰ４６６、ＲｏＨＣルータ４６５に至り、ＩＰ４６４、ＵＤＰ／ＴＣＰスタック４６３、ＲＴＰ４６２、アプリケーションデータ４６１に至る。このような処理を経て圧縮ヘッダパケット５０のＲｏＨＣヘッダ５０５は、ＩＰヘッダ５０４、ＵＤＰヘッダ５０３、ＲＴＰヘッダ５０２に解凍（伸長）され、ペイロード５０１がデコードされる。
【００５２】
このようなダウンリンクに対し、アップリンクにおいては、外部ＴＥ６で生成された圧縮ヘッダパケットがＵＥ４の疎通経路４８を疎通し、ＢＳ２２を介してＳＳ２４に至る（ルーティング処理）。
【００５３】
そして、このルーティング処理では、ＩＰヘッダ圧縮機能により、圧縮ヘッダの圧縮状態が安定した場合に、ＲｏＨＣルータ４４１に疎通させる際に、ＬＴＥ無線機能部４２から圧縮ヘッダパケット５０を疎通することを通知する通知機能を備えている。この通知は、ＬＴＥ無線機能部４２からＲＲＣ／ＴＡＦ機能部４４への通知、ＲＲＣ／ＴＡＦ機能部４４から外部ＴＥ６への通知を含む。
【００５４】
ＰＰＰ４４４の転送ＬＣＰ（Link Control Protocol ：リンクコントロールプロトコル）に、ＵＥ４からＩＰヘッダ圧縮が安定した状態を外部ＴＥ６に通知する制御機能を備えている。
【００５５】
ヘッダ圧縮のハンドシェークが完了した状態で、外部ＴＥ６側に基本ＩＰヘッダのＩＰアドレス情報などから、元のＩＰヘッダを復元するための復元機能を備えている。
【００５６】
斯かる構成によれば、次のような効果が得られる。
【００５７】
(1) ダウンリンク（ＤＬ）において、ＬＴＥのＬ２レイヤ（ＰＤＣＰ）でヘッダの復元処理を省略することができる。
【００５８】
(2) ヘッダのデータ容量を削減でき、ＰＰＰ４４４によるエスケープ処理（オクテット変換）後のデータ増加を緩和できる。
【００５９】
(3)   ＬＴＥのＬ２レイヤから外部ＴＥ６までの疎通ルートに圧縮ヘッダパケットを疎通させ、ヘッダ圧縮した状態で転送できるので、スループットを向上させることができる。
【００６０】
(4) 外部ＴＥ６でＩＰヘッダのデコード処理を簡易化できる。
【００６１】
(5) ハンドシェーク（制御命令）の大幅な増加を伴うことなく、既述のメリットが得られる。実質的なデータ（ストリーミングデータなどの領域）に対してのスループットを向上させることができる。
【００６２】
〔第３の実施の形態〕
【００６３】
第３の実施の形態について、図５を参照する。図５は通信システムの構成例を示している。図５に示す構成例は一例であり、この構成に本発明が限定されるものではない。図５において、図３と同一または共通部分には同一符号を付してある。
【００６４】
図５に示すＵＥ４は本開示の通信端末の一例であり、モデム（Modem ：信号変換装置）を構成している。このＵＥ４ではＣＰＵコア３１と、ＣＰＵコア３２と、共有メモリ５４と、外部ＴＥインターフェース５６とが備えられている。このＵＥ４では、ＢＳ２２（図３）から送信される所定の周波数たとえば、２〔ＧＨｚ〕、３〔ＧＨｚ〕または３．９〔ＧＨｚ〕の無線信号を受信するアンテナ２７が備えられている。
【００６５】
ＣＰＵコア３１は、無線信号からパケットデータの再生など、各種の無線部側処理を担当する機能部であり、既述のＬＴＥ無線機能部４２を構成する。このＬＴＥ無線機能部４２ではＲｏＨＣ機能部５２（図１５）のＲｏＨＣルータ機能制御（マスター）４３２、ＲｏＨＣ４２１、ｅｖＲＬＣ４２２およびｅｖＭＡＣ４２３の機能を実現している。このＣＰＵコア３１の出力側にはスイッチ４３０が構成されている。このスイッチ４３０はＲｏＨＣルータ機能制御４３２によって制御され、このスイッチ４３０からＲｏＨＣ４２１による出力やｅｖＲＬＣ４２２の出力が共有メモリ５４に提供される。ＲｏＨＣルータ機能制御４３２は、圧縮ヘッダの状態を判定してルーティング制御を実行する。すなわち、その判定結果に応じてスイッチ４３０を切り替え、スイッチ４３０は、圧縮ヘッダの疎通、またはＲｏＨＣ４２１による圧縮ヘッダの復元ヘッダの疎通をする。
【００６６】
共有メモリ５４は、ＣＰＵコア３１とＣＰＵコア３２で共有される記憶手段である。この共有メモリ５４はＨＤＤ（Hard Disk Drive ：ハードディスク装置）や半導体メモリなどの記録媒体で構成すればよい。この共有メモリ５４にはＵＥ４で受信したデータ、外部ＴＥ６側に疎通させる既述の圧縮ヘッダパケット５０などのパケットデータが格納される。そして、ＣＰＵコア３１、３２間のハンドシェークに基づき、共有メモリ５４を媒介としてＣＰＵコア３１からＣＰＵコア３２にデータが転送される。
【００６７】
ＣＰＵコア３２は、有線側処理を担当し、既述のＲＲＣ／ＴＡＦ機能部４４を構成する。このＲＲＣ／ＴＡＦ機能部４４ではＲｏＨＣルータ機能制御（スレーブ）４４８、Ｕ−Ｐｌａｎｅ（User Plane：ユーザ情報転送プレーン）のＲｏＨＣ終端機能制御（マスター）４５０およびＲｏＨＣルータ４５２の機能を実現している。ＲｏＨＣルータ機能制御４４８はマスターである既述のＲｏＨＣルータ機能制御４３２に対してスレーブの関係を有する。ＣＰＵコア３１、３２間のハンドシェークに基づき、ＲｏＨＣルータ機能制御４３２、４４８が協調動作を行うが、ＲｏＨＣルータ機能制御４３２が主動、ＲｏＨＣルータ機能制御４４８が従動となる。
【００６８】
ＲｏＨＣ終端機能制御４５０は、ＵＥ４と外部ＴＥ６またはＢＳ２２との間でユーザデータの送受信を制御する。
【００６９】
ＲｏＨＣルータ４５２は、共有メモリ５４とＵＳＢ処理機能部４５４との間に介在し、外部ＴＥ６側にデータ転送をするための伝送ルートを構成している。
【００７０】
ＲｏＨＣルータ４５２の出力はＵＳＢ処理機能部４５４に渡され、ＣＰＵコア３２から外部ＴＥインターフェース５６に出力される。外部ＴＥインターフェース５６はＵＥ４と外部ＴＥ６とを有線接続するための中継手段である。この外部ＴＥインターフェース５６にはスイッチを含むＵＳＢ−ＰＨＹ（ＵＳＢ物理層）５４２が備えられる。このＵＳＢ−ＰＨＹ５４２には外部ＴＥ６がケーブル２８により有線接続されている。これにより、ＣＰＵコア３１側で受信されたデータは、矢印Ｘで示すように、データ転送が行われ、外部ＴＥ６に提供される。
【００７１】
外部ＴＥ６はたとえば、ＰＣで構成され、有線接続されたＵＥ４からデータ転送を受ける。この外部ＴＥ６には、ＵＳＢ６０２、メモリ６０４、ドライバ６０６、Ｕ−ＰｌａｎｅのＲｏＨＣ終端機能制御（スレーブ）６０８、受信バッファ６１０が備えられている。
【００７２】
ＵＳＢインターフェース６０２に有線接続されたＵＥ４からデータ転送を受けると、そのデータはメモリ６０４に格納される。
【００７３】
ＲｏＨＣ終端機能制御６０８はマスターである既述のＲｏＨＣルータ終端機能制御４５０に対してスレーブの関係を有する。ＣＰＵコア３２および外部ＴＥ６間のハンドシェークに基づき、ＲｏＨＣ終端機能制御４５０、６０８が協調動作を行うが、ＲｏＨＣ終端機能制御４５０が主動、ＲｏＨＣ終端機能制御６０８が従動となる。このようなマスター・スレーブの関係により、このメモリ６０４に格納されたヘッダパケットに対し、ＲｏＨＣ終端処理が実施され、その結果がドライバ６０６に提供される。
【００７４】
受信バッファ６１０にはデコードされたＩＰヘッダとペイロードがメモリ６０４からＴＣＰ（ＵＤＰ）／ＩＰスタック４６３に提供される。この場合、インターフェースにたとえば、ＰＯＳＩＸ−ＡＰＩ（Portable Operating System Interface −Application Programming Interface ：インターフェース）が用いられる。
【００７５】
斯かる構成では、ＣＰＵコア３１側に実装されたＲｏＨＣ４２１およびＲｏＨＣルータ機能制御４３２、ＣＰＵコア３２側に実装されたＲｏＨＣルータ機能制御４４８、ＲｏＨＣ終端機能制御（マスター）４５０によりＵ−Ｐｌａｎｅルート制御が実行される。これにより、ＲｏＨＣヘッダ５０５（図４）を備えるＵ−Ｐｌａｎｅパケットが外部ＴＥ６まで転送される。
【００７６】
モデムを構成するＵＥ４ではＲｏＨＣルータ４５２を起動することでｅｖＰＤＣＰレイヤから転送されるデータはＲｏＨＣヘッダ（圧縮ヘッダパケット）とペイロードの転送となる。このため、ＬＴＥ無線機能部４２で必要とするＲｏＨＣ機能がＰＤＣＰレイヤに搭載されるが、ＩＰパケットのヘッダ解凍は不要となる。このようなＵ−Ｐｌａｎｅパスを確立するシーケンスは、後述の通り（図７、図９など）である。
【００７７】
次に、通信システム２およびプロトコルスタックについて、図６を参照する。図６において、図５と同一部分には同一符号を付してある。
【００７８】
この通信システム２では、ＵＥ４がＢＳ２２からのデータ受信、外部ＴＥ６からのデータ送信を行うモデムを構成し、たとえば、データカード端末を構成している。
【００７９】
このＵＥ４のＬＴＥ無線機能部４２にはＲｏＨＣルーティング（ＲｏＨＣルータ４２５の処理）、ｅｖＰＤＣＰ（ＲｏＨＣ）４２１、ｅｖＲＬＣ４２２、ｅｖＭＡＣ４２３、ＬＴＥ（−Ｌ１）４２４、インターフェース４２６、ＰＨＹ（Ｂｕｓ−ＩＦ）４２７のプロトコルが搭載されている。
【００８０】
ＲＲＣ／ＴＡＦ機能部４４にはＲｏＨＣルーティング（ＲｏＨＣルータ４４１の処理）、インターフェース４４２、ＰＨＹ（Ｂｕｓ−ＩＦ）４４３、ＲＦＣ１６６１／１６６２処理４４７、ＵＳＢ−ＩＦ４４６のプロトコルが搭載されている。
【００８１】
ＵＥ４には入出力部６０が設けられ、この入出力部６０を介して外部ＴＥ６が接続される。入出力部６０はＵＳＢコネクタまたはＰＣＩ（Peripheral Component Interconnect ：入出力パス）で構成される。
【００８２】
外部ＴＥ６はホストＰＣ（パーソナルコンピュータ）やモデムで構成される。この外部ＴＥ６はアプリケーションデータ４６１、ＵＤＰ／ＴＣＰ４６３、ＩＰ（ｖ４／ｖ６）４６４、簡易ＲｏＨＣ終端４６９、ＲＦＣ１６６１／１６６２処理４７０、ＵＳＢ−ＩＦ４７１のプロトコルが搭載されている。ダウンリンクで提供されたデータは、アプリケーションデータ４６１によりエンドユーザ６２に提供される。エンドユーザ６２からアプリケーション４６１に提供されたデータにはＵＤＰヘッダ５０３、ＩＰヘッダ５０４が付され、これらのヘッダがＲｏＨＣヘッダ５０５に圧縮される。この圧縮ヘッダ５０５を付されたデータが外部ＴＥ６からＵＥ４に転送される。
【００８３】
次に、起動シーケンスについて、図７を参照する。図７は起動シーケンスの一例を示している。
【００８４】
この起動シーケンスは、本開示データ転送方法の一例であって、ＲｏＨＣによる圧縮ヘッダパケットをＲｏＨＣルータ４２５、４４１を使用して外部ＴＥ６へ送信する処理を含んでいる。シーケンス起動はシーケンスにあるメッセージ応答を実施する機能を含んでいる。ＵＥ４には、内部でＬＴＥ（Ｌ２）無線機能部４２と、ＲＲＣ／ＴＡＦ機能部４４間のＲｏＨＣルータ４４８の起動制御メッセージが用いられる。このＲｏＨＣルータ起動制御メッセージには、ＲｏＨＣ起動または停止要求と、ＲｏＨＣ起動または停止応答である。
【００８５】
このルーティング制御では、ＵＥ４からその制御を外部ＴＥ６のドライバ６０６に伝えるメッセージが用いられる。このメッセージは、ＰＰＰ４６６のＬＣＰオプションに追加すればよい。このメッセージには、
ａ．Configuration-Request （ＲｏＨＣルータ起動または停止要求）、
ｂ．Configuration-Ack （ＲｏＨＣルータ起動または停止応答）、
ｃ．Configuration-Request （ＩＰヘッダ受け取り要求）、
ｄ．Configuration-Ack （受け取り完了応答）
が含まれる。
【００８６】
図７に示す起動シーケンスには、ＢＳ２２、ＵＥ４のＬＴＥ（Ｌ２）無線機能部４２、およびＲＲＣ／ＴＡＦ機能部４４、外部ＴＥ６のドライバ６０６およびミドルウェア６１１が用いられる。ミドルウェア６１１はヘッダの圧縮又は圧縮ヘッダの伸長に用いられるソフトウェアであり、ＯＳ層とアプリケーション層の間に位置する。
【００８７】
ＢＳ２２、ＵＥ４及び外部ＴＥ６が通信接続された状態（Attach）である（ステップＳ１００）。この起動シーケンスが開始される。ＢＳ２２には通信状況に応じて初期化状態（ＩＲ State：Initialization & Refresh State）、遷移状態（ＦＯ State：First Order State ）又は安定状態（ＳＯ State：Second Order State）が存在する。
【００８８】
ＩＲ Stateでは、ＢＳ２２から圧縮パケットであるＩＲパケット（ＲｏＨＣ）がＬＴＥ（Ｌ２）無線機能部４２に転送される（ステップＳ１０１）。ＩＲ Stateではノーコンテキスト（No Context）であり、この状態は有効なヘッダ情報がない場合である。この場合、ＬＴＥ（Ｌ２）無線機能部４２から非圧縮のＩＲパケットが外部ＴＥ６のドライバ６０６に転送され（ステップＳ１０２）、このドライバ６０６からＩＰパケットが外部ＴＥ６のミドルウェア６１１に転送される（ステップＳ１０３）。
【００８９】
ＦＯ Stateでは、ＩＲ−ＤＹＮパケット（ＲｏＨＣ）がＬＴＥ（Ｌ２）無線機能部４２に転送される（ステップＳ１０４）。この場合、Static Contextであり、ダイナミック（Dynamic ）フィールドの更新が必要な場合である。この場合、ＬＴＥ（Ｌ２）無線機能部４２からＩＰパケット（非圧縮）が外部ＴＥ６のドライバ６０６に転送され（ステップＳ１０５）、このドライバ６０６からＩＰパケットが外部ＴＥ６のミドルウェア６１１に転送される（ステップＳ１０６）。
【００９０】
ＳＯ Stateでは、ＵＯ−０／ＵＯ−１／ＵＯＲ−２パケット（ＲｏＨＣ）がＬＴＥ（Ｌ２）４２に転送される（ステップＳ１０７）。この場合、Full Contextであり、全てのフィールド情報が正しく復号化されている場合である。この場合、ＬＴＥ（Ｌ２）４２からＩＰパケット（非圧縮）が外部ＴＥ６のドライバ６０６に転送され（ステップＳ１０８）、このドライバ６０６からＩＰパケットが外部ＴＥ６のミドルウェア６１１に転送される（ステップＳ１０９）。
【００９１】
ＬＴＥ（Ｌ２）４２からＲｏＨＣ制御情報が発せられ、共有メモリ５４にＩＰヘッダが保存される（ステップＳ１１０）。ＩＰヘッダ最大圧縮状態での転送状態（ステップＳ１１１）に移行すると、ＬＴＥ（Ｌ２）からＲＲＣ／ＴＡＦ４４にＲｏＨＣルータ起動要求が発せられ（ステップＳ１１２）、ＲＲＣ／ＴＡＦ４４からＬＣＰ（Configuration-Request ：ＲｏＨＣルータ起動要求）がドライバ６０６に転送される（ステップＳ１１３）。これに対し、ＬＣＰ（Configuration-Ack ：ＲｏＨＣルータ起動応答）がＴＡＦ４４に対して転送される（ステップＳ１１４）。
【００９２】
ＬＴＥ（Ｌ２）無線機能部４２からＲＲＣ／ＴＡＦ４４に対し、共有メモリ５４に格納されているＲｏＨＣ制御情報が発せられる（ステップＳ１１５）。ＴＡＦ４４からＬＣＰ（Configuration-Request ：ＩＰヘッダ受取り要求＋ＩＰヘッダ）がドライバに転送され（ステップＳ１１６）、外部ＴＥ６のメモリ６０４にＲｏＨＣ制御情報が格納される（ステップＳ１１７）。ドライバ６０６からConfiguration-Ack （受け取り完了応答）がＴＡＦ４４に転送され（ステップＳ１１８）、ＲＲＣ／ＴＡＦ４４からＲｏＨＣルータ起動応答がＬＴＥ（Ｌ２）４２に転送される（ステップＳ１１９）。
【００９３】
ＢＳ２２からＵＯ−０パケット／ＵＯ−１パケット／ＵＯＲ−２パケット（ＲｏＨＣ）がＬＴＥ（Ｌ２）４２に転送され（ステップＳ１２０）、ＬＴＥ（Ｌ２）４２ではヘッダ確認が行われる（ステップＳ１２１）。ヘッダ確認の結果がＯＫであれば、ＬＴＥ（Ｌ２）４２からＵＯ−０パケット／ＵＯ−１パケット／ＵＯＲ−２パケット（ＲｏＨＣ）がドライバ６０６に転送される（ステップＳ１２２）。ドライバ６０６では、ヘッダ復元が実行され（ステップＳ１２３）、ＩＰパケットがミドルウェア６１１に渡される（ステップＳ１２４）。
【００９４】
このように、ＬＴＥ機能部４２のＬ２レイヤではＲｏＨＣがFull Context状態（最大圧縮状態）になるまで外部ＴＥ６には非圧縮ヘッダをつけたＩＰパケットが送信される。そして、最大圧縮状態（Full Context）で外部ＴＥ６側にＲｏＨＣルータ４６５の起動要求が送信され、ハンドシェークが開始される。
【００９５】
次に、圧縮パケット転送の解除処理について、図８を参照する。図８は圧縮パケット転送を解除する処理シーケンスを示している。
【００９６】
図８に示す処理シーケンスは、本開示のデータ転送方法の一例であって、ＬＴＥ機能部４２では、ＣＲＣ（Cyclic Redundancy Check ：巡回冗長検査）機能でＮＧなどエラー検出した場合、ＲｏＨＣ処理ＮＧと判定し、Ｌ２レイヤで（ＬＴＥであればＰＤＣＰレイヤ）、ＢＳ２２のＲｏＨＣ処理を解除する。解除すると同時に外部ＴＥ６側にＲｏＨＣルータ停止要求を送信し、外部ＴＥ６のＲｏＨＣ復元を停止する。つまり、圧縮パケット転送を解除する処理シーケンスを実行する。
【００９７】
図８に示す処理シーケンスでは、ＢＳ２２、ＵＥ４及び外部ＴＥ６がＩＰヘッダ最大圧縮状態での転送状態にあれば（ステップＳ２０１）、ＢＳ２２からＵＯ−０パケット／ＵＯ−１パケット／ＵＯＲ−２パケット（ＲｏＨＣ）がＬＴＥ（Ｌ２）４２に転送される（ステップＳ２０２）。ＬＴＥ（Ｌ２）４２ではヘッダ確認が行われ（ステップＳ２０３）、ヘッダ確認の結果がＯＫであれば、ＬＴＥ（Ｌ２）４２からＵＯ−０パケット／ＵＯ−１パケット／ＵＯＲ−２パケット（ＲｏＨＣ）がドライバ６０６に転送される（ステップＳ２０４）。ドライバ６０６では、ヘッダ復元が実行され（ステップＳ２０５）、ＩＰパケットがミドルウェア６１１に提供される（ステップＳ２０６）。
【００９８】
これに対し、ＢＳ２２からＵＯ−０パケット／ＵＯ−１パケット／ＵＯＲ−２パケット（ＲｏＨＣ）が転送され（ステップＳ２０７）、ＬＴＥ（Ｌ２）４２がヘッダ確認（ステップＳ２０８）した結果、ＮＧの場合がある。この場合、ＬＴＥ（Ｌ２）４２からＢＳ２２にＮＡＣＫパケット（ＲｏＨＣ）を転送する（ステップＳ２０９）。これにより、ＢＳ２２とＵＥ４の間でも通常ＩＰヘッダでの転送状態に遷移する（ステップＳ２１０）。
【００９９】
通常ＩＰヘッダの転送状態に遷移すると、ＬＴＥ（Ｌ２）４２は、ＲｏＨＣ制御情報を格納している共有メモリ５４にあるＩＰヘッダを破棄し（ステップＳ２１１）、ＴＡＦ４４にＲｏＨＣルータ停止要求を発する（ステップＳ２１２）。ＴＡＦ４４は、ＬＣＰ（Configuration-Request ：ＲｏＨＣルータ停止要求）をドライバ６０６に転送する（ステップＳ２１３）。これに対し、ドライバ６０６は、ＲｏＨＣ制御情報を格納しているメモリ６０４にあるＩＰヘッダを破棄し（ステップＳ２１４）、ＬＣＰ（Configuration-Ack ：ＲｏＨＣルータ停止応答）をＲＲＣ／ＴＡＦ機能部４４に転送する（ステップＳ２１５）。これを受けたＲＲＣ／ＴＡＦ機能部４４は、ＲｏＨＣ停止応答をＬＴＥ（Ｌ２）４２に転送する（ステップＳ２１６）。
【０１００】
ＩＲ Stateに遷移したＢＳ２２側は、ＩＲパケット（ＲｏＨＣ）をＵＥ４のＬＴＥ（Ｌ２）４２に転送する（ステップＳ２１７）。このノーコンテキストの場合、ＬＴＥ（Ｌ２）４２から非圧縮のＩＰパケットが外部ＴＥ６のドライバ６０６に転送され（ステップＳ２１８）、ドライバ６０６から外部ＴＥ６のミドルウェア６１１にＩＰパケットが転送される（ステップＳ２１９）。
【０１０１】
次に、ＲｏＨＣルータ４２５などの機能制御について、図９、図１０および図１１を参照する。図９はＲｏＨＣルーティング制御（ＬＴＥ処理側）のフローチャートを示している。図１０はＲｏＨＣルーティング（ＴＡＦ側）のフローチャートを示している。図１１は簡易ＲｏＨＣ終端処理（ドライバ側）のフローチャートを示している。
【０１０２】
〔ＲｏＨＣルーティング制御（ＬＴＥ機能部４２側の処理）〕
【０１０３】
図９に示す処理手順は、本開示のデータ転送方法の一例であって、ＬＴＥ機能部４２側の処理である。この処理手順を開始すると、ＲｏＨＣ遷移状態を取得する（ステップＳ３０１）。このＲｏＨＣ遷移状態は、ＲｏＨＣルータ機能制御４３２にある有限状態マシーン（ＦＳＭ：Finite State Machine）からポーリングにより実行される。ＲｏＨＣ遷移状態には、ノーコンテキスト（No Context）、スタティックコンテキスト（Static Context）またはフルコンテキスト（Full Context）の３つの状態が存在し、これらの何れかの状態が取得される。
【０１０４】
ＲｏＨＣ遷移状態からフルコンテキストであるか否かが判定され（ステップＳ３０２）、フルコンテキストであれば（ステップＳ３０２のＹＥＳ）、ルータ起動フラグが立っているか（ＯＮ）否かを判定する（ステップＳ３０３）。ルーティング起動フラグがＯＮでなければ（ステップＳ３０３のＮＯ）、ＲｏＨＣルータ制御シーケンスＩ（図１２）を実行する（ステップＳ３０４）。このＲｏＨＣルータ制御シーケンス（ステップＳ３０４）は、ＴＡＦ側のＲｏＨＣルーティングのステップＳ４０１（図１０）と連係されるとともに、ＴＡＦ側のＲｏＨＣルーティングのステップＳ４０４、Ｓ４０５（図１０）と連係する。
【０１０５】
ＲｏＨＣルータ制御シーケンスＩ（ステップＳ３０４：図１２）の処理の後、ＲｏＨＣルータの起動に成功したか否かを判定する（ステップＳ３０５）。ＲｏＨＣルータの起動に成功していれば（ステップＳ３０５のＹＥＳ）、ＩＰヘッダ復元を停止し（ＯＦＦ）、ルータ起動フラグの立上げ（ＯＮ）を行う（ステップＳ３０６）。この場合には、圧縮パケット転送処理を実行する（ステップＳ３０７）。
【０１０６】
ステップＳ３０２において、フルコンテキストでなければ（ステップＳ３０２のＮＯ）、ＩＰヘッダ復元を行い（ＯＮ）、ルータ起動フラグを解除（ＯＦＦ）する（ステップＳ３０８）。この場合には、ＩＰパケット転送処理を実行し（ステップＳ３０９）、圧縮パケット転送処理は行わない。
【０１０７】
ステップＳ３０３において、ルータ起動フラグがＯＮであれば（ステップＳ３０３のＹＥＳ）、圧縮パケット転送処理を実行する（ステップＳ３０７）。
【０１０８】
また、ステップＳ３０５において、ＲｏＨＣルータの起動に失敗した場合には（ステップＳ３０５のＹＥＳ）、ステップＳ３０７に移行し、フルコンテキストでない場合と同様の処理（ステップＳ３０８、Ｓ３０９）を実行する。
【０１０９】
このような処理の後、アプリケーションが終了したか否かが判定され（ステップＳ３１０）、アプリケーションが終了していなければ（ステップＳ３１０のＮＯ）、ステップＳ３０１にリターンする。したがって、斯かる処理がアプリケーションが終了するまで継続的に実行され、アプリケーションの終了により（ステップＳ３１０のＹＥＳ）、この処理を終了する。
【０１１０】
〔ＲｏＨＣルーティング（ＲＲＣ／ＴＡＦ機能部４４側の処理）〕
【０１１１】
図１０に示す処理手順は、本開示のデータ転送方法の一例であって、ＲＲＣ／ＴＡＦ機能部４４側の処理である。この処理手順を開始すると、ＲｏＨＣルータ起動（停止）要求の有無について判定する（ステップＳ４０１）。ＲｏＨＣルータの起動（停止）の要求があれば（ステップＳ４０１のＹＥＳ）、ＲｏＨＣルータ制御シーケンスII（図１３）を実行する（ステップＳ４０２）。ＲｏＨＣルータの起動（停止）の要求がなければ（ステップＳ４０１のＮＯ）、この処理を終了する。このＲｏＨＣルータ制御シーケンスIIはドライバ６０６側のステップＳ５０１、ステップＳ５０４、ステップＳ５０７（図１１）と連係している。
【０１１２】
ＲｏＨＣルータ制御シーケンスIIを実行した場合には、外部ＴＥ６は同意したか否かを判断する（ステップＳ４０３）。外部ＴＥが同意すれば（ステップＳ４０３のＹＥＳ）、ＲｏＨＣルータの起動成功通知を発し（ステップＳ４０４）、この処理を終了する。
【０１１３】
また、外部ＴＥが同意しなければ（ステップＳ４０３のＮＯ）、ＲｏＨＣルータの起動失敗（停止）通知を発し（ステップＳ４０５）、この処理を終了する。
【０１１４】
〔簡易ＲｏＨＣ終端処理（ドライバ６０６側の処理）〕
【０１１５】
図１１に示す処理手順は、本開示のデータ転送方法の一例であって、簡易ＲｏＨＣ終端処理（ドライバ側）の処理である。この処理手順を開始すると、ＲｏＨＣ終端の起動（停止）要求があるか否かを判断する（ステップＳ５０１）。ＲｏＨＣ終端の起動（停止）要求があれば（ステップＳ５０１のＹＥＳ）、ＲｏＨＣルータ制御シーケンスIII （図１４）を実行する（ステップＳ５０２）。ＲｏＨＣルータ終端の起動（停止）の要求がなければ（ステップＳ５０１のＮＯ）、ステップＳ５０８に移行する。
【０１１６】
ＲｏＨＣルータ制御シーケンスIII （図１４）を実行した場合には、ＲｏＨＣ情報を受信したか否かを判断する（ステップＳ５０３）。ＲｏＨＣ情報を受信すれば（ステップＳ５０３のＹＥＳ）、ＲｏＨＣ終端の起動成功通知を発し（ステップＳ５０４）、ＩＰヘッダの復元処理（ＯＮ）を開始し（ステップＳ５０５）、圧縮パケットの解凍処理（３ＧＰＰ準拠）を実行する（ステップＳ５０６）。
【０１１７】
ＲｏＨＣ情報を受信しなければ（ステップＳ５０３のＮＯ）、ＲｏＨＣ終端の起動失敗（停止）通知を発し（ステップＳ５０７）、ＩＰヘッダの復元処理を停止（ＯＦＦ）する（ステップＳ５０８）。この場合、ＩＰパケットの受信処理を行う（ステップＳ５０９）。
【０１１８】
圧縮パケットの解凍処理（ステップＳ５０６）またはＩＰパケットの受信処理（ステップＳ５０９）の後、アプリケーションが終了したか否かを判断する（ステップＳ５１０）。アプリケーションが終了していなければ（ステップＳ５１０のＮＯ）、ステップＳ５０１にリターンし、アプリケーションが終了するまで、既述の処理を継続する。そして、アプリケーションが終了すれば（ステップＳ５１０のＹＥＳ）、この処理を終了する。
【０１１９】
〔ＲｏＨＣルータ制御シーケンスＩ〕
【０１２０】
ＲｏＨＣルータ制御シーケンスＩでは、ＲｏＨＣルータ機能制御（スレーブ）側からの応答がなければ、一定時間経過後、ＲｏＨＣルータを起動しないで、処理を完了させている。
【０１２１】
このＲｏＨＣルータ制御シーケンスＩを開始すると、図１２に示すように、ＲｏＨＣルータ起動要求メッセージを送信し（ステップＳ６０１）、ＲｏＨＣルータ起動応答メッセージの受信があるか否かを判定する（ステップＳ６０２）。
【０１２２】
ＲｏＨＣルータ起動応答メッセージがなければ（ステップＳ６０２のＮＯ）、リトライ処理に移行し、所定時間中ＲｏＨＣルータ起動応答メッセージを監視し、リトライタイマのカウントアップを行う（ステップＳ６０３）。リトライタイマのタイムアウトを監視し（ステップＳ６０４）、リトライタイマがタイムアウトするまで、ＲｏＨＣルータ起動応答メッセージの受信を監視する（ステップＳ６０２）。リトライタイマがタイムアウトすれば（ステップＳ６０４のＹＥＳ）、この処理を終了する。
【０１２３】
そして、ＲｏＨＣルータ起動応答メッセージがあれば（ステップＳ６０２のＹＥＳ）、ＲｏＨＣルータ用転送スイッチをＯＮさせ（ステップＳ６０５）、この処理を終了する。
【０１２４】
〔ＲｏＨＣルータ制御シーケンスII〕
【０１２５】
ＲｏＨＣルータ制御シーケンスIIでは、タイマが切れた段階で処理を終了し、ＬＴＥ側ＲｏＨＣ制御部へ無応答とし、ＲｏＨＣルータを起動させない。
【０１２６】
このＲｏＨＣルータ制御シーケンスIIを開始すると、図１３に示すように、ＲｏＨＣルータ停止要求のメッセージ受信があるか否かを判断する（ステップＳ７０１）。ＲｏＨＣルータ停止要求メッセージの受信があれば（ステップＳ７０１のＹＥＳ）、ＲｏＨＣルータを停止させる（ステップＳ７０２）。
【０１２７】
ＲｏＨＣルータ停止要求メッセージの受信がなければ（ステップＳ７０１のＮＯ）、ＲｏＨＣルータ起動要求メッセージの受信が有るか否かを判断する（ステップＳ７０３）。ＲｏＨＣルータ起動要求メッセージの受信がなければ（ステップＳ７０３のＮＯ）、ステップＳ７０１に戻り、ＲｏＨＣルータ停止要求メッセージの受信の監視（ステップＳ７０１）、ＲｏＨＣルータ起動メッセージ受信の判断（ステップＳ７０３）を行う。
【０１２８】
ＲｏＨＣルータ起動要求メッセージの受信があれば（ステップＳ７０３のＹＥＳ）、ＬＣＰ（Configuration-Ack ：ＲｏＨＣルータ起動応答）としてＲｏＨＣルータ起動要求メッセージを送信する（ステップＳ７０４）。ＬＣＰ：ＲｏＨＣルータ起動応答メッセージの受信の有無を判断し（ステップＳ７０５）、ＲｏＨＣルータ起動応答メッセージの受信がなければ（ステップＳ７０５のＮＯ）、リトライタイマをカウントアップする（ステップＳ７０６）。リトライタイマのタイムアウトを監視し（ステップＳ７０７）、所定時間の経過すなわち、リトライタイマがタイムアウトするまでＲｏＨＣルータ起動応答メッセージの受信を監視する（ステップＳ７０５）。所定時間が経過し、その所定時間内にＲｏＨＣルータ起動応答メッセージが受信できなければ（ステップＳ７０７のＹＥＳ）、この処理を終了する。
【０１２９】
ＲｏＨＣルータ起動応答メッセージの受信があれば（ステップＳ７０５のＹＥＳ）、ＬＣＰ：ＩＰヘッダ受取要求メッセージを送信する（ステップＳ７０８）。ＬＣＰ：受け取り完了応答メッセージの受信の有無を判断し（ステップＳ７０９）、受け取り完了応答メッセージの受信がなければ（ステップＳ７０９のＮＯ）、リトライタイマをカウントアップする（ステップＳ７１０）。リトライタイマのタイムアウトを監視し（ステップＳ７１１）、所定時間の経過すなわち、リトライタイマがタイムアウトするまで受け取り応答メッセージの受信を監視する（ステップＳ７０９）。所定時間が経過し、その所定時間内に受け取り完了応答メッセージが受信できなければ（ステップＳ７１１のＹＥＳ）、この処理を終了する。
【０１３０】
そして、受け取り完了応答メッセージの受信があれば（ステップＳ７０９のＹＥＳ）、ＲｏＨＣルータ起動応答メッセージを送信し（ステップＳ７１２）、この処理を終了する。
【０１３１】
〔ＲｏＨＣルータ制御シーケンスIII 〕
【０１３２】
ＲｏＨＣルータ制御シーケンスIII では、応答しない場合にはタイマが切れた段階で処理を終了し、ＴＡＦ側ＲｏＨＣルーティング部へ無応答とし、ＲｏＨＣルータを起動させない。
【０１３３】
このＲｏＨＣルータ制御シーケンスIII を開始すると、図１４に示すように、ＬＣＰ：ＲｏＨＣルータ停止要求メッセージの受信があるか否かを判断する（ステップＳ８０１）。ＲｏＨＣルータ停止要求メッセージの受信があれば（ステップＳ８０１のＹＥＳ）、ＲｏＨＣルータを停止させる（ステップＳ８０２）。
【０１３４】
ＲｏＨＣルータ停止要求メッセージの受信がなければ（ステップＳ８０１のＮＯ）、ＬＣＰ：ＲｏＨＣルータ起動要求メッセージの受信があるか否かを判断する（ステップＳ８０３）。ＲｏＨＣルータ起動要求メッセージの受信がなければ（ステップＳ８０３のＮＯ）、ステップＳ８０１に戻り、ＲｏＨＣルータ停止要求メッセージ又はＲｏＨＣルータ起動要求メッセージの受信を監視する（ステップＳ８０１、Ｓ８０３）。
【０１３５】
ＲｏＨＣルータ起動要求メッセージの受信があれば（ステップＳ８０３のＹＥＳ）、〈ＬＣＰ〉ＲｏＨＣルータ起動応答メッセージを送信する（ステップＳ８０４）。この送信の後、ＬＣＰ：ＩＰヘッダ受け取り要求メッセージを受信したか否かを判断する（ステップＳ８０５）。
【０１３６】
ＬＣＰ：ＩＰヘッダ受け取り要求メッセージの受信がなければ（ステップＳ８０５のＮＯ）、リトライタイマをカウントアップする（ステップＳ８０６）。リトライタイマのタイムアウトを監視し（ステップＳ８０７）、所定時間の経過すなわち、リトライタイマがタイムアウトするまで受け取り要求メッセージの受信を監視する（ステップＳ８０５）。所定時間が経過し、その所定時間内に受け取り完了要求メッセージが受信できなければ（ステップＳ８０７のＹＥＳ）、この処理を終了する。
【０１３７】
ＬＣＰ：ＩＰヘッダ受け取り要求メッセージの受信があれば（ステップＳ８０５のＹＥＳ）、ＩＰヘッダ情報を保存（ＲｏＨＣ準拠）する（ステップＳ８０８）。そして、ＲｏＨＣ解凍機能をＯＮ（ＲｏＨＣ準拠）させ（ステップＳ８０９）、〈ＬＣＰ〉受け取り完了応答メッセージを送信し（ステップＳ８１０）、この処理を終了する。
【０１３８】
〔ＲｏＨＣルータ４５２のデータ転送（ＲｏＨＣルータ４５２がＯＦＦの場合）〕
【０１３９】
ＲｏＨＣルータがＯＦＦの場合のデータ転送について、図１５を参照する。図１５はＲｏＨＣルータのデータ転送例を示している。
【０１４０】
ダウンリンク（ＤＬ）ではデータがＵＥ４から外部ＴＥ６に転送される。ＵＥ４のＣＰＵコア３１では、ＲｏＨＣ機能制御（マスター）４３２がＲｏＨＣ機能部（３ＧＰＰ規格準拠）５２に状態ポーリングを実施し、フルコンテキスト以外の場合、ＲｏＨＣルータ４２５をＯＦＦに切り替える。
【０１４１】
ＲｏＨＣルータ４２５がＯＦＦであれば、ＣＰＵコア３１では、ＲｏＨＣヘッダ５０５をＰＤＣＰ−ＳＵＤ（ＰＤＣＰレイヤーペイロード）で圧縮ヘッダの解凍処理をする。つまり、圧縮ヘッダであるＲｏＨＣヘッダ５０５はＩＰヘッダ、ＵＰＤヘッダ、ＲＴＰヘッダに解凍される。このため、ＩＰヘッダ５０４、ＵＰＤヘッダ５０３およびＲＴＰヘッダ５０２が付されたペイロード５０１で構成される。ペイロード５０１はたとえば、画像データである。
【０１４２】
スイッチ４３０は、ＲｏＨＣルータ４２５がＯＦＦであるため、ＩＰヘッダ５０４、ＵＰＤヘッダ５０３およびＲＴＰヘッダ５０２を付加されたペイロード５０１（画像データ）を疎通させ、ＣＰＵコア３２に転送する。ＣＰＵコア３２側のＲｏＨＣルータ４４１は、ＣＰＵコア３１側のＲｏＨＣルータ４２５がＯＦＦに連動してＯＦＦとなる。このため、ＣＰＵコア３２ではデータ転送に対して素通し状態となり、ＩＰヘッダ５０４、ＵＰＤヘッダ５０３およびＲＴＰヘッダ５０２を付加された画像データがそのまま外部ＴＥ６のドライバ６０６に転送される。
【０１４３】
〔ＲｏＨＣルータ４２５のデータ転送（ＲｏＨＣルータ４２５がＯＮの場合）〕
【０１４４】
ＲｏＨＣルータ４２５がＯＮの場合のデータ転送について、図１６を参照する。図１６はＲｏＨＣルータのデータ転送例を示している。図１６において、図１５と同一部分には同一符号を付してある。
【０１４５】
ダウンリンク（ＤＬ）ではデータがＵＥ４から外部ＴＥ６に転送されることは既述の通りである。ＵＥ４のＣＰＵコア３１では、ＲｏＨＣ機能制御（マスター）４３２がＲｏＨＣ機能部（３ＧＰＰ規格準拠）５２に状態ポーリングを実施し、フルコンテキストであれば、ＲｏＨＣルータ４２５をＯＮに切り替える。
【０１４６】
ＲｏＨＣルータ４２５がＯＮであれば、ＣＰＵコア３１は、圧縮ヘッダであるＲｏＨＣヘッダ５０５の解凍処理を停止する。つまり、ＲｏＨＣヘッダ５０５はそのままの状態で維持される。この場合、データはＲｏＨＣヘッダ５０５が付されたペイロード５０１で構成される。この場合、ペイロードは一例として画像データである。
【０１４７】
スイッチ４３０は、ＲｏＨＣルータ４２５がＯＮであるため、ＲｏＨＣヘッダを付加された画像データを疎通させ、ＣＰＵコア３２に転送する。ＣＰＵコア３２側のＲｏＨＣルータ４４１は、ＣＰＵコア３１側のＲｏＨＣルータ４２５がＯＮに連動してＯＮに切り替えられる。このため、ＣＰＵコア３２ではデータ転送に対して素通し状態となり、ＲｏＨＣヘッダ５０５を付加された画像データ（ペイロード５０１）がそのまま外部ＴＥ６のドライバ６０６に転送される。
【０１４８】
ＲｏＨＣヘッダ５０５およびペイロード５０１が提供されたドライバ６０６では、ＲｏＨＣ解凍処理機能部６０９がＲｏＨＣヘッダ５０５をＩＰヘッダ、ＵＰＤヘッダおよびＲＴＰヘッダに解凍する。
【０１４９】
このように、ＲｏＨＣルータ４２５がＯＮの場合には、スイッチ４３０を切り替え、ＬＴＥ機能部４２側のＲｏＨＣ機能部５２は、圧縮ヘッダであるＲｏＨＣヘッダ５０５の解凍を停止する。圧縮ヘッダであるＲｏＨＣヘッダは、そのままドライバ６０６に転送される。ドライバ６０６ではＲｏＨＣヘッダ５０５のフルコンテキストでの解凍のみを実施する。このＲｏＨＣヘッダ５０５の解凍処理はＲｏＨＣ規格に準拠する。この場合、ヘッダ情報は、通常のＲｏＨＣで保存するＩＰ／ＵＤＰ／ＲＴＰなどのヘッダ情報の全てである。
【０１５０】
〔ハードウェア構成〕
【０１５１】
通信システム２のハードウェアについて、図１７を参照する。図１７は通信システムのハードウェアの一例を示している。図１７において、図３と同一部分には同一符号を付してある。
【０１５２】
図１７に示す通信システム２では、ＵＥ４がたとえば、携帯電話機で構成され、外部ＴＥ６がＰＣで構成され、これらがＵＳＢケーブル２８により有線接続されている。
【０１５３】
ＵＥ４はＬＴＥ無線（ＲＦ）部２６と、ベースバンド処理（ＢＢ）部７０と、表示部７２と、音声入出力部７４と、プロセッサ７６と、記憶部７８と、外部ＴＥインターフェース部８０を有し、既述のパケットデータを送受するモデムを構成する。
【０１５４】
ＲＦ部２６は送受信用のアンテナ２７を備え、既述のＢＳ２２などの各基地局と無線電波の送受信を行う。ＢＢ部７０はプロセッサ７６により制御され、データ信号や音声信号により搬送信号を変調し、または、ＲＦ部２６の受信信号からデータ信号や音声信号を復調する。表示部７２はたとえば、ＬＣＤ（Liquid Crystal Display）で構成し、送信データや受信データを視認可能な文字や記号などの情報として提示する。音声入出力部７４は、マイクロフォンからの音声信号の入力処理、受信信号から復調された音声信号を音声として再生する。
【０１５５】
プロセッサ７６は、記憶部７８に格納されているＯＳ（Operating System）やアプリケーションプログラムを実行し、既述のパケット通信方法を実現する。このプロセッサ７６は既述のＣＰＵコア３１、３２で構成される。記憶部５８は、ＲＯＭ（Read-Only Memory）７８２とＲＡＭ（Random-Access Memory）７８４を有し、プログラム記憶部やデータ記憶部を構成している。プログラム記憶部には既述のＯＳや、パケット通信方法を実現するプログラムが格納されている。ＲＡＭ７８４は、受信したパケットデータの格納や、ワークエリアに用いられる。既述の共有メモリ５４はこの記憶部７８によって構成される。この記憶部７８はたとえば、ＦｌａｓｈＲＯＭなどの半導体メモリなどの記録媒体で構成する。各種処理時間を監視するリトライタイマ８２がプロセッサ７６に接続されている。
【０１５６】
外部ＴＥインターフェース部８０は外部装置との接続手段であり、たとえば、ＵＳＢ入出力部８０２を備え、このＵＳＢ入出力部８０２にはＵＳＢケーブル２８を介して外部ＴＥ６が接続されている。
【０１５７】
外部ＴＥ６はデータ端末装置またはパケット処理装置の一例であって、ＰＣ（パーソナルコンピュータ）やモデムで構成される。図１７に示す外部ＴＥ６は、インターフェース部８４と、プロセッサ８６と、記憶部８８を有する。
【０１５８】
インターフェース部８４は外部装置との接続手段であり、たとえば、ＵＳＢ入出力部８４２を備え、このＵＳＢ入出力部８４２には既述のＵＳＢケーブル２８を介してＵＥ４が接続されている。
【０１５９】
プロセッサ８６は、記憶部８８に格納されているＯＳ（Operating System）やアプリケーションプログラムを実行し、既述のパケット通信方法を実現する。ダウンリンク（ＤＬ）の場合、ＵＥ４から転送された圧縮パケットからＩＰパケットをデコードする。
【０１６０】
記憶部８８は、ＨＤＤ（Hard Disk Drive ）８８２とＲＡＭ（Random-Access Memory）８８４を有し、プログラム記憶部やデータ記憶部を構成している。プログラム記憶部はＨＤＤ８８２で構成される。このプログラム記憶部には既述のＯＳや、パケット通信方法を実現するプログラム、既述のドライバ６０６を格納している。ＲＡＭ８８４は、受信したパケットデータの格納や、ワークエリアに用いられる。この記憶部８８はＨＤＤ装置やＦｌａｓｈＲＯＭなどの半導体メモリなどの記録媒体で構成する。
【０１６１】
次に、ＲｏＨＣのヘッダ圧縮時の構成について、図１８を参照する。図１８のＡは既述のＵＯ−０パケット、図１８のＢは既述のＵＯ−１パケット、図１８のＣは既述のＵＯＲ−２パケットを示している。
【０１６２】
ＵＯ−０パケットは、図１８のＡに示すように、ヘッダ部にＳＮ（Sequence Number ：シーケンス番号）ビットと、ＣＲＣ（Cyclic Redundancy Check ：巡回冗長検査）ビットを有する。ＳＮビットはデータの順序を示す。ＣＲＣビットはビット構成の正否のチェックに用いられる。ＳＮビットは４ビット、ＣＲＣビットは３ビットであり、１オクテッドで構成される。また、ペイロード５０１も１オクテッドデータである。
【０１６３】
ＵＯ−１パケットは、図１８のＢに示すように、ヘッダ部にＵＯ−０の構成に加え、“１０”（２bits）、ＴＳ（Time Stamp：タイムスタンプ）ビットおよびＭ（Marker：標識）ビットを有する。ＴＳビットは時間情報を表す。また、Ｍビットは、データの境界を表す。
【０１６４】
ＵＯＲ−２パケットは、図１８のＣに示すように、ヘッダ部にＵＯ−１の構成に加え、“１１０”（３bits）、ＳＮ（６bits）、ＴＳ〔ＭＳＢ（Most Significant Bit）：５bits〕およびＸ（Extension ：拡張）ビットを有する。
【０１６５】
次に、ヘッダ圧縮の比率について、図１９を参照する。図１９は最大圧縮時のヘッダ圧縮の比率を示している。
【０１６６】
プロトコルヘッダがＩＰ／ＴＣＰの場合、通常時ヘッダサイズ（バイト）は、４０〔byte〕であるのに対し、ＲｏＨＣ圧縮時サイズは４〔byte〕に圧縮される。この場合、圧縮率〔％〕＝（４０−４／４０）×１００＝９０〔％〕となる。
【０１６７】
プロトコルヘッダがＩＰ／ＵＤＰの場合、通常時ヘッダサイズ（バイト）は、２８〔byte〕であるのに対し、ＲｏＨＣ圧縮時サイズは１〔byte〕に圧縮される。この場合、圧縮率〔％〕＝（２８−１／２８）×１００＝９６．４〔％〕となる。
【０１６８】
プロトコルヘッダがＩＰ／ＵＤＰ／ＲＴＰの場合、通常時ヘッダサイズ（バイト）は、４０〔byte〕であるのに対し、ＲｏＨＣ圧縮時サイズは１〔byte〕に圧縮される。この場合、圧縮率〔％〕＝（４０−１／４０）×１００＝９７．５〔％〕となる。
【０１６９】
このような圧縮率から明らかなように、圧縮パケットを利用すれば、データの転送速度を高め、効率的な通信が可能となるとともに、ネットワーク資源の有効利用に資することになる。
【０１７０】
〔実施の形態の効果〕
【０１７１】
(1) ＲｏＨＣルータとしてＲｏＨＣ実施時に圧縮ＩＰパケットをそのまま疎通させる機能を備えているので、圧縮ヘッダパケットをＵＥ４から外部ＴＥ６に疎通させることができ、ＵＥ４側のデータ処理の軽減と、スループットを向上させることができる。
【０１７２】
(2) 外部ＴＥ６内にＲｏＨＣルータ終端機能を備えているので、ＵＥ４から転送された圧縮ヘッダパケットから元パケットを復元することができる。
【０１７３】
(3) ＲｏＨＣルータ終端では、ダウンリンク（ＤＬ）で圧縮ヘッダパケットを圧縮動作ネゴシエーション完了時に保存しているＩＰヘッダを用いて容易に復元することができ、外部ＴＥ６側のデータ処理を軽減できる。
【０１７４】
(4) 通信ベアラでＲｏＨＣがサポートされた場合、保存しているＩＰヘッダ情報に基づいた転送先に送信することができる。
【０１７５】
〔他の実施の形態〕
【０１７６】
(1) 上記実施の形態では、ＵＥ４と外部ＴＥ６とをケーブル２８で有線接続したが、これらの接続形態は有線接続に限定されない。無線接続としてもよく、たとえば、ブルートゥース接続であってもよい。このブルートゥース接続では、図２０に示すように、ＵＥ４のＲＲＣ／ＴＡＦ機能部４４にインターフェースとしてBluetooth （Ｌ２）４９１、Bluetooth （Ｌ１）４９２を備える。これに対応し、外部ＴＥ６のアプリケーション機能部４６にインターフェースとしてBluetooth （Ｌ２）５１１、Bluetooth （Ｌ１）５１２を備えればよい。この場合、ＵＥ４側にはBluetooth 用のアンテナ９１、外部ＴＥ６側には同様のアンテナ９２が備えられ、Bluetooth 規格の電波の送受信が行われる。このような無線接続によっても、ＵＥ４を疎通した圧縮ヘッダを外部ＴＥ６へ転送し、外部ＴＥ６側で元ヘッダに伸長させることができる。
【０１７７】
(2) 上記実施の形態では、ＢＳ２２とＵＥ４との無線接続のプロトコルにＬＴＥの通信規格を用いたが、これに限定されない。たとえば、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access ：高速モバイル通信）を用いてもよい。この場合、図２１に示すように、ＷｉＭＡＸＲＦ部２９が用いられ、ＢＳ２２およびＬＴＥ機能部４２のプロトコルにはそれぞれＭＡＣ２５０、４２０が用いられる。ＢＳ２２はＷｉＭＡＸ−Ｌ１機能部２４９、ＵＥ４のＬＴＥ機能部４２にＷｉＭＡＸ−Ｌ１機能部４１９を備え、ＷｉＭＡＸによる通信接続であってもよい。
【０１７８】
(3) 上記実施の形態では、ＢＳ２２とＵＥ４とを無線接続しているが、ＢＳ２２とＵＥ４との間に他の通信機器を介在して通信を行う構成であってもよい。
【０１７９】
(4) 既述のＵＥ４に例示した機能はＬＴＥ用カード端末において適用できる。
【０１８０】
〔比較例〕
【０１８１】
比較例について、図２２および図２３を参照する。図２２は比較例のプロトコル構成を示している。図２３はパケット構造を示している。
【０１８２】
図２２に示す通信システム２００は、既述の通信システム２（図３）と同様にＵＥ４とＢＳ２２との間で圧縮ヘッダパケットを送信または受信する構成である。図２２のＡはＬＴＥの通信規格によるハードウェア構成であり、図２２のＢはプロトコル構成である。これらの構成は、既述の通信システム２と同様であるが、ＲｏＨＣルータ４２５、４４１を備えていない点で相違している。
【０１８３】
この比較例の通信システム２００では、ＳＳ２４とＵＥ４００との間でＲｏＨＣによりヘッダ圧縮が行われる。このため、ＢＳ２２からＵＥ４００に向かうダウンリンク（ＤＬ）では、ＢＳ２２からＵＥ４００に圧縮ヘッダパケット５０が送信される。このパケット構成は、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダを圧縮したＲｏＨＣヘッダと、ペイロードで構成されている。
【０１８４】
この圧縮ヘッダパケット５０は、ＵＥ４００でＩＰパケットルーティング処理により解凍され、実サイズのＩＰパケットにデコードされる。この実サイズのＩＰパケットがＵＥ４００と外部ＴＥ６００との間で送受信される。
【０１８５】
ＬＴＥやＷｉＭＡＸ（Worldwide Interoperability for Microwave Access ）で採用されているＲｏＨＣは、ペイロードが大きくないＩＰパケットでは非常に有効である。ペイロードが大きくないＩＰパケットは例えば、ＶｏＩＰ（Voice over Internet Protocol：ＩＰ接続ネットワークの音声通話）などである。
【０１８６】
この比較例の通信システム２００ではつぎのような課題がある。これらの課題は上記実施の形態で解決されている。
【０１８７】
(1) 外部ＴＥ６００〜ＵＥ４００間で、圧縮ヘッダをＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダに解凍し、実サイズのＩＰパケットをそのまま送受信する場合には、ＵＥ４００や外部ＴＥ６００の負担が増大する。ＵＥ４００では、ＢＳ２２の応答用ＬＴＥ機能と、外部ＴＥ６用のモデム機能とが必要であり、ＩＰヘッダ圧縮を伴うＩＰパケット転送と、ＩＰパケット転送の間でヘッダ情報の転送を行う。つまり、ＵＥ４００には外部ＴＥ６００に対するＩＰパケット送受信に合わせた圧縮パケットの解凍（伸長）処理が必要である。
【０１８８】
(2) ＵＥ４００ではＰＰＰ（Point to Point Protocol ：２点間接続用プロトコル）が使用される場合には、最悪の場合、パケット構成が２倍のデータ転送量となり、スループットに悪影響を及ぼしている。
【０１８９】
(3) ＵＥ４００を外部ＴＥ６００のモデムとして利用する場合には、ＵＥと外部ＴＥの間でもＵＳＢなどの転送プロトコルが必要であり、このため、ルータとして機能させるＵＥでは上位層のＩＰパケット転送を圧縮せずに転送している。
【０１９０】
(4) ＵＥ４００が、基地局応答用ＬＴＥ機能となるＩＰヘッダ圧縮によるＩＰパケット転送と、外部ＴＥ用モデム機能となるＩＰパケット転送の間で、省略可能なヘッダ情報を転送している。このため、ＵＥ４００では外部ＴＥ６００とのＩＰパケット送受信に合わせるため圧縮パケットを解凍（伸長）していた。
【０１９１】
以上説明したように、通信端末およびデータ転送方法の最も好ましい実施の形態等について説明したが、本発明は、上記記載に限定されるものではなく、特許請求の範囲に記載され、又は発明を実施するための形態に開示された発明の要旨に基づき、当業者において様々な変形や変更が可能であることは勿論であり、斯かる変形や変更が、本発明の範囲に含まれることは言うまでもない。
【符号の説明】
【０１９２】
２  通信システム
４  ＵＥ（通信端末）
６  外部ＴＥ（データ端末装置）
８  受信機能
１０  状態圧縮機能
１２  圧縮ヘッダ疎通機能
１４  ヘッダ復元機能
【図１】
0005609728.tif 000002
【図２】
0005609728.tif 000003
【図３】
0005609728.tif 000004
【図４】
0005609728.tif 000005
【図５】
0005609728.tif 000006
【図６】
0005609728.tif 000007
【図７】
0005609728.tif 000008
【図８】
0005609728.tif 000009
【図９】
0005609728.tif 000010
【図１０】
0005609728.tif 000011
【図１１】
0005609728.tif 000012
【図１２】
0005609728.tif 000013
【図１３】
0005609728.tif 000014
【図１４】
0005609728.tif 000015
【図１５】
0005609728.tif 000016
【図１６】
0005609728.tif 000017
【図１７】
0005609728.tif 000018
【図１８】
0005609728.tif 000019
【図１９】
0005609728.tif 000020
【図２０】
0005609728.tif 000021
【図２１】
0005609728.tif 000022
【図２２】
0005609728.tif 000023
【図２３】
0005609728.tif 000024