(57)【特許請求の範囲】
【請求項１】
ヘッダ圧縮アルゴリズムにおいてトランスポート層のチェックサムを代替するための方法であって、
トランスポート層ヘッダおよびトランスポート層ペイロードの両方に対して単一の誤り検出コードを算出し、
該トランスポート層ヘッダを、該ヘッダ圧縮アルゴリズムに従って圧縮し、
該圧縮トランスポート層ヘッダに該誤り検出コードを含ませ、
該圧縮トランスポート層ヘッダを送信する過程を有する方法。
【請求項２】
前記トランスポート層ヘッダを復元し、前記誤り検出コードを用いて該復元トランスポート層ヘッダの正確性を確認する過程をさらに有する請求項１による方法。
【請求項３】
前記誤り検出コードがＣＲＣである請求項１による方法。
【請求項４】
前記誤り検出コードの大きさが約２オクテットである請求項１による方法。
【請求項５】
前記トランスポート層がＩＰベースのトランスポート層である請求項１による方法。
【請求項６】
前記ＩＰベースのトランスポート層が、前記トランスポート層ヘッダにトランスポート層チェックサムを含み、前記誤り検出コードが該チェックサムに対しても算出される請求項５による方法。
【請求項７】
ヘッダ圧縮アルゴリズムにおいてトランスポート層のチェックサムを代替するための装置であって、
トランスポート層ヘッダおよびトランスポート層ペイロードの両方に対して単一の誤り検出コードを算出するための誤り検出コード算出部、
該トランスポート層ヘッダを、該ヘッダ圧縮アルゴリズムに従って圧縮するためのヘッダ圧縮部、および
該圧縮トランスポート層ヘッダを送信するための送信部を有する装置。
【請求項８】
前記トランスポート層ヘッダを復元するためのヘッダ展開部をさらに有する請求項７による装置。
【請求項９】
前記誤り検出コードを用いて該復元トランスポート層ヘッダの正確性を確認するための確認処理部をさらに有する請求項７による装置。
【請求項１０】
前記誤り検出コードがＣＲＣである請求項７による装置。
【請求項１１】
前記誤り検出コードの大きさが約２オクテットである請求項７による装置。
【請求項１２】
前記トランスポート層がＩＰベースのトランスポート層である請求項７による装置。
【請求項１３】
前記ＩＰベースのトランスポート層が、前記トランスポート層ヘッダにトランスポート層チェックサムを含み、前記誤り検出コードが該チェックサムに対しても算出される請求項１２による装置。
【発明の詳細な説明】
【０００１】
【関連出願の相互参照】
本特許出願は、２０００年２月４日付で出願された現在継続中の米国特許出願第６０／１８０，３０２号に基づく優先権を主張するものであり、また、該特許出願の開示内容をすべて引用によって導入する。
【０００２】
【本発明の背景】
発明の分野
本発明は、一般的にパケットヘッダの圧縮に関し、より具体的にパケットヘッダ圧縮アルゴリズムにおけるトランスポート層チェックサムの代替に関するものである。
【０００３】
関連技術の説明
インターネットの甚だしい発展により、インターネットプロトコル（ＩＰ）を、音声通信を含む様々な用途に対応できるように拡張する要望が出てきた。その目的は、無論、音声データを伝送するためのリンクとしてインターネットを利用することである。現在では、音声データは、ユーザデータグラムプロトコル（ＵＤＰ）やリアルタイムトランスポートプロトコル（ＲＴＰ）等のＩＰに基づくトランスポート層プロトコルを使用してインターネットを介して伝送される。典型的なアプリケーションでは、電話通信ソフトを実行するコンピュータによって、音声がディジタルデータに変換され、ＩＰベースのトランスポート層プロトコルを使用したインターネット通信に適したデータパケットを形成するように構築される。ＵＤＰおよびＲＴＰ等のトランスポート層プロトコルに関する詳しい情報については、Jon Postel, User Datagram Protocol, DARPA RFC 786, August 1980またはHenning Schulzrinne et al., RTP:  A Transport Protocol for Real-time Applications, IETF RFC 1889, IETF Audio/video Transport Working Group, January 1996を参照されたい。
【０００４】
図１に、ＵＤＰおよびＲＴＰ等のＩＰベースのトランスポート層プロトコルによる通常のパケット１０を示す。パケット１０は、インターネット等のパケット交換通信網を介して伝送される、例えば音声データ等を示すパケットストリームを形成する複数の関連するパケットのうちの１つのパケットである。一般的に、パケット１０はヘッダ部１２とペイロード部１４からなるものである。ヘッダ１２は、図に示すように、パケット１０の送信元や送信先等のフィールドを含む複数のヘッダフィールドを有する。
【０００５】
図２に、一例によるパケット交換通信網２０の要部を示す。パケットストリーム１０が、インターネット等のパケット発信元２２から、リンク２４を介して、アクセス技術２６に送信される。アクセス技術２６は、全世界移動通信システム（ＧＳＭ）、時間分割多元接続（ＴＤＭＡ）および広帯域符号分割多元接続（ＷＣＤＭＡ）等の、無線インタフェースを介して受信機へのアクセスを提供する通信プロトコルの任意の層である。アクセス技術２６は、パケット１０を、リンク２８を介して例えば移動ユニット等の受信機２９へ送信するために処理する。リンク２８は、アクセス技術２６と受信機２９とを結ぶセルラーリンク等の無線インタフェース等である。受信機２９は、アクセス技術２６からパケット１０を受信、処理し、音声コーデック等の所望のアプリケーションに転送する。
【０００６】
しかし、純粋な音声データパケットにおいては、トランスポート層ヘッダ１２がパケット１０の７０％までも占有することもあり、ペイロード１４に残される容量が限られてしまう。セルラーリンクの場合、帯域幅の使用が非効率的であるため、ＩＰベースの音声通信は回線交換型のサービスに代わる経済的な手段となり得ない。純粋音声用のＩＰベースの方式をセルラーリンクを介して行うことを経済面で可能ならしめるためには、ヘッダ１２が必要とする帯域幅を大幅に削減しなくてはならない。従って、ある程度のヘッダ圧縮または縮小をホップ毎に行うことが必要となる。
【０００７】
ヘッダ圧縮とは、ホップ毎にヘッダ内の情報によって消費される帯域幅を認識できないように最小化する技術を意味する。一般的に、ヘッダは送信機または圧縮部側で圧縮またはその他の方法により縮小され、受信機または展開部側で復元される。圧縮は、同一のデータパケットおよび連続するパケット間のヘッダにおいて冗長率が高いために可能である。この冗長性によって、パケット間で予想される変化の増分に基づいて受信機においてヘッダ値を確実に推定することができる。その結果、送信時にヘッダ情報を幾分省略し、受信機において推定値に基づいて復元することができる。
【０００８】
新しいパケットストリームの転送を開始する時、トランスポート層ヘッダにおける静的情報および動的情報の初期値のみが送信される。静的情報は再送信する必要はないが、動的情報の変化は発生次第に送信しなくてはならない。（すべてのヘッダ値ではなく）変化だけを送信することによって、ヘッダを伝送するために必要な帯域幅を大幅に削減することができる。ヘッダは、予想される増分変化に基づいて先行のヘッダ値からその値を推定したり、送信された変化によって更新することによって復元することができる。しかし、ランダムまたは予想不可能な情報はこのようにして復元することができず、通常はそのまま送信される。
【０００９】
データを送信する時、データが正しく受信されることを保障するために管理手段を用いることが一般的である。送信データを管理するための方法として、送信中に異常が発生したり、損傷を負ったデータを検出するための誤り検出用のチェックまたはコードを採用する方法がある。誤り検出コードは、（幾つかの周知の方法のうち１つを使用して）保護すべきデータブロック全体に対して算出され、送信メッセージの一部として含まれる。受信側では、受信データについて新しい誤り検出コードが算出され、含まれた誤り検出コードと比較される。新しく算出された誤り検出コードが、含まれた誤り検出コードと一致すると、データが正しく受信されたことがわかる。
【００１０】
周知の誤り検出コードの一例として、チェックサムがある。チェックサムは、例えばＵＤＰおよびＲＴＰトランスポート層プロトコル等によって、単一のデータパケットにおける誤りを検出するために使われる。このようなトランスポート層チェックサムは、データパケット全体（例えば、ヘッダおよびペイロード）に対して適用できるように計算され、ヘッダフィールド１６（図１に示す）の１つとしてトランスポート層ヘッダに含まれる。チェックサムの値は、送信すべきパケットにおけるデータのオクテットをすべて合計することで算出される。受信側で同様の処理が行われ、その２つの値が一致するかどうかを比較する。一致すれば、データが正しく受信されたことを意味する。
【００１１】
しかし、当業者の間では、チェックサムは誤り検出コードとして信頼性の低いものとして認識されている。例えば、１つのオクテットにおいて誤りが発生したらチェックサムによって検出できるが、２つの異なるオクテットで誤りが発生した場合に、これは検出されない可能性が高い。従って、ヘッダ圧縮アルゴリズム等の高信頼性のアプリケーションにおいては、一般的にチェックサムは使用されない。
【００１２】
トランスポート層チェックサムは一般的に信頼性が低いと思われているため、殆どのヘッダ圧縮アルゴリズムは、ヘッダ情報を保護するために、ＣＲＣ（巡回冗長コード）等の、より信頼性の高い誤り検出チェックまたはコードを別に作成する。ＣＲＣを採用するヘッダ圧縮アルゴリズムとして現在使用されている幾つかのもののうち１つとして、例えばＲＯＣＣＯ（ロバストチェックサムベースヘッダ圧縮）がある。ＣＲＣの計算方法は、当業者にとっては周知であるので、ここでは簡単に説明するに止める。基本的に、元のパケットヘッダ全体等の、保護すべきデータブロックが、所定長の多項式によって除算される。ＣＲＣは、この除算の結果得られる剰余である。
【００１３】
ＲＯＣＣＯ等のヘッダ圧縮アルゴリズムについて、ＣＲＣの大きさは１０ビット程で足りるとされている。この大きさは、勿論、アルゴリズムの実際の適用例によってケースバイケースで変えることも可能である。さらに、ヘッダを正しく復元するために、元の非圧縮のままのヘッダ情報（例えばデルタ値）を６ビットまで、ＣＲＣと共に送信する必要があることもある。その結果、圧縮ヘッダと一緒に、最小で１６ビット分、即ち２オクテット分のヘッダオーバーヘッドを送信することになる。
【００１４】
さらに、上述のとおり、トランスポート層ヘッダのフィールド１６のうち、１つはチェックサムフィールドである。このフィールドは殆どの場合２オクテットを占有し、トランスポート層パケットが正しいか否かを確認するために使用される。ＩＰの第４版（ＩＰｖ４）には、チェックサムを解除する機能が備わっているが、そうすることによってパケット内のデータの信頼性を損ってしまう畏れがある。ＩＰの最新版であるＩＰｖ６には、このような解除機能は備わっていない。
MOBICOM 1996, Degermark et al., "Low-loss TCP/IP Header Compression for Wireless Networks"には、新規のヘッダ圧縮方式を提供するための方法に関する概略的な説明が記載されている。この方式は、同一のパケットストリームに属し、パケットストリームが継続中に同等であるか、あるいはあまり変化しない、連続するヘッダの存在に基づくものである。上流のノードは、ヘッダを完全な状態で送信せず、その代わりに、下流のノードにステートとして記憶されている、以前に送信されたヘッダを示す、短い指標を送信する。誤りの検出は、データパケット全体に対するチェックサムを使用して行われる。
Globecom '99, Subbiah et al., "RTP Payload Multiplexing between IP Telephony Gateways"には、ＩＰ電話ゲートウェイ間で、複数の低ビットレートの音声ストリームを単一のＲＴＰストリームに多重するための方法に関する概略的な説明が記載されている。個別のユーザによる音声フレームを多重ＲＴＰペイロードに組み合わせるものである。単一のＲＴＰストリームを共有する多重された各音声ストリームを識別するために、音声ストリームの各フレームに２バイトのミニヘッダが付加される。伝送中に誤りが発生したかを求めるために、データパケット全体に対してチェックサムの計算が行われる。
【００１５】
ＣＲＣおよびチェックサム型の誤り検出コードは、何れも本質的にランダムな特性を有するため、これらのコードの送信は、そのままの状態で行わなくてはならない。従って、ＩＰｖ６およびＩＰｖ４の殆どのアプリケーションにおいて、セルラーリンク等の無線インタフェースを介してＩＰベースの音声を伝送するために、各パケットにつき、少なくとも４オクテット（２オクテット＋２オクテット）分のヘッダオーバーヘッドが必要である。よって、伝送されたデータの信頼性を損わずにこのヘッダオーバーヘッドをできるだけ削減することが望ましい。
【００１６】
本発明は、データの信頼性を損わずに、ヘッダオーバーヘッドを削減するための方法および装置を提供するものである。
【００１７】
【本発明の概要】
本発明は、トランスポート層における誤り検出コードおよびヘッダ圧縮アルゴリズムにおける誤り検出コードに代えて、単一の誤り検出コードを提供する方法および装置に関するものである。代替誤り検出コードは、トランスポート層ペイロードとトランスポート層ヘッダの両方に適用される。この方式により、そのまま、非圧縮で送信される情報の量を削減し、よって、必要な帯域幅を縮小することができる。代替誤り検出コードは、次いで、復元されたヘッダおよびペイロードの両方の正確性を確認するために使用される。
【００１８】
ある側面では、本発明はヘッダ圧縮アルゴリズムにおいてトランスポート層の誤り検出コードを代替するための方法に関するものである。この方法は、トランスポート層ヘッダおよびトランスポート層ペイロードの両方に対して単一の誤り検出コードを算出し、該トランスポート層ヘッダを、該ヘッダ圧縮アルゴリズムに従って圧縮し、該圧縮トランスポート層ヘッダに該誤り検出コードを含ませ、該圧縮トランスポート層ヘッダを送信する過程を有する方法である。
【００１９】
他の側面では、本発明はヘッダ圧縮アルゴリズムにおいてトランスポート層の誤り検出コードを代替するための装置に関するものである。この装置は、トランスポート層ヘッダおよびトランスポート層ペイロードの両方に対して単一の誤り検出コードを算出するための誤り検出コード算出部、該トランスポート層ヘッダを、該ヘッダ圧縮アルゴリズムに従って圧縮するためのヘッダ圧縮部、および該圧縮トランスポート層ヘッダを送信するための送信部を有する装置である。
【００２０】
本発明とその範囲について、添付の図面（以下にそれを概略的に説明する）、以下の好適な実施形態の詳細な説明および付随の請求項を参照することでより完全な理解が得られる。
【００２１】
【好適な実施形態の詳細な説明】
以下に、本発明の好適な実施形態を示す添付の図面を参照しながら、本発明をより詳細に説明する。ただし、本発明は、様々な形態によって実施可能であり、ここに挙げる実施形態に限定される訳ではなく、これらの形態は、開示内容を徹底した完全なるものとし、当業者に本発明の範囲を全く伝えるべく記載したものである。
【００２２】
上述のとおり、セルラーリンク等の無線インタフェースを介してＩＰベースの音声データを伝送するために、現在では、各データパケットにつき、通常４オクテット分のヘッダオーバーヘッドが必要である。本発明は、ヘッダ圧縮ＣＲＣとトランスポート層チェックサムを、ここではＣＲＣ＋と称する、単一の誤り検出コードで代替することでヘッダオーバーヘッドの量を削減することを可能にする。従って、ヘッダ圧縮ＣＲＣとトランスポート層チェックサムを両方とも送信する必要がなくなるため、ヘッダオーバーヘッドの量を削減することができる。
【００２３】
図３に、ＲＯＣＣＯ等の圧縮アルゴリズムを使用した本発明の原理によるトランスポート層ヘッダを圧縮するための典型的な処理を示す。トランスポート層ヘッダ３０は、上述のようなＩＰ、ＵＤＰおよびＲＴＰヘッダフィールドを含み、非圧縮の元の状態では、長さ４０オクテットのものが典型的である。ヘッダ３０の圧縮は、例えばＲＯＣＣＯ圧縮部等の、周知のヘッダ圧縮過程に従って、圧縮部３２によって行われる。殆どの場合、その結果得られる圧縮ヘッダ３４は、ヘッダ圧縮ＣＲＣ（１０ビット）およびトランスポート層チェックサム（１６ビット）しか含まない。既に説明したとおり、このような誤り検出コードは基本的にランダムであるため、そのまま圧縮せずに送信しなくてはならない。場合によって、圧縮ヘッダ３４は、ここでＸＸと示す、元のヘッダ情報（６ビット）を含むこともある。次いで、圧縮ヘッダ３４は、図２に示し、それに関連して説明したとおり、上記の無線インタフェース２８を介して受信機８９に送信される。受信機２９側では、例えばＲＯＣＣＯ圧縮復元部等の、周知のヘッダ復元アルゴリズムによって、展開部３６が圧縮ヘッダ３４を復元する。図３に示すように、復元ヘッダ３８は、トランスポート層ヘッダ３０の元のＩＰ、ＵＤＰおよびＲＴＰヘッダフィールドを含む。
【００２４】
図４に、本発明の一実施例によるヘッダ圧縮処理を示す。元の完全な状態のＩＰ／ＵＤＰ／ＲＴＰトランスポート層ヘッダ３０（図３に示す）は、本発明の圧縮部＋４０によって、周知のヘッダ圧縮アルゴリズム（ＲＯＣＣＯ等）に従って圧縮される。その結果、ＣＲＣ＋と、場合によって、ここでＸと示す元のヘッダ情報の一部を含む圧縮ヘッダ４２が得られる。特に、圧縮部＋４０は、トランスポート層ヘッダのみならず、トランスポート層ペイロードをも保護することができる単一のＣＲＣ＋を算出する。このようにして、ＣＲＣ＋は、通常のヘッダ圧縮ＣＲＣとトランスポート層チェックサムの両方の代わりになり得るのである。
【００２５】
一実施例では、圧縮ヘッダ４２と一緒にＣＲＣ＋のみが送信され、その結果、ヘッダオーバーヘッドを約１０ビットにまで削減することができる。他の実施例では、圧縮ヘッダ４２に、非圧縮の元のヘッダ情報（Ｘと示す）を６ビットまで含ませることができる。これにより、総合ヘッダオーバーヘッドは、従来必要であった４オクテットよりかなり少ない２オクテット程度になる。
【００２６】
ヘッダオーバーヘッドを削減すること以外にも、ＣＲＣ＋はさらに従来のトランスポート層チェックサムより信頼性が高いという利点を有する。よって、一実施例では、ＣＲＣ＋を使用して、通常のトランスポート層チェックサムより確実に、パケット内のデータの信頼性を確認することができる。
【００２７】
図５は、圧縮部＋４０（図４に示す）を機能ブロック図として展開したものである。一般的に、データパケットは圧縮部＋４０のＣＲＣ＋算出部５０で受信される。ＣＲＣ＋算出部５０は、ＣＲＣ＋をトランスポート層ヘッダとペイロードの両方に対して算出する。次いで、ヘッダは、周知のヘッダ圧縮アルゴリズムに従ってヘッダ圧縮部５２で圧縮される。次に、ＣＲＣ＋は、圧縮ヘッダと共に、送信機５４に転送され、図示のとおり、そこから（ペイロードと一緒に）次の送信先に送信される。実際には、ＣＲＣ＋算出部５０、ヘッダ圧縮部５２および送信機５４を、１つまたは複数のＰＬＤ、マイクロプロセッサ、マイクロコントローラまたはＡＳＩＣ等のプログラミング可能な集積回路装置によって実現することが可能であることは当業者には明らかであろう。
【００２８】
復元部＋４４（図４に示す）の構成要素も圧縮部＋４０について説明したものと同様のものを使用することができる。これらの要素は、図６に示し、以下に説明するとおりである。図に示すように、圧縮ヘッダを有するデータパケットがヘッダ復元部６０によって受信される。ある実施形態では、ヘッダ復元部６０は、周知のヘッダ圧縮アルゴリズムに従ってトランスポート層ヘッダを復元する。ＣＲＣ＋抽出部６２は、含まれるＣＲＣ＋を抽出し、復元されたヘッダに対して新しいＣＲＣ＋を算出する。確認処理部６４は、新しいＣＲＣ＋を含まれていたＣＲＣ＋と比較する。一致すれば、復元処理が正しく行われたことと認識される。他の実施形態では、確認処理部６４は、さらにＣＲＣ＋を用いてペイロードの確認も行う。従って、この実施形態では、単一の誤り検出コードによって、パケット全体（ヘッダおよびペイロード）の正確性を確認することができる。このような確認処理は、従来のトランスポート層チェックサムを使用した確認処理より信頼性が高いという利点を有する。パケットは、復元されたヘッダと共に、目的のアプリケーションに送信される。
【００２９】
上述の説明は、本発明を実施するための好適な形態を説明するものであり、本発明の範囲は、この説明によって限定されるものではない。その代わり、本発明の技術範囲は、上記の請求項に記載してある。
【図面の簡単な説明】
【図１】  図１には、典型的な音声データパケットを示す。
【図２】  図２には、パケット交換通信環境を示す。
【図３】  図３には、一般的なヘッダ圧縮処理を示す。
【図４】  図４には、本発明の実施形態による一般的なヘッダ圧縮処理を示す。
【図５】  図５は、図４に示した実施形態による圧縮部の機能ブロック図である。
【図６】  図６は、図４に示した実施形態による展開部の機能ブロック図である。
【図１】
0004859323.tif 000002
【図２】
0004859323.tif 000003
【図３】
0004859323.tif 000004
【図４】
0004859323.tif 000005
【図５】
0004859323.tif 000006
【図６】
0004859323.tif 000007