(57)【要約】【課題】  ヘッダ圧縮技術を用いて送信されたパケットを終端するために必要なメモリ容量が従来よりも小さいヘッダ圧縮パケット処理装置を提供する。【解決手段】  ＰＰＰフレーム受信部１０１は、受信したパケット中のヘッダが圧縮ヘッダであるかフルヘッダであるかを判断し、フルヘッダを含むパケットについては、ＵＤＰ／ＩＰ受信部１０３においてフルヘッダに含まれるセッション情報とセッション情報記憶部１０４に格納されているセッション情報とを比較して、該フルヘッダが付与されているユーザデータの受け渡し先となるアプリケーションを選択し、圧縮ヘッダが付加されているユーザデータついては、疑似ＵＤＰ受信部１０５において、圧縮ヘッダ中のコンテキスト識別子に関連づけられたセッション情報をセッション情報記憶部１０４から読み出し、該読み出したセッション情報に基づいて、圧縮ヘッダが付加されていたユーザデータを受け渡すアプリケーションを決定する。【選択図】  図１
2005252855.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザデータに分割され、圧縮ヘッダ又はフルヘッダが付加された上で送信されてきたパケットを受信し、該ユーザデータを前記圧縮ヘッダ又は前記フルヘッダによって示される特定のアプリケーションに受け渡すヘッダ圧縮パケット処理装置であって、
前記ユーザデータの受け渡し先を特定するためのセッション情報が格納されたセッション情報格納手段と、
前記セッション情報を特定するための識別情報とコンテキスト識別子とを関連づけて記憶するコンテキスト情報記憶手段とを有し、
前記パケットを受信した際には、これに付加されているヘッダが圧縮ヘッダであるかフルヘッダであるかを判断し、
前記フルヘッダが付加されているユーザデータについては、該フルヘッダに含まれる情報と前記セッション情報格納手段に格納されているセッション情報とを比較して、該フルヘッダが付与されているユーザデータの受け渡し先となるアプリケーションを選択するとともに、前記セッション情報を特定するための前記識別情報と、前記フルヘッダ中の前記コンテキスト識別子とを関連づけて記憶し、
前記圧縮ヘッダが付加されているユーザデータついては、
前記圧縮ヘッダから前記コンテキスト識別子を抽出し、
前記抽出したコンテキスト識別子に関連付けられた前記識別情報を前記コンテキスト情報記憶手段から読み出し、
前記読み出した識別情報で特定されるセッション情報を前記セッション情報格納手段から読み出し、
該読み出したセッション情報に基づいて、前記圧縮ヘッダが付加されていたユーザデータを受け渡すアプリケーションを決定することを特徴とするヘッダ圧縮パケット処理装置。
【請求項２】
前記圧縮ヘッダと前記セッション情報格納手段から読み出したセッション情報とを基にして誤り検出可能な情報を含んだ疑似ヘッダを生成し、前記圧縮ヘッダが付与されていたユーザデータに対して前記疑似ヘッダを用いて誤り検出処理を行うことを特徴とする請求項１記載のヘッダ圧縮パケット処理装置。
【請求項３】
前記セッション情報は、ＩＰアドレスとトランスポート層ポート番号との組合せであることを特徴とする請求項１又は２記載のヘッダ圧縮パケット処理装置。
【請求項４】
前記アプリケーションのいずれかから取得したユーザデータに対してフルヘッダ又は圧縮ヘッダを付加する手段と、
前記フルヘッダ又は圧縮ヘッダを付加したユーザデータを、他の装置へ送信する手段とを有することを特徴とする請求項１から３のいずれか１項記載のヘッダ圧縮パケット処理装置。
【請求項５】
複数のユーザデータに分割され、圧縮ヘッダ又はフルヘッダが付加された上で送信されてきたパケットを受信し、該ユーザデータを前記圧縮ヘッダ又は前記フルヘッダによって示される特定のアプリケーションに受け渡すヘッダ圧縮パケット処理方法であって、
前記パケットを受信した際には、これに付加されているヘッダが圧縮ヘッダであるかフルヘッダであるかを判断し、
前記フルヘッダが付加されているユーザデータについては、ユーザデータの受け渡し先を特定するための情報であり、該フルヘッダに含まれているセッション情報に基づいて、前記ユーザデータの受け渡し先となるアプリケーションを選択するとともに、前記セッション情報を特定するための識別情報と、前記フルヘッダ中のコンテキスト識別子とを関連づけて記憶し、
前記圧縮ヘッダが付加されているユーザデータついては、前記圧縮ヘッダから前記コンテキスト識別子を抽出し、前記抽出したコンテキスト識別子に関連づけられた識別情報を読み出し、前記読み出した識別情報に基づいて、前記セッション情報を読み出し、該読み出したセッション情報に基づいて、前記圧縮ヘッダが付加されていたユーザデータを受け渡すアプリケーションを決定することを特徴とするヘッダ圧縮パケット処理方法。
【請求項６】
前記圧縮ヘッダと前記読み出したセッション情報とを基にして誤り検出可能な情報を含んだ疑似ヘッダを生成し、前記圧縮ヘッダが付与されていたユーザデータに対して前記疑似ヘッダを用いて誤り検出処理を行うことを特徴とする請求項５記載のヘッダ圧縮パケット処理方法。
【請求項７】
前記セッション情報は、ＩＰアドレスとトランスポート層ポート番号との組合せであることを特徴とする請求項５又は６記載のヘッダ圧縮パケット処理方法。
【請求項８】
前記アプリケーションのいずれかから取得したユーザデータに対してフルヘッダ又は圧縮ヘッダを付加し、
前記フルヘッダ又は圧縮ヘッダを付加したユーザデータを、他の装置へ送信することを特徴とする請求項５から７のいずれか１項記載のヘッダ圧縮パケット処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はヘッダ圧縮技術を用いて送信されてきたパケットデータを処理するヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法に関する。
【背景技術】
【０００２】
近年、ネットワークを介して情報を送受信する際には、対象となる音声又は画像データなどを分割した複数の「ユーザデータ」にそれぞれヘッダを付加し「パケット」化して送受信する方法が主流となっている。
【０００３】
ＩＰ網（いわゆるインターネット）上でパケットを送受信する際には、ＩＰ（Internet Protocol ）が通信プロトコルとして使用される。ＩＰのヘッダは、ＩＰｖ４（Internet Protocol version 4 ）の場合は２０バイト、ＩＰｖ６（Internet Protocol version 6 ）の場合は４０バイトのデータ量である。
これらのヘッダのデータ量は、ユーザデータの大きさに関わらず一定であるため、ユーザデータのデータ量が小さい場合には、パケットの大部分をヘッダが占めることとなる。
【０００４】
例えば、ＩＰ網上で音声データを転送するVoice over IP 技術では、ＩＰヘッダの後に８バイトのＵＤＰ（User Datagram Protocol）ヘッダと、１２バイトのＲＴＰ（Real-time Transport Protocol）ヘッダが続き、その後に音声データが格納される。音声データが１０バイトの場合、ＩＰｖ６ではＲＴＰ／ＵＤＰ／ＩＰヘッダが合計で６０バイトであるから、パケット全体の８０％以上をヘッダが占めることとなる。
【０００５】
パケットのヘッダの部分は、ユーザデータとは異なり本来は送受信の対象ではないため、パケット中でヘッダが占める割合が大きくなることは好ましいことではない。
このため、低速回線上でＩＰパケットを転送する際には、特許文献１に開示される「ヘッダ圧縮パケット受信装置及び方法」のように、圧縮ヘッダを用いることによって伝送するデータ量を低減する手法が適用されることも多い。
【０００６】
圧縮ヘッダとは、ヘッダ本来の情報のうち固定的な情報を除いて構成したヘッダである。ヘッダ圧縮の方式には、ＩＥＴＦ（Internet Engineering Task Force ）で規定された複数の種類が存在するが、基本的な考え方はＲＦＣ１１４４“Compressing TCP/IP Headers for Low-Speed Serial Links ”においてVan Jacobsonによって提案された方式を基にしている。これは、同一のフロー（ＩＰアドレスとトランスポート層ポート番号との組合せが同一のパケット群）のデータストリームにおいては、ヘッダ中のフィールドのほとんどが不変であるという特徴を利用するものである。
【０００７】
上記のような圧縮ヘッダを用いる手法では、通常のヘッダとほぼ同様の構成であるフルヘッダは散発的に付加し、それ以外のパケットに対しては圧縮ヘッダを付加することで伝送する情報量を低減する。なお、フルヘッダには、ヘッダ全体の情報の他に、フローを特定するための識別情報（コンテキストＩＤ：Context Identifier  以下、ＣＩＤという）が含まれる。一方、圧縮ヘッダには、通常のヘッダ中の可変情報及びＣＩＤのみが含まれる。
【０００８】
上記のＲＦＣ１１４４は、ＴＣＰ／ＩＰのみを対象とした圧縮方法であったが、これを拡張してＵＤＰ／ＩＰやＲＴＰ／ＵＤＰ／ＩＰにも対応させた方式が、ＲＦＣ２５０７“IP Header Compression ”やＲＦＣ２５０８“Compressing IP/UDP/RTP Headers for Low-Speed Serial Links ”として提案されている。ＲＦＣ２５０７では、ＵＤＰ／ＩＰｖ６の６０バイトのパケットを２〜４バイトにまで圧縮することが可能である。
【０００９】
図１３に、従来のヘッダ圧縮パケット受信装置の構成を示す。ヘッダ圧縮パケット受信装置６００は、ＰＰＰフレーム受信部６０１、ヘッダ圧縮受信処理部６０２、ＵＤＰ／ＩＰ受信処理部６０３、セッション情報記憶部６０４及びユーザデータ出力部６０５を有する。
【００１０】
図１４及び図１５に、ヘッダ圧縮パケット受信装置６００の各部の詳細な構成を示す。
ＰＰＰフレーム受信部６０１は、外部装置から送信されてきたＰＰＰフレームを受信し、その中に含まれるＰＰＰヘッダを解析する。ＰＰＰフレーム受信部６０１は、ＰＰＰヘッダを解析することにより、パケットに付加されているヘッダがフルヘッダであるか圧縮ヘッダであるかを判断する。
【００１１】
ヘッダ圧縮受信処理部６０２は、フルヘッダ受信部６０２１、コンテキスト情報記憶部６０２２及び圧縮ヘッダ受信部６０２３を有する。
【００１２】
フルヘッダ受信部６０２１には、フルヘッダが付加されたデータがＰＰＰフレーム受信部６０１から受け渡される。フルヘッダ受信部６０２１は、フルヘッダから「ＣＩＤ」を取り出し、ＣＩＤとＵＤＰ／ＩＰヘッダ情報とをコンテキスト情報記憶部６０２２へ記憶させた後、フルヘッダのレングスフィールドに受信したデータ長から計算したパケット長やデータグラム長などの値を書き込んで通常のＵＤＰ／ＩＰヘッダの形に変換し、パケットをＵＤＰ／ＩＰ受信処理部６０３へと受け渡す。
【００１３】
圧縮ヘッダ受信部６０２３には、圧縮ヘッダを付加されたデータがＰＰＰフレーム受信部６０１から受け渡される。圧縮ヘッダ受信部６０２３は、圧縮ヘッダから取り出したＣＩＤを用いて、コンテキスト情報記憶部６０２２に問い合わせる。圧縮ヘッダ受信部６０２３は、コンテキスト情報記憶部６０２２から取得したヘッダ情報を用いてＵＤＰ／ＩＰヘッダを復元した後、パケットを図１５に示すＵＤＰ／ＩＰ受信処理部６０３に転送する。ＵＤＰ／ＩＰヘッダの復元の際には、ユーザデータ長にヘッダ長を加えた値をレングスとし、圧縮ヘッダの中の値をＵＤＰチェックサムとして記入する。
【００１４】
コンテキスト情報記憶部６０２２は、フルヘッダ受信部６０２１から受け渡された「ＣＩＤ」と「ＵＤＰ／ＩＰヘッダ情報」とを関連づけて記憶する。また、圧縮ヘッダ受信部６０２３からの問い合わせに応じて、指定されたＣＩＤに対応するヘッダ情報を圧縮ヘッダ受信部６０２３に受け渡す。
なお、ＵＤＰ／ＩＰヘッダ情報とは、圧縮ヘッダからコンテキストに対応するＵＤＰ／ＩＰヘッダを復元するために必要な情報であり、例えば、送信元及び宛先それぞれのＩＰアドレス及びＵＤＰポート番号である。ＩＰアドレスのデータ量はＩＰｖ６の場合１２８ビット、ＵＤＰポート番号のデータ量は１６ビットであるため、コンテキスト情報記憶部は、ＣＩＤ一つ当たり少なくとも（１２８＋１６）×２＝２８８ビット＝３６バイトのフィールドを備える必要がある。
【００１５】
なお、コンテキスト情報記憶部６０２２のフィールドは個々のＵＤＰセッション（ＩＰアドレスとＵＤＰポート番号との組合せ）に対して固定的に割り当てる必要はない（換言すると、ＵＤＰセッションの数がコンテキスト記憶部のフィールド数（コンテキストの収容数ともいう）よりも多くても良い）。ただし、あるＵＤＰセッションが割り当てられているフィールドに別のＵＤＰセッションを割り当てる場合には、送信側の装置はフルヘッダのパケットを送信する必要がある。よって、あるフィールドに対するＵＤＰセッションの割当てが頻繁に変更されると、圧縮ヘッダが付加されたパケットが伝送される回数が減ってしまう。このため、一般には、コンテキストの収容数を大きくすることで、コンテキスト記憶部６０２２のフィールドとＵＤＰセッションとの関係を長い時間持続させてヘッダ圧縮の効果を高めている。
【００１６】
ＵＤＰ／ＩＰ受信処理部６０３は、ＩＰ受信部６０３１及びＵＤＰ受信部６０３２からなる。
ＩＰ受信部６０３１は、ＩＰヘッダ中のＩＰアドレスを取り出し、上位のプロトコルがＵＤＰであればパケットをＵＤＰ受信部６０３２へと受け渡す。
ＵＤＰ受信部６０３２は、ＵＤＰヘッダから取り出したポート番号と、ＩＰ受信部から渡されたＩＰアドレスとを用いてセッション情報記憶部６０４に対して問い合わせを行う。ＵＤＰ受信部６０３２は、フルヘッダ受信部６０２１又は圧縮ヘッダ受信部６０２３からパケットを受け取ると、チェックサム確認部６０３３を用いてチェックサムを確認し、受信したデータに誤りが無いかを検査する。チェックサム計算の結果異常が無ければ、ＵＤＰ受信部６０３２は、セッション情報記憶部６０４から取得したアプリケーション識別子をユーザデータと共にユーザデータ出力部６０５へと出力する。
【００１７】
ＵＤＰ受信部６０３２は、受信したデータをどのアプリケーションに渡すべきかを特定する機能部である。アプリケーション（ＵＤＰ／ＩＰアプリケーション）とは、ＵＤＰ／ＩＰを利用するユーザのプログラムであり、パケット内のユーザデータに対してセッション層よりも上位層の処理を行う。
ＵＤＰセッションはＩＰアドレスとＵＤＰポート番号との組合せによって特定されるため、ＵＤＰ受信部６０３２はこれらの情報をセッションごとに管理するセッション情報記憶部６０４に対して問い合わせることでユーザデータの受け渡し先を特定する。
【００１８】
セッション情報記憶部６０４は、ＵＤＰ受信部６０３２からの要求に応じ、指定されたＩＰアドレスとＵＤＰポート番号との組合せに対応するセッション情報の識別子とアプリケーション識別子とをＵＤＰ受信部６０３２に受け渡す。
なお、送信元及び宛先の情報を両方管理する場合には、コンテキスト情報記憶部６０２２と同じ大きさのフィールドが必要となる。また、送信元の情報のみを管理する場合は、コンテキスト情報記憶部６０２２の半分の大きさのフィールドが必要である。
【００１９】
ユーザデータ出力部６０５は、アプリケーション識別子によって指定されたＵＤＰ／ＩＰアプリケーションに対してユーザデータを出力する。
【００２０】
同一のフローに属するパケットは、コンテキストとして関連づけられる。フルヘッダには、ヘッダ全体の情報の他に、コンテキストを示す識別子であるＣＩＤが含まれる。一方、圧縮ヘッダは、ヘッダの可変情報及びＣＩＤのみからなる。
【００２１】
フローとコンテキストとの対応は、フルヘッダ受信部６０２１がフルヘッダを受信した際に更新される。全てのフローにコンテキストを固定的に割り当てる必要は無いが、収容可能なコンテキストの数が少ないと、送信側は新しいフローをコンテキストに割り当てるたびにフルヘッダを送信しなければならなくなる。
【００２２】
従来技術によるヘッダ圧縮パケット受信装置６００は、ＵＤＰレベルのセッション情報記憶部６０４でアドレスやポート番号を管理するのとは別に、ヘッダ圧縮受信処理部６０２のコンテキスト情報記憶部６０２２の中にもヘッダ復元のために必要となる情報を重複して管理する必要がある。ヘッダ復元のためには、ヘッダ全体（ＵＤＰ／ＩＰｖ６の場合４８バイト）を保持するか、少なくともＩＰアドレスやポート番号などの情報を保持する必要があり、ＵＤＰレベルのセッション管理テーブルと同じ情報を重複して管理することとなる。
【００２３】
これは、従来の構成では、ヘッダ圧縮受信処理部６０２がＵＤＰ／ＩＰ受信処理部６０３とは別体であったことや、ＩＰ受信部６０３１が上位のアプリケーションに渡すパケットのほかに、他のノードに転送すべきパケットも同時に取り扱わなければならないためである。
なお、ヘッダ圧縮受信処理部６０２が収容するコンテキストの数が少ない場合には、ＩＰアドレス等の情報を重複して保持することの影響は少ない。
【００２４】
しかし、多数のフローを効率良く終端するためには、多くのコンテキストを同時に収容する必要が出てきている。例えば、第三世代移動体通信における無線アクセス網では、ＩＰを用いてデータを転送する技術が規格化されている。この規格では、3GPP TS 25.401 “UTRAN Overall Description ”に記載されているとおり、端末宛のデータを別々のＵＤＰ／ＩＰフローとして転送するため、多数のフローを収容する必要があり、全てのコンテキストについてヘッダ情報を保持しようとすると、必要となるメモリ量は大幅に増大してしまう。
【００２５】
ヘッダ圧縮パケットを用いてパケットデータを送受信する従来技術としては、特許文献２に開示される「ヘッダ圧縮パケット転送システム及びヘッダ圧縮パケット転送方法」がある。
特許文献２に開示される発明は、あるノードを中継してパケットを転送する際に、ヘッダ圧縮の状態で受信したパケットを、出力側のコンテキストと関連づけることにより、パケットの復元を行わず、ヘッダ圧縮状態のまま転送するものである。
【特許文献１】特開２００３−１１０６１８号公報
【特許文献２】特開２００３−２２４６１０号公報
【発明の開示】
【発明が解決しようとする課題】
【００２６】
しかし、上記特許文献２に開示される発明は、ＵＤＰなどのトランスポート層でのセッションが他の受信端末で最終的に終端される構成の装置、（換言すると、トランスポート層のプロトコルを処理しない装置。すなわち、中継ノード）における処理に関するものであり、データグラムの誤り検出（チェックサム計算）などのトランスポート層プロトコルに必要な処理は行っていない。これは、ＵＤＰなどのトランスポート層の処理は通常は中継ノードでは行われないためである。すなわち、上記特許文献２に開示される発明は、受信したパケットを最終的に終端する装置（すなわち、ユーザデータを処理するためのアプリケーションを備えた装置）に適用可能な構成ではない。
【００２７】
このように、従来のヘッダ圧縮パケット受信装置は、圧縮ヘッダを復元したりユーザデータの受け渡し先を特定したりするための情報を効率よく記憶しておくことはできない。このため、従来のヘッダ圧縮パケット受信装置は、受信したパケットを終端するための情報を記憶しておくために大規模なメモリを備えていなければならなかった。
【００２８】
本発明はかかる問題に鑑みてなされたものであり、圧縮ヘッダを含むパケットを終端するために必要なメモリ容量が従来よりも小さいヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法を提供することを目的とする。
【課題を解決するための手段】
【００２９】
上記目的を達成するため、本発明は、第１の態様として、複数のユーザデータに分割され、圧縮ヘッダ又はフルヘッダが付加された上で送信されてきたパケットを受信し、該ユーザデータを圧縮ヘッダ又はフルヘッダによって示される特定のアプリケーションに受け渡すヘッダ圧縮パケット処理装置であって、ユーザデータの受け渡し先を特定するためのセッション情報が格納されたセッション情報格納手段と、セッション情報を特定するための識別情報とコンテキスト識別子とを関連づけて記憶するコンテキスト情報記憶手段とを有し、パケットを受信した際には、これに付加されているヘッダが圧縮ヘッダであるかフルヘッダであるかを判断し、フルヘッダが付加されているユーザデータについては、該フルヘッダに含まれる情報とセッション情報格納手段に格納されているセッション情報とを比較して、該フルヘッダが付与されているユーザデータの受け渡し先となるアプリケーションを選択するとともに、セッション情報を特定するための識別情報と、フルヘッダ中のコンテキスト識別子とを関連づけて記憶し、圧縮ヘッダが付加されているユーザデータについては、圧縮ヘッダからコンテキスト識別子を抽出し、抽出したコンテキスト識別子に関連付けられた識別情報をコンテキスト情報記憶手段から読み出し、読み出した識別情報で特定されるセッション情報をセッション情報格納手段から読み出し、該読み出したセッション情報に基づいて、圧縮ヘッダが付加されていたユーザデータを受け渡すアプリケーションを決定することを特徴とするヘッダ圧縮パケット処理装置を提供するものである。
【００３０】
上記本発明の第１の態様においては、圧縮ヘッダとセッション情報格納手段から読み出したセッション情報とを基にして誤り検出可能な情報を含んだ疑似ヘッダを生成し、圧縮ヘッダが付与されていたユーザデータに対して疑似ヘッダを用いて誤り検出処理を行うことが好ましい。
【００３１】
また、上記本発明の第１の態様のいずれの構成においても、セッション情報は、ＩＰアドレスとトランスポート層ポート番号との組合せであることが好ましい。
【００３２】
また、上記本発明の第１の態様のいずれの構成においても、アプリケーションのいずれかから取得したユーザデータに対してフルヘッダ又は圧縮ヘッダを付加する手段と、フルヘッダ又は圧縮ヘッダを付加したユーザデータを、他の装置へ送信する手段とを有することが好ましい。
【００３３】
また、上記目的を達成するため、本発明は、第２の態様として、複数のユーザデータに分割され、圧縮ヘッダ又はフルヘッダが付加された上で送信されてきたパケットを受信し、該ユーザデータを圧縮ヘッダ又はフルヘッダによって示される特定のアプリケーションに受け渡すヘッダ圧縮パケット処理方法であって、パケットを受信した際には、これに付加されているヘッダが圧縮ヘッダであるかフルヘッダであるかを判断し、フルヘッダが付加されているユーザデータについては、ユーザデータの受け渡し先を特定するための情報であり、該フルヘッダに含まれているセッション情報に基づいて、ユーザデータの受け渡し先となるアプリケーションを選択するとともに、さらにセッション情報を特定するための識別情報と、フルヘッダ中のコンテキスト識別子とを関連づけて記憶し、圧縮ヘッダが付加されているユーザデータついては、圧縮ヘッダからコンテキスト識別子を抽出し、抽出したコンテキスト識別子に関連づけられた識別情報を読み出し、読み出した識別情報に基づいて、セッション情報を読み出し、該読み出したセッション情報に基づいて、圧縮ヘッダが付加されていたユーザデータを受け渡すアプリケーションを決定することを特徴とするヘッダ圧縮パケット処理方法を提供するものである。
【００３４】
上記本発明の第２の態様においては、圧縮ヘッダと読み出したセッション情報とを基にして誤り検出可能な情報を含んだ疑似ヘッダを生成し、圧縮ヘッダが付与されていたユーザデータに対して疑似ヘッダを用いて誤り検出処理を行うことが好ましい。
【００３５】
また、上記本発明の第２の態様のいずれの構成においても、セッション情報は、ＩＰアドレスとトランスポート層ポート番号との組合せであることが好ましい。
【００３６】
上記本発明の第２の態様のいずれの構成においても、アプリケーションのいずれかから取得したユーザデータに対してフルヘッダ又は圧縮ヘッダを付加し、フルヘッダ又は圧縮ヘッダを付加したユーザデータを、他の装置へ送信することが好ましい。
【発明の効果】
【００３７】
本発明によれば、圧縮ヘッダを含むパケットを終端するために必要なメモリ容量が従来よりも小さいヘッダ圧縮パケット処理装置及びヘッダ圧縮パケット処理方法を提供できる。
【発明を実施するための最良の形態】
【００３８】
〔発明の原理〕
通常のＵＤＰ／ＩＰヘッダの一例として、図９に、ＵＤＰ／ＩＰｖ６ヘッダの構成を示す。ＩＰｖ６ヘッダの構成はＲＦＣ２４６０"Internet Protocol Version 6 (IPv6) Specification"で、ＵＤＰヘッダの構成はＲＦＣ７６８"User Datagram Protocol"で規定されている。また、図１０に、ＵＤＰ／ＩＰｖ６に用いるフルヘッダの構成を示す。さらに、図１１に、ＲＦＣ２５０７で規定されたＵＤＰ／ＩＰｖ６に用いる圧縮ヘッダの構成例を示す。
フルヘッダは、通常のＵＤＰ／ＩＰヘッダとほぼ同様の構成であるが、レングスフィールドに相当する部分に書き込まれるデータは、通常のヘッダとは異なっている。フルヘッダの場合は、通常のヘッダではペイロード長及びデータグラム長がそれぞれ書き込まれる部分（レングス＃１、レングス＃２）に、ＣＩＤを含む情報が書き込まれる。
【００３９】
ＣＩＤは、８ビット又は１６ビットのデータであり、その大きさはパケット送信側によって指定される。図１２に示すように、ＣＩＤが８ビットの場合には、レングス＃１の最上位ビットは“０”とされ、レングス＃１の下位８ビット分がＣＩＤとなる。一方、ＣＩＤが１６ビットの場合には、レングス＃１の最上位は“１”とされており、レングス＃２に１６ビットのＣＩＤが書き込まれる。
【００４０】
圧縮ヘッダは、通常のＵＤＰ／ＩＰヘッダを構成する情報成分のうち、可変的な成分（チェックサム）のみと、ＣＩＤを含む情報とから構成されている。
【００４１】
本発明においては、コンテキスト情報記憶部には、対応するＵＤＰ／ＩＰフローのセッション識別子（セッション情報記憶部内に記憶されている情報のいずれかを指定する識別子）のみを保持し、ＩＰアドレスやポート番号と行ったヘッダ復元のための情報は保持しない。
【００４２】
フルヘッダが付加されているパケットを受信した場合には、フルヘッダからコンテキスト識別子（ＣＩＤ）を抽出し、ＩＰアドレス及びポート番号の組合せから構成されるセッション情報を特定するためのセッション識別子と関連づけて、コンテキスト情報記憶部に記憶させる。
【００４３】
その後、圧縮ヘッダが付加されているパケットを受信した場合には、圧縮ヘッダ内に書き込まれているＣＩＤを用いて、これに対応するセッション識別子をコンテキスト情報記憶部から取得する。
【００４４】
さらに、セッション識別子を用いてセッション情報記憶部からＩＰアドレスやポート番号、さらにユーザデータを渡すアプリケーションを特定するためのアプリケーション識別子といった情報を取得し、これを基にして圧縮ヘッダが付加されたパケットを終端する。
【００４５】
このようにして圧縮ヘッダが付加されたパケットを終端することにより、セッション情報記憶部に記憶されている情報と重複する情報をコンテキスト情報記憶部に記憶させておく必要が無くなるため、装置の小型化が可能となる。
【００４６】
以下、上記原理に基づく本発明の好適な実施の形態について説明する。
【００４７】
〔第１の実施形態〕
本発明を好適に実施した第１の実施形態について説明する。図１に、本実施形態にかかるヘッダ圧縮パケット受信装置の構成を示す。ヘッダ圧縮パケット受信装置１００は、ＰＰＰフレーム受信部１０１、ヘッダ圧縮受信処理部１０２、ＵＤＰ／ＩＰ受信処理部１０３、セッション情報記憶部１０４（特許請求の範囲におけるセッション情報格納手段に相当）、疑似ＵＤＰ受信部１０５及びユーザデータ出力部１０６を有する。
【００４８】
図２及び図３に、本実施形態にかかるヘッダ圧縮パケット受信装置１００の各部の詳細な構成を示す。
ＰＰＰフレーム受信部１０１は、ＰＰＰフレームを受信し、ＰＰＰヘッダを解析して上位プロトコルを識別し、フルヘッダ受信部１０２１又は圧縮ヘッダ受信部１０２３へパケットを受け渡す。
【００４９】
ヘッダ圧縮受信処理部１０２は、ユーザデータに付加されているヘッダがフルヘッダであるか圧縮ヘッダであるかに応じてパケットに対して異なる処理を行う。ヘッダ圧縮受信処理部１０２は、フルヘッダ受信部１０２１、圧縮ヘッダ受信部１０２３及びコンテキスト情報記憶部１０２２（特許請求の範囲におけるコンテキスト情報記憶手段に相当）を有する。
フルヘッダ受信部１０２１は、フルヘッダからＣＩＤを取り出し、データ長から計算した値をフルヘッダ内のレングスフィールドへ書き込んで通常のＵＤＰ／ＩＰヘッダと同様にした後、パケットとＣＩＤとをＵＤＰ／ＩＰ受信処理部１０３へと渡す。
圧縮ヘッダ受信部１０２３は、圧縮ヘッダから取り出したＣＩＤを用いて、コンテキスト情報記憶部１０２２に問い合わせを行う。圧縮ヘッダ受信部１０２３は、コンテキスト情報記憶部１０２２から取得したセッション識別子をユーザデータ及び圧縮ヘッダ中のチェックサムとともに疑似ＵＤＰ受信部１０５へと出力する。
【００５０】
コンテキスト情報記憶部１０２２は、ＵＤＰ受信部１０３２から指定されたＣＩＤに対応するセッション識別子を記憶する。また、圧縮ヘッダ受信部１０２３からの問い合わせに応じて、指定されたＣＩＤに対応するセッション識別子を圧縮ヘッダ受信部１０２３へと受け渡す。
【００５１】
ＵＤＰ／ＩＰ受信処理部１０３は、通常のＵＤＰ／ＩＰヘッダが付加されているパケットを終端するための機能部である。ＵＤＰ／ＩＰ受信処理部１０３は、ＩＰ受信部１０３１及びＵＤＰ受信部１０３２とからなる。
ＩＰ受信部１０３１は、フルヘッダ受信部１０２１から受け渡されたＵＤＰ／ＩＰパケットのＩＰヘッダの中からＩＰアドレスを取りだし、上位プロトコルがＵＤＰであれば、パケットをＵＤＰ受信部１０３２へと受け渡す。
ＵＤＰ受信部１０３２は、ＵＤＰヘッダから取り出したポート番号と、ＩＰ受信部１０３１から渡されたＩＰアドレスとを用いてセッション情報記憶部１０４に対して問い合わせる。ＵＤＰ受信部１０３２は、セッション情報記憶部１０４から取得したアプリケーション識別子を、ユーザデータとともにユーザデータ出力部１０６へ出力する。また、ＣＩＤとセッション識別子とをコンテキスト情報記憶部１０２２へ出力し、これらを関連づけて記憶させる。また、ＵＤＰ受信部１０３２は、チェックサム確認部を備えており、フルヘッダのパケットに対してチェックサム計算を行い、データに誤りがあるか否かを判断する。
【００５２】
セッション情報記憶部１０４は、ＵＤＰ受信部１０３２からの問い合わせに応じて、指定されたＩＰアドレスとＵＤＰポート番号との組合せに対応するセッション情報の識別子と、アプリケーション識別子とをＵＤＰ受信部１０３２へ返答する。
また、疑似ＵＤＰ受信部１０５からの問い合わせに応じて、指定されたセッション識別子に対応するＩＰアドレス、ＵＤＰポート番号及びアプリケーション識別子を疑似ＵＤＰ受信部１０５へ返答する。
【００５３】
疑似ＵＤＰ受信部１０５は、圧縮ヘッダが付加されているパケットを終端するための機能部であり、圧縮ヘッダ受信部から受け渡されたセッション識別子を用いてセッション情報記憶部１０４に問い合わせる。
疑似ＵＤＰ受信部１０５は、疑似ＵＤＰ／ＩＰヘッダ生成部１０５１及びチェックサム確認部１０５２を有する。
疑似ＵＤＰ／ＩＰヘッダ生成部１０５１は、セッション情報記憶部１０４から取得したＩＰアドレス及びポート番号を用いて疑似ＵＤＰ／ＩＰヘッダを生成する。チェックサム確認部１０５２は、疑似ＵＤＰ／ＩＰヘッダ生成部１０５１が生成した疑似ＵＤＰ／ＩＰヘッダを用いてチェックサム計算を行って、データに誤りがあるか否かを判断する。データに誤りがなければ、セッション情報記憶部１０４から取得したアプリケーション識別子を、ユーザデータとともにユーザデータ出力部１０６へ出力する。
【００５４】
ユーザデータ出力部１０６は、ＵＤＰ／ＩＰ受信処理部１０３又は疑似ＵＤＰ受信部１０５から取得したユーザデータを、これとともに取得したアプリケーション識別子によって指定されたＵＤＰ／ＩＰアプリケーションへと出力する。
【００５５】
疑似ＵＤＰ／ＩＰヘッダの一例として、図４に、疑似ＵＤＰ／ＩＰｖ６ヘッダの構成を示す。疑似ＵＤＰ／ＩＰｖ６ヘッダは、ＲＦＣ２４６０で規定されている疑似ＩＰｖ６ヘッダとＵＤＰヘッダとを組み合わせたものである。ＵＤＰチェックサムは、疑似ＩＰヘッダ、ＵＤＰヘッダ及びユーザデータに対してチェックサム計算を行った値として定義される。チェックサムは、計算対象となる全てのデータを１６ビットごとに１の補数で加算した総和に対する１の補数である。
【００５６】
疑似ＵＤＰ／ＩＰヘッダ生成部１０５１は、疑似ＵＤＰ受信部１０５がセッション識別子に基づいてセッション情報記憶部１０４から取得した値を、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号及び宛先ポート番号として疑似ＵＤＰ／ＩＰヘッダを生成する際にそれぞれ書き込む。また、疑似ＵＤＰ／ＩＰヘッダ生成部１０５１は、ユーザデータ長にＵＤＰヘッダ長の８バイトを加えた値をデータグラム長として疑似ＵＤＰ／ＩＰヘッダに書き込む。さらに、疑似ＵＤＰ／ＩＰヘッダのチェックサムとして、圧縮ヘッダ受信部１０２３から渡されたチェックサムをそのまま書き込む。なお、次ヘッダは、ＵＤＰを示す“１７”で固定であるため、これが疑似ＵＤＰ／ＩＰヘッダに書き込まれる。
【００５７】
圧縮ヘッダに対するチェックサム計算は、疑似ＵＤＰ／ＩＰヘッダ生成部１０５１が生成した疑似ＵＤＰ／ＩＰヘッダをユーザデータに付加したうえで行われる。チェックサム確認部１０５２は、チェックサム計算の結果が“０”であれば、データは正常であると判断する。一方、チェックサム計算の結果が、“０”以外になればデータは異常であると判断し、受信データを破棄する。
【００５８】
図５に、本実施形態にかかるヘッダ圧縮パケット受信装置１００の動作の流れを示す。
ＰＰＰフレーム受信部１０１は、外部装置から送られてきたＰＰＰフレームを受信すると、ＰＰＰヘッダを解析する（ステップＳ１０１）。ＰＰＰフレーム受信部１０１は、ＰＰＰヘッダを解析した結果に基づいて、フルヘッダのパケットを受信したのか圧縮ヘッダのパケットを受信したのかを判断する（ステップＳ１０２）。ＰＰＰフレーム受信部１０１は、フルヘッダのパケットを受信したと判断した場合には（ステップＳ１０２／Ｎｏ）、受信したデータをフルヘッダ受信部１０２１へと出力する。一方、圧縮ヘッダのパケットであると判断した場合には（ステップＳ１０２／Ｙｅｓ）、受信したデータを圧縮ヘッダ受信部１０２３へと出力する。
【００５９】
フルヘッダ受信部１０２１は、ＰＰＰフレーム受信部１０２からパケットを受け渡されると、フルヘッダに含まれているＣＩＤを取り出し、データ長から計算した値をフルヘッダのレングスフィールドに書き込む。その後、パケットとＣＩＤとをＵＤＰ／ＩＰ受信処理部１０３へと受け渡す（ステップＳ１０３）。
【００６０】
フルヘッダ受信部１０２からパケット及びＣＩＤを受け渡されたＵＤＰ／ＩＰ受信処理部１０３は、ＩＰ受信部１０３１を用いて、ＩＰヘッダからＩＰアドレスを取り出すとともに、ＵＤＰ受信部１０３２を用いてＵＤＰヘッダからポート番号を取り出す（ステップＳ１０４）。
【００６１】
その後、ＵＤＰ／ＩＰ受信処理部１０３は、チェックサム確認部１０３３を用いてチェックサム計算を行い、データに誤りがあるか否かを判断する（ステップＳ１０５）。チェックサム計算の結果誤りが検出された場合、ＵＤＰ／ＩＰ受信処理部１０３は、そのパケットのデータを破棄する。
【００６２】
チェックサム計算の結果誤りが検出されなければ、ＵＤＰ／ＩＰ受信処理部１０３は、ＩＰアドレスとポート番号とを用いてセッション情報記憶部１０４に対して問い合わせ、セッション情報記憶部１０４からセッション識別子とアプリケーション識別子とを取得する（ステップＳ１０６）。
【００６３】
続いて、ＵＤＰ／ＩＰ受信処理部１０３は、ＣＩＤとセッション識別子とをコンテキスト情報記憶部１０２２へ出力し、これらを関連づけて記憶させる（ステップＳ１０７）。その後、ユーザデータ及びアプリケーション識別子をユーザデータ出力部１０６へ出力する。
【００６４】
一方、圧縮ヘッダ受信部１０２３は、ＰＰＰフレーム受信部１０１からパケットを受け渡されると、圧縮ヘッダに含まれているＣＩＤを取り出し（ステップＳ１０８）、これを用いてコンテキスト情報記憶部１０２２に対して問い合わせ、ＣＩＤに対応するセッション識別子を取得する。ＣＩＤに対応するセッション識別子を取得した圧縮ヘッダ受信部１０２３は、圧縮ヘッダに含まれるＵＤＰチェックサムを取り出し、これをユーザデータ及びセッション識別子と共に疑似ＵＤＰ受信部１０５へと出力する（ステップＳ１０９）。
【００６５】
圧縮ヘッダ受信部１０２３からセッション識別子及びチェックサムと共にユーザデータを受け渡された疑似ＵＤＰ受信部１０５は、疑似ＵＤＰ受信処理を行う（ステップＳ１１０）。
【００６６】
図６に、本実施形態において疑似ＵＤＰ受信部１０５が行う疑似ＵＤＰ受信処理の流れを示す。
疑似ＵＤＰ受信部１０５は、圧縮ヘッダ受信部１０２３から取得したセッション識別子をセッション情報記憶部１０４に通知することで問い合わせを行う（ステップＳ２０１）。疑似ＵＤＰ受信部１０５からの問い合わせを受けたセッション情報記憶部１０４は、格納している情報を参照し（ステップＳ２０２）、通知されたセッション識別子に対応するＩＰアドレス及びＵＤＰポート番号及びこれらの組合せを示す情報（アプリケーション識別子）を疑似ＵＤＰ受信部１０５へ返す（ステップＳ２０３）。疑似ＵＤＰ受信部１０５は、問い合わせに応じてセッション情報記憶部１０４から返信されてきたＩＰアドレス、ポート番号、アプリケーション識別子を取得する（ステップＳ２０４）。
【００６７】
疑似ＵＤＰ受信部１０５は、問い合わせによってセッション情報記憶部１０４から情報を取得すると、これらの情報を基にして、疑似ＵＤＰ／ＩＰヘッダ生成部１０５１を用いて疑似ＵＤＰ／ＩＰヘッダを生成する（ステップＳ２０５）。
【００６８】
疑似ＵＤＰ受信部１０５は、疑似ＵＤＰ／ＩＰヘッダを生成し終えると、これをユーザデータに付加し、付加したユーザデータに対してチェックサム確認部１０５２を用いてチェックサム計算を行い（ステップＳ２０６）、データに誤りがあるか否かを判断する（ステップＳ２０７）。チェックサム計算の結果誤りが検出された場合（ステップＳ２０７／Ｎｏ）、疑似ＵＤＰ受信部１０５は、そのパケットを破棄する（ステップＳ２０９）。この場合は、疑似ＵＤＰ受信処理よりも後段の処理（すなわち、図４ステップＳ１１１）は行わない。
【００６９】
一方、疑似ＵＤＰ受信部１０５は、チェックサム計算の結果異常がないと判断したパケットのユーザデータ及びアプリケーション識別子をユーザデータ出力部１０６へと出力する（ステップＳ２０８）。
【００７０】
ユーザデータ出力部１０６は、ＵＤＰ／ＩＰ受信処理部１０３又は疑似ＵＤＰ受信部１０５から取得したユーザデータを、これと共に取得したアプリケーション識別子によって指定されるＵＤＰ／ＩＰアプリケーションに対して出力する（ステップＳ１１１）。
【００７１】
従来のヘッダ圧縮パケット処理装置は、圧縮ヘッダを含むパケットを受信した際には、データリンク層の処理において、そのパケットのヘッダを通常のヘッダと同様に復元し、その後ネットワーク層及びトランスポート層の処理を行ってユーザデータの受け渡し先を特定していた。このため、データリンク層の処理において圧縮ヘッダを復元するために必要な情報と、ネットワーク層及びトランスポート層の処理においてユーザデータの受け渡し先を特定するために必要な情報とに、共通する情報成分が含まれているにも関わらず、従来のヘッダ圧縮パケット処理装置は、これらの情報を別個に管理する必要があった。
【００７２】
これに対し、本実施形態にかかるヘッダ圧縮パケット処理装置は、圧縮ヘッダを含むパケットを受信した場合には、データリンク層の処理では元のＵＤＰ／ＩＰヘッダの復元は行わず、ネットワーク層及びトランスポート層の処理において通常のヘッダとは異なる疑似ヘッダを付加して誤り検出のためのチェックサム計算を行い、ＣＩＤに関連付けられたセッション識別子からユーザデータの受け渡し先を特定する。このようにしてユーザデータの受け渡し先を特定することにより、ヘッダ圧縮パケット処理装置は、通常のヘッダに含まれる情報をネットワーク層及びトランスポート層とデータリンク層とで重複して管理する必要が無くなる。
【００７３】
よって、本実施形態にかかるヘッダ圧縮パケット受信装置は、圧縮ヘッダが付加されたユーザデータを復元するために装置内に蓄積しておく必要のあるデータ量が従来の圧縮パケット受信装置よりも少なくて済む。このため、従来技術による圧縮ヘッダパケット受信装置よりも、装置を小型化・軽量化することが可能となる。
【００７４】
〔第２の実施形態〕
本発明を好適に実施した第２の実施形態について説明する。図７に、本実施形態にかかるヘッダ圧縮パケット通信装置の構成を示す。このヘッダ圧縮パケット通信装置は、ヘッダ圧縮パケット受信部２００及びヘッダ圧縮パケット送信部３００を有する。
【００７５】
ヘッダ圧縮パケット受信部２００は、第１の実施形態におけるヘッダ圧縮パケット受信装置と同様の機能を有する。ヘッダ圧縮パケット送信部３００は、従来技術によるヘッダ圧縮パケット送信装置と同様の構成であり、ユーザデータ入力部３０１、ＵＤＰ／ＩＰヘッダ生成部３０２及びＰＰＰフレーム送信部３０３を有する。
【００７６】
ユーザデータ入力部３０１は、各ＵＤＰ／ＩＰアプリケーションからユーザデータとともにセッション識別情報を取得し、これらをＵＤＰヘッダ生成部３０２へと出力する。
【００７７】
ＵＤＰ／ＩＰヘッダ生成部３０２は、ユーザデータ入力部３０１から取得したセッション識別情報に従い、対応するＩＰアドレスとＵＤＰポート番号とを用いて、フルヘッダまたは圧縮ヘッダを生成し、これをユーザデータに付与し、ＰＰＰフレーム送信部３０３へと出力する。
【００７８】
ＰＰＰフレーム送信部３０３は、フルヘッダ又は圧縮ヘッダが付加されたユーザデータに対して、ＰＰＰヘッダを付与し、外部装置へ送信する。
【００７９】
ヘッダ圧縮パケット通信装置が、圧縮ヘッダを用いたパケットを受信する際の動作は、上記第１の実施形態と同様である。また、ヘッダ圧縮パケット通信装置が圧縮ヘッダを用いる手法でパケットを送信する場合の動作は、通常のヘッダ圧縮パケット通信装置と同様である。
【００８０】
本実施形態にかかるヘッダ圧縮パケット通信装置は、受信された圧縮ヘッダを処理するために必要なメモリ容量が従来よりも小さいため、ヘッダ圧縮パケット通信装置の小型化・軽量化ができる。
【００８１】
〔第３の実施形態〕
本発明を好適に実施した第３の実施形態について説明する。図８に、本実施形態にかかる無線通信装置の構成を示す。この無線通信装置は、ヘッダ圧縮パケット受信部２００、ヘッダ圧縮パケット送信部３００、無線通信部４００及びアンテナ５００を有する。
【００８２】
ヘッダ圧縮パケット受信部２００及びヘッダ圧縮パケット送信部３００は上記第２の実施形態と同様である。無線通信部４００は、ヘッダ圧縮パケット送信部から入力された電気信号をアンテナ５００へ出力するとともに、アンテナ５００から入力された電気信号をヘッダ圧縮パケット受信部２００へと出力する。アンテナ５００は、無線通信部４００から入力された電気信号を無線信号に変換して発信するとともに、受信した無線信号を電気信号に変換して無線通信部４００へ出力する。
【００８３】
無線通信は、無線帯域という極めて限られた資源を利用して通信を行うため、与えられた無線帯域内で高速データ通信を実現するためには、無線リソースを極限まで効率良く利用する必要がある。このため、圧縮ヘッダを用いる手法は無線通信において非常に有効な技術である。しかし、従来は圧縮ヘッダを復元するために無線通信装置は装置内に大規模なメモリを備えていなければならず、装置を小型化・軽量化する妨げとなっていた。
これに対し、本実施形態にかかる無線通信装置は、無線通信装置内に設置するメモリの容量が従来のヘッダ圧縮パケット受信装置より小さくても圧縮ヘッダを復元できるため、無線通信装置の小型化・軽量化ができる。
なお、本実施形態においては、無線通信を行う構成について説明したが、本発明が有線通信・無線通信を問わずに適用できることは言うまでもない。
【００８４】
なお、上記各実施形態は、本発明の好適な実施の一例であり、本発明はこれらに限定されることはない。
例えば、セッション情報記憶部内に記憶するデータは、上記実施形態に示したデータ構造に限定されるものではない。
また、本発明を適用可能な通信プロトコルは、ＵＤＰ／ＩＰに限定されることはなく、他の通信プロトコルにも適用できる。
このように、本発明は、様々な変形が可能である。
【図面の簡単な説明】
【００８５】
【図１】本発明を好適に実施した第１の実施形態にかかるヘッダ圧縮パケット受信装置の構成を示す図である。
【図２】第１の実施形態にかかるヘッダ圧縮パケット受信装置の詳細な構成を示す図である。
【図３】第１の実施形態にかかるヘッダ圧縮パケット受信装置の詳細な構成を示す図である。
【図４】疑似ＵＤＰ／ＩＰヘッダの構成を示す図である。
【図５】第１の実施形態にかかるヘッダ圧縮パケット受信装置のＰＰＰフレーム受信時の動作の流れを示すフローチャートである。
【図６】第１の実施形態における疑似ＵＤＰ受信処理の流れを示すフローチャートである。
【図７】本発明を好適に実施した第２の実施形態にかかるヘッダ圧縮パケット通信装置の構成を示す図である。
【図８】本発明を好適に実施した第３の実施形態にかかる無線通信装置の構成を示す図である。
【図９】ＩＰｖ６ヘッダの構成を示す図である。
【図１０】ＩＰｖ６に用いるフルヘッダの構成を示す図である。
【図１１】圧縮ヘッダの構成例を示す図であり、（ａ）はＣＩＤが８ビットの場合、（ｂ）はＣＩＤが１６ビットの場合を表す。
【図１２】フルヘッダのレングスフィールドに書き込まれる情報を示す図であり、（ａ）はＣＩＤが８ビットの場合、（ｂ）はＣＩＤが１６ビットの場合を表す。
【図１３】従来のヘッダ圧縮パケット受信装置の構成を示す図である。
【図１４】従来のヘッダ圧縮パケット受信装置の詳細な構成を示す図である。
【図１５】従来のヘッダ圧縮パケット受信装置の詳細な構成を示す図である。
【符号の説明】
【００８６】
１００    ヘッダ圧縮パケット受信装置
１０１、２０１    ＰＰＰフレーム受信部
１０２、２０２    ヘッダ圧縮受信処理部
１０３、２０３    ＵＤＰ／ＩＰ受信処理部
１０４、２０４    セッション情報記憶部
１０５、２０５    疑似ＵＤＰ受信部
１０６、２０６    ユーザデータ出力部
２００    ヘッダ圧縮パケット受信部
３００    ヘッダ圧縮パケット送信部
３０１    ユーザデータ入力部
３０２    ＵＤＰ／ＩＰヘッダ生成部
３０３    ＰＰＰフレーム送信部
４００    無線通信部
５００    アンテナ
１０２１    フルヘッダ受信部
１０２２    コンテキスト情報記憶部
１０２３    圧縮ヘッダ受信部
１０３１    ＩＰ受信部
１０３２    ＵＤＰ受信部
１０３３、１０５２    チェックサム確認部
１０５１    疑似ＵＤＰ／ＩＰヘッダ生成部
【図１】
2005252855.tif 000003
【図２】
2005252855.tif 000004
【図３】
2005252855.tif 000005
【図４】
2005252855.tif 000006
【図５】
2005252855.tif 000007
【図６】
2005252855.tif 000008
【図７】
2005252855.tif 000009
【図８】
2005252855.tif 000010
【図９】
2005252855.tif 000011
【図１０】
2005252855.tif 000012
【図１１】
2005252855.tif 000013
【図１２】
2005252855.tif 000014
【図１３】
2005252855.tif 000015
【図１４】
2005252855.tif 000016
【図１５】
2005252855.tif 000017