JP3730835B2 - パケット伝送方法、中継装置およびデータ端末 - Google Patents
パケット伝送方法、中継装置およびデータ端末 Download PDFInfo
- Publication number
- JP3730835B2 JP3730835B2 JP2000146787A JP2000146787A JP3730835B2 JP 3730835 B2 JP3730835 B2 JP 3730835B2 JP 2000146787 A JP2000146787 A JP 2000146787A JP 2000146787 A JP2000146787 A JP 2000146787A JP 3730835 B2 JP3730835 B2 JP 3730835B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- header
- compressed
- full
- received
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/38—Flow control; Congestion control by adapting coding or compression rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のデータ端末間で行われるパケットの送受信を行うパケット伝送方法、ならびにこれに用いられる中継装置およびデータ端末に関する。
【０００２】
【従来の技術】
近年、画像データや音声データ等のリアルタイム性を要求されるデータを、インターネットを介して伝送したいという要求が強くなってきている。かかる要求に応えるためのプロトコルとして、インターネットの標準化団体であるIETF（Internet Engineering Task Force）が発行するRFC（Request For Comment）1889には、RTP（Realtime Transport Protocol）が規定されている。このRTPによれば、▲１▼ペイロードタイプの指定、▲２▼シーケンス番号の付与、▲３▼タイムスタンプの付与といった機能が規定されており、これにより音声や映像などの実時間情報をインターネット上で伝送することができるようになっている。このRTPは、通常、ネットワーク層のIP（Internet Protocol）およびトランスポート層のUDP（User Datagram Protocol）の上位層として利用されるものである。
【０００３】
ここで、図１１（ａ）は、RTP、UDPおよびIPに従って送信対象となるデータ（音声データまたは画像データ等）に付加されるRTPヘッダ、UDPヘッダおよびIPヘッダ（以下、これらを総称して「RTP/UDP/IPヘッダ」という）の内容を示す図である。なお、以下では、このRTP/UDP/IPヘッダを含むパケットをIPパケットと呼ぶ。
【０００４】
ここで、同図に示すように、IPヘッダは２０バイト、UDPヘッダは８バイト、RTPヘッダは１２バイトとなり、これらのヘッダの合計のデータ量は４０バイトとなる。一方、１つのIPパケットに含まれる画像データは例えば５０バイト程度であるから、かかる画像データをパケット化して伝送する場合、そのオーバーヘッドは４４％にも達することとなる。同様に、音声データを伝送する場合、１つのパケットに含まれる音声データを２０バイトとすれば、オーバーヘッドは６６％にも達することとなる。実際には、さらに他のレイヤにおいて付加されるヘッダがあるため、１つのパケットに占めるヘッダの割合が大きくなり、通信の効率が低下してしまうという問題があった。
【０００５】
かかる問題を解決するための技術として、IETFが発行するRFC2508には、RTP/UDP/IPヘッダを圧縮するＲＴＰ圧縮プロトコルが開示されている。このＲＴＰ圧縮プロトコルによれば、図１１（ａ）に示すRTP/UDP/IPヘッダを、図１１（ｂ）に例示するヘッダ（以下、「圧縮ヘッダ」という）に圧縮することができる。詳述すると、以下の通りである。
【０００６】
この方法は、例えば、複数のデータ端末間でネットワークを介したパケットの送受信が行われる場合に、当該ネットワークに含まれる２つのノード間において用いられる。具体的には、これらのうちの一方のノード（以下、「送信側ノード」という）は、上記各データ端末間で交換されるIPパケットのうちの一部のIPパケット内のRTP/UDP/IPヘッダを圧縮ヘッダに変換し、ヘッダ圧縮パケットとして他方のノード（以下、「受信側ノード」という）に送信する一方、他の一部のIPパケット内のRTP/UDP/IPヘッダは圧縮することなく、フルヘッダパケットとして受信側ノードに送信するのである。一方、受信側ノードは、送信側ノードから受信したヘッダ圧縮パケットまたはフルヘッダパケットを、IPパケットに復元して次のノードまたは受信側のデータ端末に送信する。なお、フルヘッダとは、図１１（ａ）に示したRTP/UDP/IPヘッダに含まれるlengthを、当該フルヘッダを特定するためのCONTEXT_ID、および送信側ノードからの送信順に順次付される連続番号であるリンクシーケンス番号link_seqを含む情報に置き換えたものである。
【０００７】
ここで、図１１（ｂ）に示す圧縮ヘッダの内容について説明する。
まず、図１１（ａ）に示すRTP/UDP/IPヘッダ内の密なハッチングが施された部分のデータ、すなわち、IPヘッダ内のバージョン番号（Ｖ）や、RTPヘッダ内のペイロードタイプ（ＰＴ；画像データであるか音声データであるか等を示すデータのフォーマットや、符号化方法等についての情報を含むデータ）等は、送信側ノードから送信される各パケットにおいて共通のデータ（以下、「一定値フィールド」という）である。従って、図１１（ｂ）に示すように、圧縮ヘッダ内にはこの一定値フィールドのデータは含まれない。送信側ノードは、送信対象となるIPパケットのうち、少なくとも最初のIPパケットは一定値フィールドを含むフルヘッダパケットとして受信側ノードに送信する一方、その後のIPパケット内のRTP/UDP/IPヘッダは、一定値フィールドを含まない圧縮ヘッダに変換し、ヘッダ圧縮パケットとして受信側ノードに送信する。一方、受信側ノードは、少なくとも最初に受信するフルヘッダパケット内のフルヘッダからRTP/UDP/IPヘッダを復元して内部の記憶装置に書込むとともに、当該RTP/UDP/IPヘッダ内の一定値フィールドを用いて、以後受信するヘッダ圧縮パケット内の圧縮ヘッダの一定値フィールドを復元するのである。
【０００８】
ただし、一定値フィールドのデータは、必ずしも全てのIPパケットにおいて一定値となるとは限らず、変更が生じる場合もあり得る。このような変更があった場合、送信側ノードは、当該IPパケット内のRTP/UDP/IPヘッダを圧縮することなく、フルヘッダパケットとして受信側ノードに送信するようになっている。
【０００９】
また、図１１（ａ）に示すRTP/UDP/IPヘッダ内のハッチングが施されていない部分のデータ、すなわち、IPヘッダ内のID、RTPヘッダ内のシーケンス番号（sequence number）およびタイムスタンプ（timestamp；当該パケットが送信された時刻を表す）は、送信対象となる各IPパケット間で値が連続的に（所定の差分値ずつ）変化し、連続する２つのIPパケット間における差分値（変化量）が一定と期待されるデータ（以下、「差分一定フィールド」という）である。図１１（ｂ）に示すように、圧縮ヘッダ内には、原則としてこの差分一定フィールドのデータは含まれない。上述したように、受信側ノードは、記憶装置にRTP/UDP/IPヘッダを保持しており、このRTP/UDP/IPヘッダ内の差分一定フィールドの値に対して所定の差分値を順次加えることにより、以後受信する圧縮ヘッダ内の差分一定フィールドを復元するのである。
【００１０】
ただし、差分一定フィールドのデータに関しては、必ずしも全てのIPパケット間で差分値が一定値になるとは限らず、差分値に変更がある場合も生じる。かかる場合には、変化後の差分値を受信側ノードに対して通知すれば、当該受信側ノードは、記憶装置に保持されたRTP/UDP/IPヘッダの内容と新たに通知された差分値とから、その後に受信したヘッダ圧縮パケット内の圧縮ヘッダの差分一定フィールドの内容を復元することができる。このため、図１１（ｂ）に示す圧縮ヘッダにおいては、差分一定フィールドについての差分値の変更の有無を示すフラグＳ、ＴおよびＩが含まれるとともに、各差分値に変更があった場合には、図１１（ｂ）に破線で示すように、当該変更後の差分値が付加されることとなる。具体的には、RTPヘッダ内のシーケンス番号の差分値に変更があった場合には、フラグＳに「１」がセットされるとともに、図１１（ｂ）に破線で示すように、当該変更後のシーケンス番号の差分値を表すシーケンス番号差分値（delta RTP sequence）が圧縮ヘッダに付加されることとなる。同様に、RTPヘッダ内のタイムスタンプの差分値に変更があった場合、このフラグＴに「１」がセットされるとともに、図１１（ｂ）に破線で示すように、当該変更後のタイムスタンプの差分値を表すタイムスタンプ差分値（delta RTP timestamp）が圧縮ヘッダに含まれることとなる。また、IPヘッダ内のIDの差分値に変更があった場合、フラグＩに「１」がセットされるとともに、当該変更後のIDの差分値を示すID差分値（delta IP ID）が圧縮ヘッダに付加されることとなる。
【００１１】
さらに、図１１（ｂ）に示すように、圧縮ヘッダには、フルヘッダと同様、CONTEXT_IDおよびlink_seqが含まれている。受信側ノードにおいては、このCONTEXT_IDによって特定されるRTP/UDP/IPヘッダの内容に従って、当該圧縮ヘッダが復元されることとなる。また、受信側ノードは、送信側ノードから順次受信するパケット（ヘッダ圧縮パケットまたはフルヘッダパケット）内のリンクシーケンス番号link_seqを参照し、このリンクシーケンス番号に欠番が生じた場合には、送信側ノードと受信側ノードとの間でパケットの喪失が発生したと判定するようになっている。
【００１２】
次に、図１２を参照して、送信側ノードと受信側ノードとの間でなされるパケット転送のための手順を説明する。なお、同図においては、フィールドＡはRTP/UDP/IPヘッダ内の一定値フィールド（すなわち、図１１（ａ）の密なハッチングが施されたデータのうちのいずれか）を表し、フィールドＢは差分一定フィールド（すなわち、図１１（ａ）のハッチングが施されていないデータのうちのいずれか）を表すものとする。また、図１２において、「Ｆ」はフルヘッダパケットを示し、「Ｃ」はヘッダ圧縮パケットを示すものとする。
【００１３】
まず、送信側ノードは、送信側データ端末から受信側データ端末宛に送信されたIPパケットａを受け取ると、このIPパケットａ内のRTP/UDP/IPヘッダを内部の記憶装置に記憶するとともに、当該ヘッダ内のlengthをCONTEXT_IDおよびリンクシーケンス番号link_seqに置き換えてフルヘッダを生成し、このフルヘッダと、上記IPパケット内のRTP/UDP/IPヘッダ以外の部分のデータ（以下、「RTPペイロード」という）とを含むフルヘッダパケットを受信側ノードに送信する（図１２中の▲１▼）。このフルヘッダパケットを受け取った受信側ノードは、このパケット内のフルヘッダからRTP/UDP/IPヘッダを復元し（すなわち、フルヘッダ内のCONTEXT_IDおよびlink_seqを取出して）、当該ヘッダを含むIPパケットを次のノードまたは受信側データ端末に送信する。なお、この際に、復元されたRTP/UDP/IPヘッダを内部の記憶装置に記憶しておく。
【００１４】
続いて、送信側ノードは、IPパケットａの次に受け取ったIPパケットｂ内のRTP/UDP/IPヘッダを圧縮ヘッダに変換して、当該ヘッダ圧縮パケットｂを受信側ノードに送信する（図１２中の▲２▼）。このヘッダ圧縮パケット内の圧縮ヘッダには、パケットｂ内の差分一定フィールドＢの値「１」と、直前に受け取ったパケットａのフルヘッダ内の差分一定フィールドＢの値「０」との差分値ΔＢ（＝１）が付加されるとともに、差分値の変更の有無を示すフラグ（図１１（ｂ）に示すフラグＳ、ＴまたはＩ）に「１」がセットされている。
【００１５】
このヘッダ圧縮パケットｂを受信した受信側ノードは、記憶装置に記憶されたIPパケットａのRTP/UDP/IPヘッダ内の差分一定フィールドＢの値に、今回通知された差分値ΔＢを加えることにより、ヘッダ圧縮パケットｂ内の圧縮ヘッダの差分一定フィールドＢを求める。そして、当該差分一定フィールドＢ、およびIPパケットａのRTP/UDP/IPヘッダ内の一定値フィールドＡを含むRTP/UDP/IPヘッダと、RTPペイロードとを含むIPパケットｂを送信する。なお、IPパケットｂを復元する際に参照されるRTP/UDP/IPヘッダ（この場合にはIPパケットａ内のRTP/UDP/IPヘッダ）は、ヘッダ圧縮パケットｂ内のCONTEXT_IDによって特定される。また、ここではIPパケットｂのRTP/UDP/IPヘッダと、今回通知された差分値ΔＢとが内部の記憶装置に記憶される。
【００１６】
続いて、IPパケットｃを受け取ると、送信側ノードは、当該IPパケットｃ内のフィールドＢの値と、前回受信されたIPパケットｂ内の差分一定フィールドＢとの差分値を求める。ここでは、差分値ΔＢは「１（＝３−２）」であり、前回受信側ノードに対して通知した差分値と同一であるから、新たに差分値を通知する必要はない。従って、送信側ノードは、差分値（すなわち、図１１（ｂ）において破線で示される情報）が付加されない圧縮ヘッダを含んだヘッダ圧縮パケットｃを受信側ノードに対して送信する（図１２中の▲３▼）。一方、このヘッダ圧縮パケットｃを受信した受信側ノードは、先に送信したパケットｂの差分一定フィールドＢに対して記憶装置に記憶されたΔＢを加えることによってヘッダ圧縮パケットｃ内の圧縮ヘッダの差分一定フィールドＢを復元し、この値、およびフルヘッダパケットａのフルヘッダ内の一定値フィールドＡを含むRTP/UDP/IPヘッダとRTPペイロードとからなるIPパケットｃを送信する。以後、パケットｄについても同様の処理がなされる。
【００１７】
さて、次に送信側ノードが受信するIPパケットｅの差分一定フィールドＢは「５」であり、前回のIPパケットｄの差分一定フィールドＢとの差分値は「２」である。このように、差分値ΔＢに変更があった場合、送信側ノードは、変更後の新たな差分値が付加され、フラグに「１」がセットされた圧縮ヘッダを含むヘッダ圧縮パケットｅを受信側ノードに送信する。受信側ノードは、こうして通知された新たな差分値と、IPパケットｄの差分一定フィールドＢの値とを加えることによりパケットｅの差分一定フィールドＢを復元し、当該差分一定フィールドＢを含むIPパケットを送信する。
【００１８】
続いて、次に送信側ノードが受信するIPパケットｇは、直前に受信したIPパケットｅと比較して一定値フィールドＡが異なっている。この場合、送信側ノードは、当該IPパケット内のRTP/UDP/IPヘッダを圧縮せず、パケットｇ内のRTP/UDP/IPヘッダ内のlengthをCONTEXT_IDおよびlink_seqに置き換えたフルヘッダを含むフルヘッダパケットｇを受信側ノードに対して送信する。このフルヘッダパケットｇを受け取った受信側ノードは、これに含まれるフルヘッダをRTP/UDP/IPヘッダに復元して内部の記憶装置に記憶する。
【００１９】
以上がRFC2508に規定されたヘッダ圧縮方法（以下、「従来方法Ａ」という）である。しかしながら、この圧縮方法においては、以下に示す問題があった。
【００２０】
例えば、図１３に示すように、ヘッダ圧縮パケットｃが送信側ノードと受信側ノードとの間で何らかの原因により喪失した場合を想定する。上述したように、受信側ノードは、IPパケットｄ内の差分一定フィールドＢを、IPパケットｃ内の差分一定フィールドＢに差分値ΔＢを加えることにより復元するようになっているため、ヘッダ圧縮パケットｃが喪失した場合にはヘッダ圧縮パケットｄ内の差分一定フィールドＢを復元することができない。この結果、受信側ノードにおいては、次にフルヘッダパケットｇが受信されるまでの間に受信したパケット、すなわち、図１３におけるパケットｄ、ｅおよびｆは破棄せざるを得ない。このように、一部のパケットの喪失に伴ってバースト的なパケットの喪失が発生する結果、ヘッダを圧縮しない方法を採った場合よりもスループットが低下してしまう場合も生じ得る。特に送信側ノードと受信側ノードとの間に無線区間が含まれる場合には、当該無線区間においてパケットの喪失が発生しやすいため、これに伴ってパケットのバースト的なロスが多く引き起こされるという問題があった。かかる問題を解決するための技術として、IETFが発行するRFC2507および2508ならびにInternet-Draftには、以下の各技術が開示されている。
【００２１】
方法１：フルヘッダパケットの周期的な送信（RFC2507）
上述した従来方法Ａにおいては、送信側ノードは、ヘッダ内の一定値フィールドに変更があった場合にのみフルヘッダパケットを送信するようにしたが、この方法１においては、図１４に示すように、一定値フィールドの変更の有無に関わらず、送信対象となる複数のIPパケットを一定個数間隔毎に選択し、選択したIPパケットについてはヘッダを圧縮することなくフルヘッダパケットとして受信側ノードに送信する一方、それ以外のパケットについてはヘッダを圧縮してヘッダ圧縮パケットとして受信側ノードに送信するようになっている。上記従来方法Ａにおいては、一定値フィールドに変更がない限り、受信側ノードにはフルヘッダパケットが送信されないため、以後の全てのパケットが破棄されることとなるが、本方法によれば、一定周期でフルヘッダパケットが送信されるようになっているため、一部のパケットの喪失に起因して破棄されるパケットの数を減らすことができるという利点がある。しかしながら、本方法においては、フルヘッダパケットの送信周期を長くすると、破棄されるパケットの数が増加する一方、フルヘッダパケットの送信周期を短くするとオーバーヘッドの大きいフルヘッダパケットが多数送信されることとなり、通信効率の低下を招くこととなるといった問題がある。
【００２２】
方法２：バックチャネルによるフルヘッダの要求（RFC2507,2508）
本方法においては、図１５に示すように、パケットの喪失を検知すると、受信側ノードは、送信側ノードに対してフルヘッダパケットを要求するためのメッセージであるCONTEXT_STATEを送信するようになっている。送信側ノードは、このCONTEXT_STATEを受信すると、次に送信すべきIPパケットをフルヘッダパケットとして受信側ノードに送信する。この結果、受信側ノードにおいて、一部のパケットの喪失に起因して他のパケットが破棄される期間を、パケットのロスが発生してから、CONTEXT_STATEに応じて送信されたフルヘッダパケットを受信するまでの期間に抑えることができる。しかしながら、本方法においては、受信側ノードがCONTEXT_STATEを送信してから、フルヘッダパケットを受信するまでの時間、すなわちＲＴＴ（Round Trip Time）が大きいと、破棄されるパケットが多くなるという問題がある。無線区間を含んでパケットの送受信が行われる場合には、当該区間において特にＲＴＴが長くなるから、かかる問題は特に顕著に現れる。
【００２３】
方法３：Twiceアルゴリズム（RFC2507）
本方法においては、パケットの喪失が発生した後に受信されるヘッダ圧縮パケット内の圧縮ヘッダを、当該パケットの喪失が発生する直前に受信し、復元したRTP/UDP/IPヘッダに基づいて復元するようになっている。例えば、図１６に示すように、パケットｂが正常に受信された後、パケットｃが喪失し、次にパケットｄが正常に受信された場合を想定する。この場合、パケットｂからパケットｄの間で差分値ΔＢの値に変化がないとすれば、パケットｄ内の差分一定フィールドＢは、パケットｂの差分一定フィールドＢにΔＢを２倍した数値を加えることにより算出することができる。さらに、本方法においては、圧縮ヘッダ内にUDPチェックサムを含ませるようになっており（図１１（ｂ）参照）、このUDPチェックサムを用いて、パケットが正しく復元できたか否かを判断するようになっている。しかしながら、図１６に示すように、パケットｋが喪失し、かつ、パケットｊからパケットｋの間で差分一定フィールドの差分値ΔＢに変化があった場合には、パケット喪失直後に受信されたパケットｌを正確に復元することができないという問題がある。特に、無線区間を含んでパケットの送受信が行われる場合にあっては、パケットの喪失が連続的に（すなわち、長い期間にわたって）発生する。かかる場合には、喪失された多数のパケット間で差分値ΔＢが変化しない場合は少ないと考えられるから、上記問題は特に顕著に現れる。
【００２４】
方法４：ROCCO（Internet-Draft）
本方法においては、送信されるメディアの特性に基づいて、差分値ΔＢを推測するようになっている。例えば、図１７においては、パケットｇおよびｈが喪失し、かつ、パケットｇからパケットｈの間で差分値ΔＢの値に変化があった場合を想定している。この場合、送信されるメディアの特性に基づいて、差分値ΔＢの変化が推測され、推測された差分値ΔＢをパケットｆに加えることにより、パケットｉを復元することができる。さらに、本方法においては、誤り検出符号（CRC）によって正しく復元できたか否かを確認するようになっている。本方法によれば、差分値ΔＢに変化があった場合であっても、その後のパケットを復元することができる。しかしながら、本方法においては、差分値ΔＢの変化をどのように推測するかが問題となる。
【００２５】
【発明が解決しようとする課題】
このように、IPパケットのRTP/UDP/IPヘッダを圧縮した場合であっても効率よくデータ通信を行うための方法として各種の方法が提案されてはいるものの、いずれの方法も何らかの問題を有しており、送信側ノードと受信側ノード間で生じたあるパケットの喪失に起因して破棄されるパケットの数を効果的に減らすには限界があるのが現状であった。
【００２６】
本発明は、上述した事情に鑑みてなされたものであり、送受信すべきパケットのヘッダを圧縮する場合であっても、あるパケットの喪失に起因して破棄されるパケットの数を有効に減らすことができるパケット伝送方法、中継装置およびデータ端末を提供することを目的としている。
【００２７】
【課題を解決するための手段】
上述した課題を解決するために、本発明は、送信側と受信側とを含むネットワークにおいて、前記送信側は、送信すべき非圧縮パケットを、フルヘッダを有するフルヘッダパケットまたは圧縮ヘッダを有するヘッダ圧縮パケットに変換して前記受信側に送信する一方、前記受信側は、前記送信側から送信されたフルヘッダパケットまたはヘッダ圧縮パケットを受信して非圧縮パケットに変換するパケット伝送方法であって、前記受信側は、前記送信側と受信側との間で前記フルヘッダパケットまたはヘッダ圧縮パケットの喪失が発生した場合には、当該パケット喪失後、次にフルヘッダパケットを受信するまでの間に受信したヘッダ圧縮パケットを保持し、前記パケット喪失後に受信したフルヘッダパケット内のフルヘッダの内容に基づいて、前記保持したヘッダ圧縮パケット内の圧縮ヘッダを復元することを特徴とするパケット伝送方法を提供するものである。
【００２８】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について説明する。かかる実施の形態は、本発明の一態様を示すものであり、この発明を限定するものではなく、本発明の範囲内で任意に変更可能である。
【００２９】
Ａ：第１実施形態
Ａ−１：第１実施形態の構成
図１は、本発明に係るパケット伝送方法を適用可能な通信システムの構成を模式的に例示するブロック図である。この通信システムにおいては、送信側データ端末１と受信側データ端末２とが、ネットワーク３を介してパケットの交換を行うことができるようになっている。なお、以下では、送信側データ端末１が受信側データ端末２に対してパケットを送信する場合を例に説明を進める。
【００３０】
ネットワーク３には、送信側ノード３ａおよび受信側ノード３ｂが含まれている。この送信側ノード３ａおよび受信側ノード３ｂは、送信側データ端末１と受信側データ端末２との間で交換されるパケットの中継を行う役割を担っている。なお、図１に示すネットワーク３には、送信側ノード３ａおよび受信側ノード３ｂが１つずつ含まれている場合を例示しているが、本発明を適用できるのはかかる場合に限られず、より多数のノードが含まれていてもよいことはいうまでもない。
【００３１】
かかる構成の下、送信側データ端末１は、受信側データ端末２を宛先に特定したパケットをネットワーク３に対して順次送信する。ここで、送信側データ端末１から送信されるパケットは、図１１（ａ）に示したRTP/UDP/IPヘッダを含むIPパケットである。送信側ノード３ａは、この送信側データ端末１から送信されたIPパケットを順次受信し、受信したIPパケットをフルヘッダを含むフルヘッダパケットまたは圧縮ヘッダを含むヘッダ圧縮パケットのいずれかに変換して受信側ノード３ｂに送信する。ここで、フルヘッダとは、上述したように、IPパケット内のRTP/UDP/IPヘッダにおけるIPヘッダまたはUDPヘッダに含まれるlength値を、CONTEXT_IDまたはlink_seqを含むデータに代えたものである。一方、こうして送信側ノード３ａから送信されたヘッダ圧縮パケットまたはフルヘッダパケットを受信した受信側ノード３ｂは、ヘッダ圧縮パケット内の圧縮ヘッダまたはフルヘッダパケット内のフルヘッダをRTP/UDP/IPヘッダに復元するとともに、当該RTP/UDP/IPヘッダを含むIPパケットを受信側データ端末２に送信する。受信側データ端末２は、受信側ノード３ｂから送信されたIPパケットを受信し、受信したIPパケットに従って所定の処理（例えば、RTPペイロードに従った画像の表示や音声の再生等）を行う。
【００３２】
なお、上記従来の技術にも示したように、フルヘッダパケットは、当該フルヘッダパケットに含まれるフルヘッダの内容のみに基づいてRTP/UDP/IPヘッダを含むIPパケットを復元可能なパケットである。なお、RTP/UDP/IPヘッダ内のlength値は、フルヘッダにおいてCONTEXT_STATEおよびlink_seqに置き換えられるが、下位レイヤの情報から復元可能である。これに対し、ヘッダ圧縮パケットは、当該ヘッダ圧縮パケットに含まれる圧縮ヘッダのみではRTP/UDP/IPヘッダを含むIPパケットを復元することはできないが、その他のパケット（フルヘッダパケット等）の内容に基づいて、IPパケットに復元可能なパケットである。
【００３３】
次に、図２を参照して、受信側ノード３ｂの構成を説明する。同図に示すように、受信側ノード３ｂは、受信部３１ｂ、送信部３２ｂ、制御部３３ｂおよび記憶部３４ｂと、これらの各部を接続するバス３５ｂとを含んで構成されている。
【００３４】
受信部３１ｂは、送信側ノード３ａから送信されたフルヘッダパケットまたはヘッダ圧縮パケットを通信回線を介して受信し、制御部３３ｂに出力するための手段である。また、送信部３２ｂは、制御部３３ｂから出力されたデータを通信回線を介して受信側データ端末２に送信するための手段である。
【００３５】
制御部３３ｂは、ＣＰＵ等を含んで構成され、記憶部３４ｂに記憶されたプログラムを実行することによりこの受信側ノード３ｂの各部を制御するための手段である。具体的には、制御部３３ａは、送信側ノード３ａから受信部３１ｂを介して受信したフルヘッダパケットまたはヘッダ圧縮パケットをIPパケットに変換し、送信部３２ｂを介して受信側データ端末２に送信する機能を有している。また、本実施形態における制御部３３ｂは、送信側ノード３ａと受信側ノード３ｂとの間で生じたパケットの喪失を検知することができる。そして、かかるパケットの喪失が検知された場合、制御部３３ｂは、送信側ノード３ａに対してフルヘッダパケットの送信を要求するためのCONTEXT_STATEを送信するようになっている。
【００３６】
ところで、上記従来の技術に示した各手法においては、送信側と受信側との間でパケットの喪失が生じた場合、喪失したパケット以後のパケットであって、次にフルヘッダパケットが受信されるまでの間に受信されたパケットは破棄されるようになっていた。これに対し、本実施形態における受信側ノード３ｂ内の制御部３３ｂは、パケットの喪失を検知した後、次にフルヘッダパケットを受信するまでの間に受信されたヘッダ圧縮パケットを記憶部３４ｂに順次書き込むようになっている。そして、当該パケットの喪失後にフルヘッダパケットを受信すると、当該フルヘッダパケット内のフルヘッダの内容に基づいて、記憶部３４ｂに記憶されたヘッダ圧縮パケット内の圧縮ヘッダを復元してIPパケットを生成し、受信側データ端末２に送信するようになっている。なお、制御部３３ｂが行う処理については、後の動作説明において詳述する。
【００３７】
なお、送信側ノード３ａも、上述した受信側ノード３ｂと同様の構成となっている。すなわち、送信側ノード３ａは、送信側データ端末１からのIPパケットを受信する受信部３１ａと、当該送信側ノード３ａ内の各部を制御する制御部３３ａと、記憶部３４ａと、制御部３３ａから出力されたパケットを受信側ノード３ｂに対して送信する送信部３２ａとを含んで構成されている。ただし、本実施形態においては、送信側ノード３ａ内の制御部３３ａは、送信側データ端末１から送信されたIPパケットのうち、少なくとも最初のIPパケットをフルヘッダパケットとして受信側ノード３ｂに送信する一方、その他のIPパケットをヘッダ圧縮パケットとして受信側ノード３ｂに送信するようになっている。また、送信側ノード３ａ内の制御部３３ａは、受信側ノード３ｂからCONTEXT_STATEを受信した場合、その直後に送信すべきIPパケットをフルヘッダパケットとして受信側ノード３ｂに送信するようになっている。
【００３８】
Ａ−２：第１実施形態の動作
図３は、本実施形態に係るパケット伝送方法における動作を例示するタイミングチャートである。
同図に示すように、送信側データ端末１から送信対象となる最初のIPパケットａを受信すると、送信側ノード３ａ内の制御部３３ａは、当該パケットをフルヘッダパケットとして受信側ノード３ｂに送信する。具体的には、当該IPパケット内のRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダに含まれるlengthフィールドをCONTEXT_IDおよびlink_seqを含む情報に置き換えたフルヘッダを生成し、当該フルヘッダと、IPパケット中のRTPペイロードとを含むフルヘッダパケットａを受信側ノード３ｂに対して送信する。
【００３９】
次に、送信側データ端末１からIPパケットｂを受信した場合、制御部３３ａは、当該IPパケットｂをヘッダ圧縮パケットとして受信側ノード３ｂに送信する。詳述すると、制御部３３ａは、まず、当該IPパケットのRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダ内の差分一定フィールドの値と、記憶部３４ａに記憶されているIPパケットａのRTP/UDP/IPヘッダの差分一定フィールドの値との差分値を演算する。そして、制御部３３ａは、当該差分値を含む圧縮ヘッダを生成し、この圧縮ヘッダと、IPパケットｂ内のRTPペイロードとを含むヘッダ圧縮パケットを、受信側ノード３ｂに対して送信する。
【００４０】
続いて、送信側データ端末１からIPパケットｃを受信すると、制御部３３ａは、当該IPパケット内のRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダの差分一定フィールドの値と、記憶部３４ａに記憶されているIPパケットｂのRTP/UDP/IPヘッダの差分一定フィールドの値との差分値を求め、当該差分値が、記憶部３４ａに記憶されている差分値（すなわちIPパケットｂとIPパケットａとの間の差分値）と同一であるか否かを判定する。この結果、同一であると判定した場合には、受信側ノード３ｂに対して新たに差分値を通知する必要はないから、制御部３３ａは、差分値を含まない圧縮ヘッダを生成するとともに、当該圧縮ヘッダを含むヘッダ圧縮パケットｃを受信側ノード３ｂに対して送信する。
これに対し、上記差分値が同一でないと判定した場合には、今回新たに求められた差分値を受信側ノード３ｂに対して通知すべく、当該差分値を含む圧縮ヘッダを生成するとともに、当該圧縮ヘッダとIPパケットｃ内のRTPペイロードとを含むヘッダ圧縮パケットを受信側ノード３ｂに対して送信する。さらに、制御部３３ａは、記憶部３４ａに既に記憶されている差分値（すなわち、IPパケットａとIPパケットｂとの間の差分値）を、今回新たに得られた差分値に更新する。
【００４１】
以後、送信側データ端末１からIPパケットｄ、ｅおよびｆを受信した場合も、上記IPパケットｃと同様の処理がなされ、差分値を含むヘッダ圧縮パケットまたは差分値を含まないヘッダ圧縮パケットが受信側ノード３ｂに送信される。
【００４２】
ここで、図３に示す例においては、送信側データ端末１からIPパケットｇを受信する直前に受信側ノード３ｂからのCONTEXT_STATEを受信した場合を想定している。この場合、送信側ノード３ａ内の制御部３３ａは、CONTEXT_STATEの受信直後に送信すべきIPパケットｇを、フルヘッダパケットｇとして送信する。以後同様に、送信側ノード３ａ内の制御部３３ａは、パケットｈ〜ｌについてはヘッダ圧縮パケットとして受信側ノードに送信する一方、CONTEXT_STATEの受信直後に送信すべきパケットｍについてはフルヘッダパケットとして受信側ノード３ｂに送信する。
【００４３】
一方、受信側ノード３ｂ内の制御部３３ｂは、フルヘッダパケットａを受信すると、これに含まれるフルヘッダからRTP/UDP/IPヘッダを復元し、これを含むIPパケットａを受信側データ端末２に送信するとともに、当該RTP/UDP/IPヘッダを記憶部３４ｂに記憶する。次に、ヘッダ圧縮パケットｂを受信すると、制御部３３ｂは、記憶部３４ｂに保持されたIPパケットａのRTP/UDP/IPヘッダの内容を参照してヘッダ圧縮パケットｂ内の圧縮ヘッダをRTP/UDP/IPヘッダに復元し、得られたIPパケットｂを受信側データ端末２に送信する。
【００４４】
ここで、図３においては、送信側ノード３ａから送信されたヘッダ圧縮パケットｃが何らかの理由により喪失された場合を例示している。この場合、受信側ノード３ｂ内の制御部３３ｂは、喪失したヘッダ圧縮パケットｃの次のヘッダ圧縮パケットｄを受信し、当該パケットｄ内のlink_seqがパケットｂ内のlink_seqから連続していないことによりパケットｃが喪失されたことを検知する。パケットｃの喪失が検知されると、制御部３３ｂは、送信側ノード３ａに対し、CONTEXT_STATEを送信するとともに、パケットの喪失から次のフルヘッダパケットを受信するまでの間に受信されるヘッダ圧縮パケットを記憶部３４ｂに順次書き込む。図３に示す例では、パケットｃの喪失が発生してからフルヘッダパケットｇを受信するまでの間に、ヘッダ圧縮パケットｄ〜ｆが受信され、これらのヘッダ圧縮パケットが順次記憶部３４ｂに書込まれることとなる。
【００４５】
次に、受信側ノード３ｂ内の制御部３３ｂは、CONTEXT_STATEに応じて送信側ノード３ａから送信されたフルヘッダパケットｇを受信する。ここで、本実施形態における制御部３３ｂは、このフルヘッダパケットｇ内の差分一定フィールドの値から、差分値Δを順次減じることによって、パケットｄ〜ｆのヘッダ内の差分一定フィールドを復元するようになっている。具体的には、図３に示すように、フルヘッダパケットｇ内の差分一定フィールドの値から差分値Δを減じることにより、パケットｆ内の差分一定フィールドの内容を復元し、こうして復元されたパケットｆ内の差分一定フィールドの値から差分値Δを減じることにより、パケットｅ内の差分一定フィールドの内容を復元する、といった具合である。さらに、本実施形態においては、記憶部３４ｂに記憶されたIPパケットｂのRTP/UDP/IPヘッダの内容に基づいて、パケットｄ〜ｆ内の一定値フィールドの内容も復元されるようになっている。こうして、パケットｄ〜ｆ内のRTP/UDP/IPヘッダの内容が復元されるのである。以下、図４に示すフローチャートを参照して、上記圧縮ヘッダの復元のために受信側ノード３ｂ内の制御部３３ｂが実行する処理の詳細について説明する。
【００４６】
まず、受信側ノード３ｂ内の制御部３３ｂは、link_seqの欠番によってパケットｃの喪失を検知すると、レジスタＮに「０」をセットする（ステップＳ１）。続いて、レジスタＮの内容を「１」だけインクリメントする（ステップＳ３）。
【００４７】
次に、ヘッダ圧縮パケットｄから復元されるべきRTP/UDP/IPヘッダのうち、一定値フィールド、length値、UDPチェックサムおよびマーカビットを復元する。具体的には、記憶部３４ｂに記憶されたIPパケットｂのRTP/UDP/IPヘッダを読み出し、当該ヘッダに含まれる一定値フィールドをパケットｄのRTP/UDP/IPヘッダの一定値フィールドとする。なお、UDPチェックサムおよびマーカビットは、図１１（ｂ）に示すように、圧縮ヘッダ内に含まれるものである。また、length値は、下位レイヤのヘッダに含まれる情報によって取得することができる。さらに、制御部３３ｂは、パケットｄに新たな差分値が含まれている場合（図１１（ｂ）に示す破線部分が含まれている場合）には当該差分値を抽出する（ステップＳ４）。
【００４８】
続いて、ステップＳ４において部分的（一定値フィールド等について）に復元されたRTP/UDP/IPヘッダと、ヘッダ圧縮パケットｄに含まれるRTPペイロードの内容をデータIP(1)として記憶部３４ｂに記憶するとともに、当該時点におけるIPヘッダのIDの差分値、RTPヘッダ内のシーケンス番号の差分値、およびタイムスタンプの差分値を、それぞれΔIP_ID(1)、ΔRTP_SN(1)およびΔRTP_TS(1)として記憶部３４ｂに書き込む（ステップＳ５）。なお、当該時点における各情報（ID、シーケンス番号およびタイムスタンプ）の差分値とは、パケットｄに新たな差分値が付加されている場合には当該差分値であり、含まれていない場合にはその時点において記憶部３４ｂに保持されている差分値である。
【００４９】
以後、フルヘッダパケットｇが受信されるまでの間に受信されるヘッダ圧縮パケットｅおよびｆ（ｎ＝２〜３）についても、ステップＳ２〜Ｓ５の処理が同様に行われる。
【００５０】
次に、フルヘッダパケットｇを受信すると、これに含まれるフルヘッダから取得されるRTP/UDP/IPヘッダを、IP(4)として記憶部３４ｂに記憶する（ステップＳ６）。続いて、パケットｆとフルヘッダパケットｇとの間で差分値に変更がないものとみなし、パケットｅとパケットｆとの間のID、SNおよびTSについての差分値、すなわち、ΔIP_ID(3)、ΔRTP_SN(3)、ΔRTP_TS(3)を、パケットｆとフルヘッダパケットｇとの間のIP、SNおよびTSについての差分値、すなわち、ΔIP_ID(4)、ΔRTP_SN(4)およびΔRTP_TS(4)とする（ステップＳ７）。つまり、
ΔIP_ID(4)＝ΔIP_ID(3)
ΔRTP_SN(4)＝ΔRTP_SN(3)
ΔRTP_TS(4)＝ΔRTP_SN(3)
とする。
【００５１】
次に、フルヘッダパケットｇの各差分一定フィールドの内容から、パケットｆとｇとの間の差分値とみなされた数値、すなわち、上述したΔIP_ID(4)、ΔRTP_SN(4)およびΔRTP_TS(4)を減じることにより、パケットｆの差分一定フィールドの内容を復元する（ステップＳ８）。具体的には、パケットｆについて、復元対象となるIPヘッダ内のID、RTPヘッダ内のシーケンス番号（SN）、およびRTPヘッダ内のタイムスタンプ（TS）の値を、それぞれIP(3).IP_ID、IP(3).RTP_SN、およびIP(3).RTP_TSとし、フルヘッダパケットｇについて、IPヘッダ内のID、RTPヘッダ内のシーケンス番号、およびRTPヘッダ内のタイムスタンプの値を、それぞれIP(4).IP_ID、IP(4).RTP_SN、およびIP(4).RTP_TSとすると、以下の演算によりパケットｆの差分一定フィールドの内容が復元できる。
IP(3).IP_ID＝IP(4).IP_ID−ΔIP_ID(4)
IP(3).RTP_SN＝IP(4).RTP_SN−ΔRTP_SN(4)
IP(3).RTP_TS＝IP(4).RTP_TS−ΔRTP_TS(4)
【００５２】
こうしてパケットｆのRTP/UDP/IPヘッダが復元されると、制御部３３ｂは、パケットｆに含まれていたUDPチェックサムを用い、正しく復元されたか否かを判定する（ステップＳ９）。この結果、正しく復元されたと判定される場合には、レジスタＮの値を「１」だけデクリメントした後（ステップＳ１０）、パケットｅおよびｄについても同様に、ステップＳ８およびＳ９の処理を実行する。
【００５３】
一方、ステップＳ９において、正しく復元できていないと判定される場合には、それよりも前に受信されたパケットについても正しく復元することはできないから、その時点で処理を止めてステップＳ１１に移行する。また、ステップＳ１０において、Ｎの値を「１」だけデクリメントした結果、Ｎの値が「０」となった場合には（ステップＳ１２）、復元対象となる全てのパケットの復元が終了したことを意味するから、ステップＳ１１に移行する。
【００５４】
制御部３３ｂは、ステップＳ１１において、正しく復元できた各パケットを、当該各パケットに含まれるRTPヘッダ内のシーケンス番号の順に、順次受信側データ端末２に送信する。なお、正しく復元できなかったパケットについては破棄される。
以上が本実施形態における動作である。
【００５５】
上述したように、本実施形態に係るパケット伝送方法によれば、パケット喪失が発生した後に受信されるヘッダ圧縮パケットを保持しておき、次に受信したフルヘッダパケットの内容に基づいてこれらのパケットのヘッダを復元するようになっている。ここで、上記従来の技術において示した各方法においては、パケットの喪失が発生した後、次のフルヘッダパケットが受信されるまでの間においては、各パケットが適切に受信されているにもかかわらず破棄しなければならないという問題があった。これに対し、本実施形態においては、パケットの喪失から次のフルヘッダパケット受信までの間に受信されたパケットを有効に利用することができる。従って、パケットの喪失によって、受信側データ端末におけるデータの再生等に与えられる影響を、従来の技術と比較して小さくすることができるという利点がある。
【００５６】
Ａ−３：第１実施形態の変形例
上記第１実施形態においては、パケットｃの喪失が発生してから次のフルヘッダパケットｇが受信されるまでの間に受信されたパケットｄ〜ｆの一定値フィールドを、当該パケットｃの喪失よりも前に受信されたIPパケットｂのRTP/UDP/IPヘッダの内容に従って復元するようにしたが、これに限らず、例えば、これらのパケットｄ〜ｆの一定値フィールドを、新たに受信されたフルヘッダパケットｇの内容に基づいて復元するようにしてもよい。図５は、本変形例におけるパケット復元のための動作を表すフローチャートである。なお、同図に示すフローチャートは、復元対象となるパケット内の一定値フィールドを、これらの各パケットの受信後に受信されたフルヘッダパケットｇの内容に基づいて復元する点を除いて前掲図４に示したものと同様であるため、以下では、図４と比較して異なる点についてのみ説明する。
【００５７】
まず、上記第１実施形態においては、ステップＳ４において、パケットの喪失後に受信されたヘッダ圧縮パケット内の一定値フィールドの情報を、既に受信され記憶部３４ｂに保持されているIPパケットｂのRTP/UDP/IPヘッダの一定値フィールドを用いて復元するようにしたが、本変形例においては、ステップＳ４’においては一定値フィールドの復元は行わず、length値、UDPチェックサムおよびマーカビットＭのみを復元するようになっている。従って、続くステップＳ５において、IP（Ｎ）として記憶部３４ｂに記憶されるのは、一定値フィールドおよび差分一定フィールドを含まないRTP/UDP/IPヘッダと、今回受信したヘッダ圧縮パケット内のRTPペイロードとを有するパケットである。
【００５８】
一方、復元対象となるパケットの一定値フィールドは、ステップＳ８’において、当該パケットの次のフルヘッダパケットｇの内容に基づいて復元される。すなわち、図５のステップＳ８’に下線を付して示すように、復元対象となるパケットの一定値フィールドを、当該パケットの直後に受信されたフルヘッダパケットに含まれる一定値フィールドの内容と同様の内容とみなすのである。例えば、図３に示した状況を例にとると、パケットｆの一定値フィールドの内容を、当該パケットｆの直後に受信されたフルヘッダパケットｇの一定値フィールドと同一とみなすことにより、パケットｆの一定値フィールドの内容を復元する。また、パケットｅの一定値フィールドの内容を、こうして復元されたパケットｆの一定値フィールドの内容と同一であるとみなすことにより、パケットｅの一定値フィールドの内容を復元するようになっている。
【００５９】
本変形例にあっても、最終的にはUDPチェックサムにより正確に復元されたか否かが判定され、正確に復元されたパケットのみが受信側データ端末に送信されることとなる。本変形例によっても上記第２実施形態と同様の効果を得ることができる。
【００６０】
Ｂ：第２実施形態
Ｂ−１：第２実施形態の構成
上記各実施形態においては、ネットワーク３内の受信側ノード３ｂにおいて、パケットの喪失が発生した後に受信したヘッダ圧縮パケットを保持するとともに、当該パケット喪失後に受信したフルヘッダパケットの内容に基づいて、保持したヘッダ圧縮パケットの内容を復元するようにした。しかしながら、上記各実施形態においては、パケットの喪失後に受信したフルヘッダパケットの差分一定フィールドと、当該フルヘッダパケットの直前に受信したヘッダ圧縮パケットの差分一定フィールドとの差分値に変更がないものと仮定して上記復元を行うようにしたため（図４中のステップＳ７）、この差分値に変更があった場合には、保持されたヘッダ圧縮パケットの内容を正しく復元できないという問題が発生し得る。本実施形態は、このような問題を解決可能なパケット中継方法に係るものである。
【００６１】
本実施形態に係る通信システムの構成、ならびに送信側ノード３ａおよび受信側ノード３ｂの構成は、前掲図１および図２に示したものと同様となる。ただし、上記実施形態における送信側ノード３ａから受信側ノード３ｂへの送信対象がフルヘッダパケットまたはヘッダ圧縮パケットであったのに対し、本実施形態における送信側ノード３ａは、これらのパケットに加え、所定の場合には差分値を含むフルヘッダパケットを送信対象とする点で異なっている。具体的には、本実施形態における送信側ノード３ａは、送信側データ端末１から受信したIPパケットをフルヘッダパケットとして送信すべき場合であって、かつ、当該IPパケットの差分一定フィールドと、その直前に受信したIPパケットの差分一定フィールドとの差分値が、記憶部３４ａに記憶された差分値と異なっている場合（すなわち、差分値に変更があった場合）には、当該新たな差分値を含むフルヘッダパケットを受信側ノード３ｂに対して送信するようになっている。
【００６２】
ここで、図６（ａ）は、差分値が付加されたフルヘッダパケットの内容を模式的に表す図である。同図に破線で示すように、このフルヘッダパケットには、RTP/UDP/IPヘッダ内の差分一定フィールド（すなわち、IPヘッダ内のID、ならびにRTPヘッダ内のシーケンス番号およびタイムスタンプ）のうちの差分値に変更があったものについて、当該変更後の差分値が含まれることとなる。また、上記各実施形態と同様に、フルヘッダパケット内のフルヘッダは、IPヘッダおよびUDPヘッダ内のlength（図６（ａ）において斜線を付した部分）をCONTEXT_IDおよびlink_seqに置き換えたものであるが、差分値を付加した場合のフルヘッダパケットにおいては、図６（ｂ）および（ｃ）に示すように、CONTEXT_IDおよびlink_seqに加え、フラグＳ、ＴおよびＩが含まれることとなる。これらの各フラグは、差分値に変更があった差分一定フィールドを示す情報である。例えば、RTPヘッダ内のシーケンス番号の差分値に変更があった場合、図６（ａ）に破線で示すように当該変更後の差分値ΔRTP_SNがヘッダに付加されるとともに、フラグＳに「１」がセットされるのである。また、ＩＰヘッダ内のＩＤの差分値に変更があった場合、当該変更後の差分値ΔIP_IDがヘッダに付加されるとともに、フラグＩに「１」がセットされる。同様に、ＲＴＰヘッダ内のタイムスタンプの差分値に変更があった場合には、変更後の差分値ΔRTP_TSがヘッダに付加されるとともに、フラグＴに「１」がセットされる。受信側ノード３ｂは、差分値が付加されたフルヘッダパケットを受信すると、上記フラグを参照することにより変更があった差分一定フィールド（ID、シーケンス番号、タイムスタンプのいずれであるか）を検知するとともに、当該差分一定フィールドの変更後の差分値を取得することができるのである。
【００６３】
Ｂ−２：第２実施形態の動作
次に、図７を参照して、本実施形態の動作を説明する。なお、以下では、上記第１実施形態と同様に、送信側ノード３ａが、受信側ノード３ｂからCONTEXT_STATEを受信することを契機として、IPパケットをフルヘッダパケットとして受信側ノード３ｂに送信する場合を例示する。
【００６４】
まず、送信側データ端末１からIPパケットａ乃至ｆを順次受信すると、送信側ノード３ａ内の制御部３３ａは、最初のIPパケットａについてはフルヘッダパケットとして受信側ノード３ｂに送信する一方、IPパケットｂ乃至ｃについてはヘッダ圧縮パケットとして受信側ノード３ｂに送信する。なお、この動作は、上記第１実施形態で示したものと同様であるため、その詳細な説明を省略する。
【００６５】
ここで、図７においては、送信側ノード３ａ内の制御部３３ａが、送信側データ端末１からIPパケットｇを受信する直前に、受信側ノード３ｂからCONTEXT_STATEを受信した場合を想定している。この場合、制御部３３ａは、当該CONTEXT_STATEの受信直後に送信側データ端末１から受信したIPパケットｇを、差分値を含まないフルヘッダパケットまたは差分値が付加されたフルヘッダパケットとして受信側ノード３ｂに送信する。具体的には、以下の通りである。
【００６６】
まず、制御部３３ａは、今回受信したIPパケットｇに含まれるRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダの差分一定フィールドの値と、記憶部３４ａに記憶されているRTP/UDP/IPヘッダ（IPパケットｆに含まれていたもの）の差分一定フィールドの値との差分値を求める。続いて、制御部３３ａは、得られた差分値が、記憶部３４ａに記憶された差分値と同一であるか否かを判定する。この結果、記憶部３４ａに記憶された差分値と同一であると判定した場合には、当該差分値は既に受信側ノード３ｂに通知されているから、今回得られた差分値を受信側ノード３ｂに改めて通知する必要はない。従って、制御部３３ａは、IPパケットｇのRTP/UDP/IPヘッダ内のlengthをCONTEXT_ID（上記フルヘッダパケットａに含ませたCONTEXT_IDとは異なるもの）およびlink_seqを含む情報に置き換えたフルヘッダを生成し、当該フルヘッダとIPパケットｇ内のRTPペイロードとを含むフルヘッダパケットｇを受信側ノード３ａに対して送信する。
【００６７】
これに対し、上記判定において記憶部３４ａに記憶された差分値と同一でないと判定した場合、制御部３３ａは、今回得られた差分値を受信側ノード３ｂに対して通知すべく、当該差分値を含むフルヘッダパケットを受信側ノード３ｂに対して送信する。詳述すると、制御部３３ａは、まず、IPパケットｇのRTP/UDP/IPヘッダ内のlengthを、CONTEXT_IDおよびlink_seq、ならびに変更があった差分一定フィールドに対応して「１」がセットされたフラグ（図６（ｃ）参照）を含むデータに置き換えるとともに、上記変更後の新たな差分値（図６（ａ）に破線で示す部分）を含むフルヘッダを生成する。そして、制御部３３ａは、このフルヘッダと、IPパケットｇ内のRTPペイロードとを含むフルヘッダパケットｇを、受信側ノード３ｂに対して送信するのである。なお、図７においては、IPパケットｆとIPパケットｇとの間の差分一定フィールドの差分値に変更があり、当該IPパケットｇが差分値を含むフルヘッダパケットｇとして送信された場合を例示している。
【００６８】
送信側データ端末１から以後のIPパケットｈ乃至ｎを受信した場合にも上記と同様の処理がなされ、差分値を含まないヘッダ圧縮パケットまたはフルヘッダパケット、もしくは差分値を含むヘッダ圧縮パケットまたはフルヘッダパケットのいずれかが、適宜送信側ノード３ａから受信側ノード３ｂに対して送信される。
【００６９】
次に、受信側ノード３ｂの制御部３３ｂが、上記のようにして送信側ノード３ａから送信されたパケットを受信した場合の動作を説明する。
まず、送信側ノードから送信されたフルヘッダパケットａを受信すると、受信側ノード３ｂ内の制御部は、当該フルヘッダパケットａ内のフルヘッダに含まれるCONTEXT_IDおよびlink_seq等を抽出して記憶部３４ｂに書き込むとともに、フルヘッダ中のこれらの情報を、下位レイヤの内容に基づいて得られるlengthに置き換えて、RTP/UDP/IPヘッダを復元する。そして、このRTP/UDP/IPヘッダを、先に書込んだCONTEXT_IDおよびlink_seqに対応付けて記憶部３４ｂに書き込むとともに、当該RTP/UDP/IPヘッダを含むIPパケットａを受信側データ端末２に対して送信する。
【００７０】
次に、送信側ノード３ａから送信されたヘッダ圧縮パケットｂを受信すると、受信側ノード３ｂ内の制御部３３ｂは、当該ヘッダ圧縮パケットｂに含まれる差分値を記憶部３４ｂに書き込む。さらに、制御部３３ｂは、当該圧縮ヘッダに含まれるCONTEXT_IDと同一のCONTEXT_IDを記憶部３４ｂから検索し、検索されたCONTEXT_IDに対応付けられたRTP/UDP/IPヘッダ（この場合にはIPパケットａのRTP/UDP/IPヘッダ）を読み出す。そして、読み出したRTP/UDP/IPヘッダの差分一定フィールドに、今回取得した差分値を加算して得られる差分一定フィールドと、IPパケットａのRTP/UDP/IPヘッダ内の一定値フィールドとを含むRTP/UDP/IPヘッダを生成する。さらに、制御部３３ｂは、記憶部３４ｂに既に記憶されているIPパケットａのRTP/UDP/IPヘッダを、今回新たに得られたRTP/UDP/IPヘッダに更新するとともに、当該RTP/UDP/IPヘッダを含むIPパケットｂを、受信側データ端末２に対して送信する。
【００７１】
ここで、図７においては、送信側ノード３ａから送信されたヘッダ圧縮パケットｃが何らかの理由により喪失された場合を例示している。この場合、受信側ノード３ｂの制御部３３ｂは、ヘッダ圧縮パケットｄ内のlink_seqがパケットｂ内のlink_seqから連続していないことによってヘッダ圧縮パケットｃが喪失されたことを検知する。以下、図８に示すフローチャートを参照して、かかるパケットの喪失が検知された場合に制御部３３ｂによって実行される動作について説明する。
【００７２】
まず、受信側ノード３ｂ内の制御部３３ｂは、レジスタｎに「０」をセットするとともに（ステップＳ２１）、直前に受信したパケット（すなわち、喪失されたパケットの次のパケット）がヘッダ圧縮パケットであるか否かを判定する（ステップＳ２２）。図７に示す例では、パケット喪失直後に受信したのはヘッダ圧縮パケットｄであるから、この判定の結果は「Ｙｅｓ」となる。次に、制御部３３ｂは、このヘッダ圧縮パケットについて、一定値フィールド、length値、UDPチェックサムおよびマーカビット（Ｍbit）を復元し、復元された情報と今回受信したヘッダ圧縮パケット内のRTPペイロードとをIP(n)として記憶部３４ｂに記憶する（ステップＳ２３）。すなわち、ヘッダ圧縮パケットｄから復元されるべきIPパケットｄ内の差分一定フィールド以外のフィールドが復元され、IP(0)として記憶部３４ｂに記憶されることとなる。なお、この復元動作は、上記第１実施形態に示したものと同様にして行うことができる。
【００７３】
続いて、制御部３３ｂは、当該時点における差分一定フィールドの差分値、すなわち、IPヘッダのIDの差分値、RTPヘッダのシーケンス番号の差分値、およびRTPヘッダのタイムスタンプの差分値を、それぞれΔIP_ID(n)、ΔRTP_SN(n)、およびΔRTP_TS(n)として（以下、これらをまとめて「Δ(n)」と表記する）、記憶部３４ｂに記憶する（ステップＳ２４）。なお、当該時点における差分値とは、今回受信したヘッダ圧縮パケットに新たな差分値が付加されている場合には当該差分値であり、含まれていない場合には当該時点において記憶部３４ｂに記憶されている差分値である。
【００７４】
続いて、制御部３３ｂは、次のパケットを受信するまで待機し、当該次のパケットを受信すると（ステップＳ２５）、レジスタｎの値を「１」だけインクリメントする（ステップＳ２６）。以後、上記のステップＳ２２〜Ｓ２６に示した動作がヘッダ圧縮パケットｅおよびｆについても実行され、この結果、ヘッダ圧縮パケットｄ〜ｆについては、図９に例示する各情報（すなわち、IP(n)およびΔ(n)）が記憶部３４ｂに記憶される。
【００７５】
一方、ステップＳ２５においてフルヘッダパケットを受信すると、続くステップＳ２２における判定結果が「Ｎｏ」となってステップＳ２７に進む。すなわち、制御部３３ｂは、受信したフルヘッダパケットｇ内のフルヘッダに含まれるCONTEXT_IDおよびlink_seq等をlengthに置き換えたRTP/UDP/IPヘッダを生成し、当該RTP/UDP/IPヘッダと今回受け取ったフルヘッダパケットのRTPペイロードとからなるIPパケットを生成する。そして、得られたIPパケットを、IP(3)として記憶部３４ｂに記憶する（ステップＳ２７）。ここで、図９に示すように、すなわちフルヘッダパケットから得られたIPパケット（IP(3)）のRTP/UDP/IPヘッダには、差分一定フィールド（すなわち、ID、シーケンス番号およびタイムスタンプ）の値も含まれる。
【００７６】
続いて制御部３３ｂは、当該フルヘッダパケットとその前に受信されたヘッダ圧縮パケットとの間の各差分一定フィールドの差分値をΔ(n)として記憶部３４ｂに記憶する。図７の場合を例にとれば、以下の通りである。まず、制御部３３ｂは、今回受信したフルヘッダパケットｇに新たな差分値（図６（ａ）において破線で示された部分）が付加されているか否かを判定する（ステップＳ２８）。この結果、差分一定フィールドのいずれかについての差分値が付加されていると判定すると、当該差分一定フィールドについては新たな差分値を、他の差分一定フィールドについては、当該時点において記憶部３４ｂに記憶された差分値を、それぞれΔ(3)として記憶部３４ｂに記憶する（ステップＳ２９）。これに対し、今回受信したフルヘッダパケットｇに新たな差分値が付加されていない場合には、当該時点において記憶部３４ｂに記憶されている差分値を、Δ(3)として記憶部３４ｂに記憶する（ステップＳ３０）。
【００７７】
以上示した動作の結果、パケットｄ乃至ｇについて、図９に示す情報が記憶部３４ｂに記憶されることとなる。なお、この時点において、IP(3)として記憶されたIPパケットｇには差分一定フィールドの値も含まれているものの、パケットｄ乃至ｆの差分一定フィールドはIP(0)〜IP(2)には含まれていない。従って、以後、これらのパケットｄ乃至ｆ（すなわち、ヘッダ圧縮パケットとして受信されたパケット）のRTP/UDP/IPヘッダに含ませるべき差分一定フィールドの値を復元するための動作が実行される。
【００７８】
まず、制御部３３ｂは、レジスタｎの値を「１」だけデクリメントするとともに（ステップＳ３２）、フルヘッダパケットから復元されたRTP/UDP/IPヘッダ中の差分一定フィールドの値から、上記のようにして得られた差分値を減算することにより、当該フルヘッダパケットの直前に受信したヘッダ圧縮パケットの差分一定フィールドを復元する（ステップＳ３３）。図７に例示した場合にあっては、フルヘッダパケットｇの内容に基づいて記憶されたIP(3)に含まれる差分一定フィールドの各値から、Δ(3)として記憶された各差分一定フィールドの差分値を減算することにより、ヘッダ圧縮パケットｆの差分一定フィールドを復元する。具体的には、IP(3)に含まれるIDの値をIP(3).IP_ID、IP(3)に含まれるシーケンス番号の値をIP(3).RTP_SN、IP(3)に含まれるタイムスタンプの値をIP(3).RTP_TSとすると、ヘッダ圧縮パケットｆの差分一定フィールドIP(2).IP_ID、IP(2).RTP_SN、IP(2).RTP_TSの値は、
IP(2).IP_ID＝IP(3).IP_ID−ΔIP_ID(3)
IP(2).RTP_SN＝IP(3).RTP_SN−ΔRTP_SN(3)
IP(2).RTP_TS＝IP(3).RTP_TS−ΔRTP_TS(3)
なる演算によって得られる（図９参照）。
【００７９】
こうして差分一定フィールドの値を復元すると、制御部３３ｂは、当該差分一定フィールドと、IP(2)として記憶部３４ｂに記憶されている差分一定フィールド以外の部分とを合わせてIPパケットｆを生成する。この後、制御部３４ｂは、当該IPパケットｆに含まれるUDPチェックサムを用い、正しく復元されたか否かを判定する（ステップＳ３４）。この結果、正しく復元されていると判定した場合、制御部３３ｂは、当該IPパケットｆを記憶部３４ｂに記憶する（ステップＳ３５）。以後、制御部３３ｂは、他のヘッダ圧縮パケットｅおよびｄの差分一定フィールドを復元するための動作、すなわち、上述したステップＳ３２〜Ｓ３５に示したのと同様の動作を繰り返す。
【００８０】
ここで、ステップＳ３１において、レジスタｎの値が「０」となった場合には、保持されたすべてのヘッダ圧縮パケットの復元が終了したことを意味しているから、それまでに記憶部３４ｂに記憶されたIPパケット（フルヘッダパケットから得られたIPパケットも含む）を、RTPヘッダ中のシーケンス番号の順番に、受信側データ端末２に対して順次送信する（ステップＳ３７）。
【００８１】
一方、ステップＳ３４において、正しく復元できていないと判定される場合には、それよりも前に受信されたヘッダ圧縮パケットについても正しく復元することはできないから、復元が失敗したパケットを破棄するとともに（ステップＳ３６）、それ以前に復元が完了しているIPパケットを受信側データ端末２に対して送信する（ステップＳ３７）。
以上が本実施形態の動作である。
【００８２】
このように、本実施形態によれば、差分値の変更があった場合には、ヘッダ圧縮パケットのみならずフルヘッダパケットについても当該差分値を付加して送信するようになっている。従って、フルヘッダパケットとして送信すべきIPパケットとその直前のIPパケットとの間で差分値に変更があった場合であっても、受信側ノード３ｂにおいては正確にヘッダ圧縮パケットの内容を復元することができる。
【００８３】
Ｃ：第３実施形態
上記各実施形態においては、パケットの喪失直後に受信したフルヘッダパケット内の差分一定フィールドの値から、パケット喪失後に保持したヘッダ圧縮パケットに関する差分値を順次減算することによって、保持したヘッダ圧縮パケットをIPパケットに復元するようにした。しかしながら、パケット喪失後に受信したフルヘッダパケットに基づいて、保持したヘッダ圧縮パケットを復元するための方法は、これに限られるものではない。以下に示す本実施形態は、かかる方法の一例に関するものである。なお、以下では、本実施形態のうち、上記各実施形態と異なる部分についてのみ説明する。
【００８４】
上記各実施形態における送信側ノード３ａは、IPパケット中の差分一定フィールドの差分値に変更があった場合、ヘッダ圧縮パケットの圧縮ヘッダ中に当該変更後の差分値を含ませるようにした。これに対し、本実施形態においては、この差分値に代えて、各差分一定フィールドの値を表すビット列のうちの下位の数ビット（以下、「下位ビット列LSB」という）を、ヘッダ圧縮パケット中の圧縮ヘッダに含ませるようになっている。
【００８５】
すなわち、送信側ノード３ａは、送信側データ端末１からヘッダ圧縮パケットとして送信すべきIPパケットを受信すると、当該IPパケット内の差分一定フィールドの値と、記憶部３４ａに記憶されているIPパケット（その直前に受信したIPパケット）内の各差分一定フィールドの値との差分値を求め、記憶部に記憶されている差分値と比較する。この結果、いずれかの差分一定フィールドの差分値に変更があったと判定すると、送信側ノード３ａ内の制御部３３ａは、今回受信したIPパケット中の変更があった差分一定フィールドを表すビット列から下位ビット列LSBを抽出する。そして、この下位ビット列LSBと、変更があった差分一定フィールドに応じて「１」がセットされたフラグ（図１１（ｂ）におけるフラグＳ、ＴおよびＩに相当する）とを含む圧縮ヘッダを生成し、この圧縮ヘッダを含むヘッダ圧縮パケットを受信側ノード３ｂに対して送信するのである。一方、上記差分値の比較の結果、双方の差分値が同一である場合には、今回受信したIPパケットを圧縮したヘッダ圧縮パケット中には、下位ビット列LSBは含ませない。
【００８６】
ところで、上記下位ビット列LSBを、差分一定フィールドを表すビット列のうちの下位何ビットに設定するかは、送信対象となるデータや、差分一定フィールド（ID、シーケンス番号およびタイムスタンプ）ごとの性質等に応じて適宜選定される。例えば、差分一定フィールドを表すビット列のうち、変更が生じないと予想される上位数ビットを除いたビット列を、下位ビット列LSBとすることが考えられる。
【００８７】
次に、図１０を参照して、本実施形態の動作を説明する。なお、実際には、上記第１実施形態等にも示したように、差分一定フィールドにはIPヘッダ中のIDや、RTPヘッダ中のシーケンス番号およびタイムスタンプ等が含まれるが、以下では、簡単のため、これらを総称して単に「差分一定フィールド」と呼ぶこととする。
【００８８】
まず、送信側ノード３ａは、送信側データ端末１から最初に受信したIPパケットａをフルヘッダパケットとして、以後受信したIPパケットｂ乃至ｆをヘッダ圧縮パケットとして受信側ノード３ｂに送信する。さらに、図１０においては、IPパケットｇを受信する直前に、受信側ノード３ｂからCONTEXT_STATEを受信した場合を想定しているので、送信側ノード３ａは、IPパケットｇについてはフルヘッダパケットとして受信側ノード３ｂに送信する。ここで、上述したように、ヘッダ圧縮パケット中の圧縮ヘッダには、差分一定フィールドの差分値に変更があったものについてのみ下位ビット列LSBが含まれることとなる。図１０においては、ヘッダ圧縮パケットｂ、ｄおよびｆには下位ビット列LSBb、LSBdおよびLSBfがそれぞれ含まれる一方、ヘッダ圧縮パケットｅには下位ビット列LSBが含まれない場合を想定している。
【００８９】
一方、受信側ノード３ｂ内の制御部３３ｂは、送信側ノード３ａから最初に受信したフルヘッダパケットａからIPパケットａを復元して記憶部３４ｂに格納するとともに、このIPパケットａを受信側データ端末２に送信する。続いて制御部３３ｂは、次に受信したヘッダ圧縮パケットｂを、IPパケットａを用いて復元する。具体的には、図１０に示すように、記憶部３４ｂに格納されたIPパケットａのうちの差分一定フィールドを読み出し、この差分一定フィールドを表すビット列のうちの下位ビット列LSBaを、ヘッダ圧縮パケットｂに含まれる下位ビット列LSBbに置換することによってヘッダ圧縮パケットｂの差分一定フィールドを復元する（図１０中の▲１▼）。そして、制御部３３ｂは、この差分一定フィールドを含むIPパケットｂを生成して記憶部３４ｂに格納するとともに、このIPパケットｂを受信側データ端末２に送信するのである。
【００９０】
ここで、図１０においては、送信側ノード３ａから送信されたヘッダ圧縮パケットｃが、受信側ノード３ｂによって受信される前に、何らかの原因によって喪失された場合を想定している。受信側ノード３ｂ内の制御部３３ｂは、ヘッダ圧縮パケットｂの次にヘッダ圧縮パケットｄを受信したことによってヘッダ圧縮パケットｃが喪失されたことを検知すると、送信側ノード３ａに対してCONTEXT_STATEを送信する。
【００９１】
さらに、制御部３３ｂは、パケットｃの喪失後、次にフルヘッダパケットｇを受信するまでに受信したヘッダ圧縮パケットｄ乃至ｆを記憶部３４ｂに順次格納する。具体的には、下位ビット列LSBを含むヘッダ圧縮パケットを受信した場合には、当該ヘッダ圧縮パケットをそのまま記憶部３４ｂに格納する。一方、下位ビット列LSBを含まないヘッダ圧縮パケットを受信した場合には、当該ヘッダ圧縮パケットに対して、その直前に受信した、下位ビット列LSBを含むヘッダ圧縮パケットのLSBを付加して記憶部３４ｂに格納する。例えば、図１０に示す例においては、ヘッダ圧縮パケットｅは下位ビット列LSBを含まないので、その直前に受信した下位ビット列を含むヘッダ圧縮パケットｄの当該下位ビット列LSBdが、下位ビット列LSBeとして、ヘッダ圧縮パケットｅとともに記憶部３４ｂに格納されることとなる。
【００９２】
次に、先に送信したCONTEXT_STATEに応じて送信側ノード３ａから送信されたフルヘッダパケットｇを受信すると、制御部３３ｂは、このフルヘッダパケットｇの内容に基づいて、記憶部３４ｂに保持されたヘッダ圧縮パケットｄ乃至ｆをIPパケットに復元するための処理を実行する。以下、この復元処理について詳述する。
【００９３】
まず、制御部３３ｂは、フルヘッダパケットｇをIPパケットｇに復元して記憶部３４ｂに格納するとともに、当該IPパケットｇを受信側データ端末２に送信する。なお、図１０においては、当該IPパケットｇ中の差分一定フィールドを表すビット列のうち、下位ビット列を「LSBg」、それ以外のビットを「Ｇ」によってそれぞれ表記している。
【００９４】
次に、制御部３３ｂは、記憶部３４ｂに格納されたIPパケットｇ内の差分一定フィールドを読み出し、当該差分一定フィールドを表すビット列のうちの下位ビット列LSBgを、記憶部３４ｂに格納されたヘッダ圧縮パケットｆの下位ビット列LSBfに置き換え、ヘッダ圧縮パケットｆの差分一定フィールドを復元する（図１０中の▲２▼）。そして、制御部３３ｂは、この差分一定フィールドと、IPパケットｇの一定値フィールドとを含むIPパケットｆを生成するとともに、ヘッダ圧縮パケットｆ中に含まれていたチェックサムを用いて正しく復元できたか否かを判定する。
【００９５】
IPパケットｆが正しく復元できた場合には、このIPパケットｆを用いてヘッダ圧縮パケットeが復元される。すなわち、制御部３３ｂは、IPパケットｆの差分一定フィールドのうちの下位ビット列LSBfを、記憶部３４ｂに格納されたヘッダ圧縮パケットｅの下位ビット列LSBe（LSBdと同一の内容である）に置き換えて、ヘッダ圧縮パケットｅの差分一定フィールドを復元する（図１０中の▲３▼）。一方、IPパケットｆが正しく復元できなかった場合には、フルヘッダパケットとして受信・復元されたIPパケットｇを用いてヘッダ圧縮パケットｅが復元される。すなわち、制御部３３ｂは、IPパケットｇの差分一定フィールドのうちの下位ビット列LSBgを、記憶部３４ｂに格納されたヘッダ圧縮パケットｅに対応する下位ビット列LSBeに置き換えて、ヘッダ圧縮パケットｅの差分一定フィールドを復元する。
【００９６】
こうして、IPパケットｆまたはｇのいずれかの内容に基づいて、ヘッダ圧縮パケットｅについての差分一定フィールドを復元すると、制御部３３ｂは、この差分一定フィールドと、IPパケットｆまたはｇ内の一定値フィールドとを含むIPパケットｅを生成するとともに、ヘッダ圧縮パケットｅに含まれていたチェックサムを用いて正しく復元できたか否かを判定する。
【００９７】
以後、制御部３３ｂは、パケットｃの喪失後、フルヘッダパケットｇの受信までの間に受信したすべてのヘッダ圧縮パケットについて同様の処理を行う。そして、すべてのヘッダ圧縮パケットについて処理を終了すると、正しく復元できたIPパケットのみを、各々のRTPヘッダ中に含まれるシーケンス番号の順に、順次受信側データ端末２に送信する。一方、正しく復元できなかったパケットは破棄する。
【００９８】
このように、本実施形態においても、上記各実施形態と同様に、パケット喪失後に受信されたヘッダ圧縮パケットが、当該パケット喪失直後に受信されたフルヘッダパケットに基づいて順次復元されるようになっているため、上記各実施形態と同様の効果を得ることができる。さらに、本実施形態においては、あるヘッダ圧縮パケットの復元に際し、パケット喪失直後に受信したフルヘッダパケット、または当該ヘッダ圧縮パケットの直前に復元されたIPパケットのうちのいずれかを用いることができる。例えば、図１０においては、ヘッダ圧縮パケットｄの復元に際してフルヘッダパケットｇを復元したIPパケットｇ、またはヘッダ圧縮パケットeを復元したIPパケットeのうちのいずれかを用いることができる。従って、復元対象となるヘッダ圧縮パケットｄの直前の復元対象であるヘッダ圧縮パケットｅが正しく復元されなかった場合であっても、IPパケットｇの内容に基づいてヘッダ圧縮パケットｄを復元することができるのである。従って、本実施形態によれば、上記各実施形態と比較して復元の効率を向上させることができるという利点がある。
【００９９】
上記各実施形態に示したように、本発明においては、パケット喪失後に受信・保持したヘッダ圧縮パケットの内容を、当該パケット喪失直後に受信したフルヘッダパケットの内容に基づいて復元するものであればよい。すなわち、パケット喪失直後に受信したフルヘッダパケットを用いて、それ以前のヘッダ圧縮パケットを復元する方法は、上記各実施形態に示した方法に限られるものではなく、他の種々の方法をも用いることができるのである。
【０１００】
Ｄ：第４実施形態
上記各実施形態においては、送信側ノード３ａがIPパケットをヘッダ圧縮パケットまたはフルヘッダパケットに変換する機能（以下、「圧縮機能」という）を有する一方、受信側ノード３ｂがヘッダ圧縮パケットまたはフルヘッダパケットをIPパケットに変換する機能（以下、「復元機能」という）を有するようにした。これに対し、本実施形態においては、図１に示す送信側データ端末および受信側ノード３ｂが圧縮機能を有し、送信側ノード３ａおよび受信側データ端末２が復元機能を有するようになっている。
【０１０１】
具体的には、送信側データ端末１は、送信対象となるIPパケットを順次生成し、最初のIPパケットおよび送信側ノード３ａからCONTEXT_STATEを受信した直後に送信すべきIPパケットについては、フルヘッダパケットとして送信側ノード３ａに送信する一方、その他のIPパケットについては、ヘッダ圧縮パケットとして送信側ノード３ａに送信する。
【０１０２】
一方、送信側ノード３ａは、上記第１実施形態における受信側ノード３ｂと同様の動作を行うことにより、送信側データ端末１から送信されたフルヘッダパケットまたはヘッダ圧縮パケットをIPパケットに復元し、受信側ノード３ｂに送信する。受信側ノード３ｂは、これらのIPパケットを受信し、フルヘッダパケットまたはヘッダ圧縮パケットに変換して受信側データ端末に送信する。
【０１０３】
一方、受信側データ端末２は、受信側ノード３ｂから受信したフルヘッダパケットまたはヘッダ圧縮パケットをIPヘッダに変換する。ここで、受信側ノード３ｂと受信側データ端末２との間で生じたパケットの喪失を検知すると、受信側データ端末２は、当該パケットの喪失後、次にフルヘッダパケットが受信されるまでの間に受信されたヘッダ圧縮パケットを内部の記憶装置に記憶する。そして、当該パケットの喪失後にフルヘッダパケットを受信すると、当該フルヘッダパケット内のフルヘッダの内容に基づいて、上記記憶装置に記憶されたヘッダ圧縮パケット内の圧縮ヘッダを復元してIPパケットを生成するのである。この後、受信側データ端末２は、受信した各パケットに含まれるデータに従って画像の表示や音声の出力等の処理を行う。こうした場合にも、上記各実施形態と同様の効果が得られる。
【０１０４】
以上説明したように、パケットの喪失後、次にフルヘッダパケットを受信するまでに受信されたヘッダ圧縮パケットの圧縮ヘッダの内容を、当該フルヘッダパケット内のフルヘッダの内容に基づいて復元する機能を、受信側データ端末に持たせるようにしてもよいのである。すなわち、本発明にかかるパケット伝送方法は、ネットワーク内でパケットの送受信を行う任意の装置に対して適用可能である。つまり、特許請求の範囲における「送信側」および「受信側」は、データ端末間のパケットの交換を中継するパケット中継装置のみならず、パケットの送信元であるデータ端末およびパケットの送信先であるデータ端末をも含む概念である。
【０１０５】
Ｅ：変形例
＜変形例１＞
上記各実施形態においては、送信側ノード３ａは、受信側ノード３ｂからのCONTEXT_STATEを受信した直後に送信すべきIPパケットを、フルヘッダパケットとして受信側ノード３ｂに対して送信するようにした。しかしながら、送信側ノード３ａがフルヘッダパケットとして送信するIPパケットの条件は、これに限られるものではない。送信側ノード３ａからフルヘッダパケットとして送信されるIPパケットとしては、例えば以下のようなものが考えられる。
【０１０６】
ａ．第１の態様
送信対象となるIPパケット内のRTP/UDP/IPヘッダ内の一定値フィールドの値に変更が生じない場合、送信側ノード３ａは、上記実施形態に示したように、最初に送信すべきIPパケット、および受信側ノードからCONTEXT_STATEを受信した直後に送信すべきIPパケットについてのみフルヘッダパケットとして送信することも可能である。しかしながら、一定値フィールドの値に変更が生じ得る場合には、かかるパケットに加え、上記従来技術Ａにも示したように、一定値フィールドの内容に変更があったパケットもフルヘッダパケットとして送信される必要がある。すなわち、送信側ノード３ａ内の制御部３３ａは、RTP/UDP/IPヘッダ内の一定値フィールドに変更があったパケットについても、フルヘッダパケットとして送信するようにしてもよい。なお、CONTEXT_STATEを受信した直後に送信すべきIPパケットに代えて、一定値フィールドに変更があったIPパケットについてのみフルヘッダパケットとして送信するようにしてもよいことは言うまでもない。
【０１０７】
ｂ．第２の態様
送信側ノード３ａにおいては、上記従来の技術において方法１として示したように、送信側データ端末１から順次送信されるパケットのうちの１のパケットを一定個数間隔毎に選択し、選択したパケットをフルヘッダパケットとして受信側ノード３ｂに送信するようにしてもよい。
【０１０８】
なお、上記第１および第２の態様においても、受信側ノード３ｂは、パケットの喪失が発生してから、送信側ノード３ａからのフルヘッダパケットが受信されるまでに受信されたパケットを保持しておき、当該フルヘッダパケットの内容に基づいてこれらの保持したパケットを復元する点は上記各実施形態と同様である。
【０１０９】
＜変形例２＞
フルヘッダパケットおよびヘッダ圧縮パケットは、上記各実施形態に示したものに限られない。すなわち、本発明における「フルヘッダパケット」とは、送信側ノードにおける圧縮動作の内容と、受信側ノードにおける復元動作の内容とを一致させるための機能を有するパケットであればいかなる構成であってもよい。例えば、フルヘッダパケットは、上記機能を有していれば、必ずしもそれ自身の内容に基づいて非圧縮パケットを復元可能なパケットである必要はないし、また、必ずしもIPヘッダに基づいて生成されるパケットである必要はない。一方、圧縮ヘッダは、他のパケット（フルヘッダパケットや、ヘッダ圧縮パケットを復元したIPパケット）の内容に基づいて復元可能なパケットであれば、いかなる構成としてもよい。
【０１１０】
【発明の効果】
本発明においては、パケットの喪失時から次にフルヘッダが受信されるまでに受信されたヘッダ圧縮パケットを保持しておき、当該パケットの喪失後に受信したフルヘッダパケットの内容に基づいて、当該保持されたヘッダ圧縮パケット内の圧縮ヘッダを復元するようになっている。この結果、上記従来の技術と比較して、他のパケットの喪失に伴って破棄されるパケットを減らすことができるという利点がある。
【図面の簡単な説明】
【図１】 本発明の第１実施形態に係る通信システムの構成を例示するブロック図である。
【図２】 同通信システムにおける受信側ノードの構成を例示するブロック図である。
【図３】 同通信システムにおける動作を示すタイミングチャートである。
【図４】 同通信システムにおける受信側ノードの、パケット喪失時の動作を示すフローチャートである。
【図５】 第１実施形態の変形例におけるパケット喪失時の動作を示すフローチャートである。
【図６】 本発明の第２実施形態に係る通信システムにおける差分値付きフルヘッダパケットの構成を表す図である。
【図７】 同通信システムにおける動作を示すタイミングチャートである。
【図８】 同通信システムにおける受信側ノードの、パケット喪失時の動作を示すフローチャートである。
【図９】 同通信システムにおけるパケット喪失時の、受信側ノード内の記憶部の記憶内容を例示する図である。
【図１０】 本発明の第３実施形態に係る通信システムにおける動作を示すタイミングチャートである。
【図１１】 （ａ）はRTP/UDP/IPヘッダの内容を示す図であり、（ｂ）は圧縮ヘッダの内容を示す図である。
【図１２】 従来のパケット伝送方法（従来方法Ａ）の手順を示すタイミングチャートである。
【図１３】 同パケット伝送方法の問題点を説明するためのタイミングチャートである。
【図１４】 従来のパケット伝送方法（方法１）の手順を示すタイミングチャートである。
【図１５】 従来のパケット伝送方法（方法２）の手順を示すタイミングチャートである。
【図１６】 従来のパケット伝送方法（方法３）の手順を示すタイミングチャートである。
【図１７】 従来のパケット伝送方法（方法４）の手順を示すタイミングチャートである。
【符号の説明】
１……送信側データ端末、２……受信側データ端末、３……ネットワーク、３ａ……送信側ノード（中継装置）、３ｂ……受信側ノード（中継装置）、３１ａ……受信部、３２ａ……送信部、３３ａ……制御部、３４ａ……記憶部、３５ａ……バス。
【発明の属する技術分野】
本発明は、複数のデータ端末間で行われるパケットの送受信を行うパケット伝送方法、ならびにこれに用いられる中継装置およびデータ端末に関する。
【０００２】
【従来の技術】
近年、画像データや音声データ等のリアルタイム性を要求されるデータを、インターネットを介して伝送したいという要求が強くなってきている。かかる要求に応えるためのプロトコルとして、インターネットの標準化団体であるIETF（Internet Engineering Task Force）が発行するRFC（Request For Comment）1889には、RTP（Realtime Transport Protocol）が規定されている。このRTPによれば、▲１▼ペイロードタイプの指定、▲２▼シーケンス番号の付与、▲３▼タイムスタンプの付与といった機能が規定されており、これにより音声や映像などの実時間情報をインターネット上で伝送することができるようになっている。このRTPは、通常、ネットワーク層のIP（Internet Protocol）およびトランスポート層のUDP（User Datagram Protocol）の上位層として利用されるものである。
【０００３】
ここで、図１１（ａ）は、RTP、UDPおよびIPに従って送信対象となるデータ（音声データまたは画像データ等）に付加されるRTPヘッダ、UDPヘッダおよびIPヘッダ（以下、これらを総称して「RTP/UDP/IPヘッダ」という）の内容を示す図である。なお、以下では、このRTP/UDP/IPヘッダを含むパケットをIPパケットと呼ぶ。
【０００４】
ここで、同図に示すように、IPヘッダは２０バイト、UDPヘッダは８バイト、RTPヘッダは１２バイトとなり、これらのヘッダの合計のデータ量は４０バイトとなる。一方、１つのIPパケットに含まれる画像データは例えば５０バイト程度であるから、かかる画像データをパケット化して伝送する場合、そのオーバーヘッドは４４％にも達することとなる。同様に、音声データを伝送する場合、１つのパケットに含まれる音声データを２０バイトとすれば、オーバーヘッドは６６％にも達することとなる。実際には、さらに他のレイヤにおいて付加されるヘッダがあるため、１つのパケットに占めるヘッダの割合が大きくなり、通信の効率が低下してしまうという問題があった。
【０００５】
かかる問題を解決するための技術として、IETFが発行するRFC2508には、RTP/UDP/IPヘッダを圧縮するＲＴＰ圧縮プロトコルが開示されている。このＲＴＰ圧縮プロトコルによれば、図１１（ａ）に示すRTP/UDP/IPヘッダを、図１１（ｂ）に例示するヘッダ（以下、「圧縮ヘッダ」という）に圧縮することができる。詳述すると、以下の通りである。
【０００６】
この方法は、例えば、複数のデータ端末間でネットワークを介したパケットの送受信が行われる場合に、当該ネットワークに含まれる２つのノード間において用いられる。具体的には、これらのうちの一方のノード（以下、「送信側ノード」という）は、上記各データ端末間で交換されるIPパケットのうちの一部のIPパケット内のRTP/UDP/IPヘッダを圧縮ヘッダに変換し、ヘッダ圧縮パケットとして他方のノード（以下、「受信側ノード」という）に送信する一方、他の一部のIPパケット内のRTP/UDP/IPヘッダは圧縮することなく、フルヘッダパケットとして受信側ノードに送信するのである。一方、受信側ノードは、送信側ノードから受信したヘッダ圧縮パケットまたはフルヘッダパケットを、IPパケットに復元して次のノードまたは受信側のデータ端末に送信する。なお、フルヘッダとは、図１１（ａ）に示したRTP/UDP/IPヘッダに含まれるlengthを、当該フルヘッダを特定するためのCONTEXT_ID、および送信側ノードからの送信順に順次付される連続番号であるリンクシーケンス番号link_seqを含む情報に置き換えたものである。
【０００７】
ここで、図１１（ｂ）に示す圧縮ヘッダの内容について説明する。
まず、図１１（ａ）に示すRTP/UDP/IPヘッダ内の密なハッチングが施された部分のデータ、すなわち、IPヘッダ内のバージョン番号（Ｖ）や、RTPヘッダ内のペイロードタイプ（ＰＴ；画像データであるか音声データであるか等を示すデータのフォーマットや、符号化方法等についての情報を含むデータ）等は、送信側ノードから送信される各パケットにおいて共通のデータ（以下、「一定値フィールド」という）である。従って、図１１（ｂ）に示すように、圧縮ヘッダ内にはこの一定値フィールドのデータは含まれない。送信側ノードは、送信対象となるIPパケットのうち、少なくとも最初のIPパケットは一定値フィールドを含むフルヘッダパケットとして受信側ノードに送信する一方、その後のIPパケット内のRTP/UDP/IPヘッダは、一定値フィールドを含まない圧縮ヘッダに変換し、ヘッダ圧縮パケットとして受信側ノードに送信する。一方、受信側ノードは、少なくとも最初に受信するフルヘッダパケット内のフルヘッダからRTP/UDP/IPヘッダを復元して内部の記憶装置に書込むとともに、当該RTP/UDP/IPヘッダ内の一定値フィールドを用いて、以後受信するヘッダ圧縮パケット内の圧縮ヘッダの一定値フィールドを復元するのである。
【０００８】
ただし、一定値フィールドのデータは、必ずしも全てのIPパケットにおいて一定値となるとは限らず、変更が生じる場合もあり得る。このような変更があった場合、送信側ノードは、当該IPパケット内のRTP/UDP/IPヘッダを圧縮することなく、フルヘッダパケットとして受信側ノードに送信するようになっている。
【０００９】
また、図１１（ａ）に示すRTP/UDP/IPヘッダ内のハッチングが施されていない部分のデータ、すなわち、IPヘッダ内のID、RTPヘッダ内のシーケンス番号（sequence number）およびタイムスタンプ（timestamp；当該パケットが送信された時刻を表す）は、送信対象となる各IPパケット間で値が連続的に（所定の差分値ずつ）変化し、連続する２つのIPパケット間における差分値（変化量）が一定と期待されるデータ（以下、「差分一定フィールド」という）である。図１１（ｂ）に示すように、圧縮ヘッダ内には、原則としてこの差分一定フィールドのデータは含まれない。上述したように、受信側ノードは、記憶装置にRTP/UDP/IPヘッダを保持しており、このRTP/UDP/IPヘッダ内の差分一定フィールドの値に対して所定の差分値を順次加えることにより、以後受信する圧縮ヘッダ内の差分一定フィールドを復元するのである。
【００１０】
ただし、差分一定フィールドのデータに関しては、必ずしも全てのIPパケット間で差分値が一定値になるとは限らず、差分値に変更がある場合も生じる。かかる場合には、変化後の差分値を受信側ノードに対して通知すれば、当該受信側ノードは、記憶装置に保持されたRTP/UDP/IPヘッダの内容と新たに通知された差分値とから、その後に受信したヘッダ圧縮パケット内の圧縮ヘッダの差分一定フィールドの内容を復元することができる。このため、図１１（ｂ）に示す圧縮ヘッダにおいては、差分一定フィールドについての差分値の変更の有無を示すフラグＳ、ＴおよびＩが含まれるとともに、各差分値に変更があった場合には、図１１（ｂ）に破線で示すように、当該変更後の差分値が付加されることとなる。具体的には、RTPヘッダ内のシーケンス番号の差分値に変更があった場合には、フラグＳに「１」がセットされるとともに、図１１（ｂ）に破線で示すように、当該変更後のシーケンス番号の差分値を表すシーケンス番号差分値（delta RTP sequence）が圧縮ヘッダに付加されることとなる。同様に、RTPヘッダ内のタイムスタンプの差分値に変更があった場合、このフラグＴに「１」がセットされるとともに、図１１（ｂ）に破線で示すように、当該変更後のタイムスタンプの差分値を表すタイムスタンプ差分値（delta RTP timestamp）が圧縮ヘッダに含まれることとなる。また、IPヘッダ内のIDの差分値に変更があった場合、フラグＩに「１」がセットされるとともに、当該変更後のIDの差分値を示すID差分値（delta IP ID）が圧縮ヘッダに付加されることとなる。
【００１１】
さらに、図１１（ｂ）に示すように、圧縮ヘッダには、フルヘッダと同様、CONTEXT_IDおよびlink_seqが含まれている。受信側ノードにおいては、このCONTEXT_IDによって特定されるRTP/UDP/IPヘッダの内容に従って、当該圧縮ヘッダが復元されることとなる。また、受信側ノードは、送信側ノードから順次受信するパケット（ヘッダ圧縮パケットまたはフルヘッダパケット）内のリンクシーケンス番号link_seqを参照し、このリンクシーケンス番号に欠番が生じた場合には、送信側ノードと受信側ノードとの間でパケットの喪失が発生したと判定するようになっている。
【００１２】
次に、図１２を参照して、送信側ノードと受信側ノードとの間でなされるパケット転送のための手順を説明する。なお、同図においては、フィールドＡはRTP/UDP/IPヘッダ内の一定値フィールド（すなわち、図１１（ａ）の密なハッチングが施されたデータのうちのいずれか）を表し、フィールドＢは差分一定フィールド（すなわち、図１１（ａ）のハッチングが施されていないデータのうちのいずれか）を表すものとする。また、図１２において、「Ｆ」はフルヘッダパケットを示し、「Ｃ」はヘッダ圧縮パケットを示すものとする。
【００１３】
まず、送信側ノードは、送信側データ端末から受信側データ端末宛に送信されたIPパケットａを受け取ると、このIPパケットａ内のRTP/UDP/IPヘッダを内部の記憶装置に記憶するとともに、当該ヘッダ内のlengthをCONTEXT_IDおよびリンクシーケンス番号link_seqに置き換えてフルヘッダを生成し、このフルヘッダと、上記IPパケット内のRTP/UDP/IPヘッダ以外の部分のデータ（以下、「RTPペイロード」という）とを含むフルヘッダパケットを受信側ノードに送信する（図１２中の▲１▼）。このフルヘッダパケットを受け取った受信側ノードは、このパケット内のフルヘッダからRTP/UDP/IPヘッダを復元し（すなわち、フルヘッダ内のCONTEXT_IDおよびlink_seqを取出して）、当該ヘッダを含むIPパケットを次のノードまたは受信側データ端末に送信する。なお、この際に、復元されたRTP/UDP/IPヘッダを内部の記憶装置に記憶しておく。
【００１４】
続いて、送信側ノードは、IPパケットａの次に受け取ったIPパケットｂ内のRTP/UDP/IPヘッダを圧縮ヘッダに変換して、当該ヘッダ圧縮パケットｂを受信側ノードに送信する（図１２中の▲２▼）。このヘッダ圧縮パケット内の圧縮ヘッダには、パケットｂ内の差分一定フィールドＢの値「１」と、直前に受け取ったパケットａのフルヘッダ内の差分一定フィールドＢの値「０」との差分値ΔＢ（＝１）が付加されるとともに、差分値の変更の有無を示すフラグ（図１１（ｂ）に示すフラグＳ、ＴまたはＩ）に「１」がセットされている。
【００１５】
このヘッダ圧縮パケットｂを受信した受信側ノードは、記憶装置に記憶されたIPパケットａのRTP/UDP/IPヘッダ内の差分一定フィールドＢの値に、今回通知された差分値ΔＢを加えることにより、ヘッダ圧縮パケットｂ内の圧縮ヘッダの差分一定フィールドＢを求める。そして、当該差分一定フィールドＢ、およびIPパケットａのRTP/UDP/IPヘッダ内の一定値フィールドＡを含むRTP/UDP/IPヘッダと、RTPペイロードとを含むIPパケットｂを送信する。なお、IPパケットｂを復元する際に参照されるRTP/UDP/IPヘッダ（この場合にはIPパケットａ内のRTP/UDP/IPヘッダ）は、ヘッダ圧縮パケットｂ内のCONTEXT_IDによって特定される。また、ここではIPパケットｂのRTP/UDP/IPヘッダと、今回通知された差分値ΔＢとが内部の記憶装置に記憶される。
【００１６】
続いて、IPパケットｃを受け取ると、送信側ノードは、当該IPパケットｃ内のフィールドＢの値と、前回受信されたIPパケットｂ内の差分一定フィールドＢとの差分値を求める。ここでは、差分値ΔＢは「１（＝３−２）」であり、前回受信側ノードに対して通知した差分値と同一であるから、新たに差分値を通知する必要はない。従って、送信側ノードは、差分値（すなわち、図１１（ｂ）において破線で示される情報）が付加されない圧縮ヘッダを含んだヘッダ圧縮パケットｃを受信側ノードに対して送信する（図１２中の▲３▼）。一方、このヘッダ圧縮パケットｃを受信した受信側ノードは、先に送信したパケットｂの差分一定フィールドＢに対して記憶装置に記憶されたΔＢを加えることによってヘッダ圧縮パケットｃ内の圧縮ヘッダの差分一定フィールドＢを復元し、この値、およびフルヘッダパケットａのフルヘッダ内の一定値フィールドＡを含むRTP/UDP/IPヘッダとRTPペイロードとからなるIPパケットｃを送信する。以後、パケットｄについても同様の処理がなされる。
【００１７】
さて、次に送信側ノードが受信するIPパケットｅの差分一定フィールドＢは「５」であり、前回のIPパケットｄの差分一定フィールドＢとの差分値は「２」である。このように、差分値ΔＢに変更があった場合、送信側ノードは、変更後の新たな差分値が付加され、フラグに「１」がセットされた圧縮ヘッダを含むヘッダ圧縮パケットｅを受信側ノードに送信する。受信側ノードは、こうして通知された新たな差分値と、IPパケットｄの差分一定フィールドＢの値とを加えることによりパケットｅの差分一定フィールドＢを復元し、当該差分一定フィールドＢを含むIPパケットを送信する。
【００１８】
続いて、次に送信側ノードが受信するIPパケットｇは、直前に受信したIPパケットｅと比較して一定値フィールドＡが異なっている。この場合、送信側ノードは、当該IPパケット内のRTP/UDP/IPヘッダを圧縮せず、パケットｇ内のRTP/UDP/IPヘッダ内のlengthをCONTEXT_IDおよびlink_seqに置き換えたフルヘッダを含むフルヘッダパケットｇを受信側ノードに対して送信する。このフルヘッダパケットｇを受け取った受信側ノードは、これに含まれるフルヘッダをRTP/UDP/IPヘッダに復元して内部の記憶装置に記憶する。
【００１９】
以上がRFC2508に規定されたヘッダ圧縮方法（以下、「従来方法Ａ」という）である。しかしながら、この圧縮方法においては、以下に示す問題があった。
【００２０】
例えば、図１３に示すように、ヘッダ圧縮パケットｃが送信側ノードと受信側ノードとの間で何らかの原因により喪失した場合を想定する。上述したように、受信側ノードは、IPパケットｄ内の差分一定フィールドＢを、IPパケットｃ内の差分一定フィールドＢに差分値ΔＢを加えることにより復元するようになっているため、ヘッダ圧縮パケットｃが喪失した場合にはヘッダ圧縮パケットｄ内の差分一定フィールドＢを復元することができない。この結果、受信側ノードにおいては、次にフルヘッダパケットｇが受信されるまでの間に受信したパケット、すなわち、図１３におけるパケットｄ、ｅおよびｆは破棄せざるを得ない。このように、一部のパケットの喪失に伴ってバースト的なパケットの喪失が発生する結果、ヘッダを圧縮しない方法を採った場合よりもスループットが低下してしまう場合も生じ得る。特に送信側ノードと受信側ノードとの間に無線区間が含まれる場合には、当該無線区間においてパケットの喪失が発生しやすいため、これに伴ってパケットのバースト的なロスが多く引き起こされるという問題があった。かかる問題を解決するための技術として、IETFが発行するRFC2507および2508ならびにInternet-Draftには、以下の各技術が開示されている。
【００２１】
方法１：フルヘッダパケットの周期的な送信（RFC2507）
上述した従来方法Ａにおいては、送信側ノードは、ヘッダ内の一定値フィールドに変更があった場合にのみフルヘッダパケットを送信するようにしたが、この方法１においては、図１４に示すように、一定値フィールドの変更の有無に関わらず、送信対象となる複数のIPパケットを一定個数間隔毎に選択し、選択したIPパケットについてはヘッダを圧縮することなくフルヘッダパケットとして受信側ノードに送信する一方、それ以外のパケットについてはヘッダを圧縮してヘッダ圧縮パケットとして受信側ノードに送信するようになっている。上記従来方法Ａにおいては、一定値フィールドに変更がない限り、受信側ノードにはフルヘッダパケットが送信されないため、以後の全てのパケットが破棄されることとなるが、本方法によれば、一定周期でフルヘッダパケットが送信されるようになっているため、一部のパケットの喪失に起因して破棄されるパケットの数を減らすことができるという利点がある。しかしながら、本方法においては、フルヘッダパケットの送信周期を長くすると、破棄されるパケットの数が増加する一方、フルヘッダパケットの送信周期を短くするとオーバーヘッドの大きいフルヘッダパケットが多数送信されることとなり、通信効率の低下を招くこととなるといった問題がある。
【００２２】
方法２：バックチャネルによるフルヘッダの要求（RFC2507,2508）
本方法においては、図１５に示すように、パケットの喪失を検知すると、受信側ノードは、送信側ノードに対してフルヘッダパケットを要求するためのメッセージであるCONTEXT_STATEを送信するようになっている。送信側ノードは、このCONTEXT_STATEを受信すると、次に送信すべきIPパケットをフルヘッダパケットとして受信側ノードに送信する。この結果、受信側ノードにおいて、一部のパケットの喪失に起因して他のパケットが破棄される期間を、パケットのロスが発生してから、CONTEXT_STATEに応じて送信されたフルヘッダパケットを受信するまでの期間に抑えることができる。しかしながら、本方法においては、受信側ノードがCONTEXT_STATEを送信してから、フルヘッダパケットを受信するまでの時間、すなわちＲＴＴ（Round Trip Time）が大きいと、破棄されるパケットが多くなるという問題がある。無線区間を含んでパケットの送受信が行われる場合には、当該区間において特にＲＴＴが長くなるから、かかる問題は特に顕著に現れる。
【００２３】
方法３：Twiceアルゴリズム（RFC2507）
本方法においては、パケットの喪失が発生した後に受信されるヘッダ圧縮パケット内の圧縮ヘッダを、当該パケットの喪失が発生する直前に受信し、復元したRTP/UDP/IPヘッダに基づいて復元するようになっている。例えば、図１６に示すように、パケットｂが正常に受信された後、パケットｃが喪失し、次にパケットｄが正常に受信された場合を想定する。この場合、パケットｂからパケットｄの間で差分値ΔＢの値に変化がないとすれば、パケットｄ内の差分一定フィールドＢは、パケットｂの差分一定フィールドＢにΔＢを２倍した数値を加えることにより算出することができる。さらに、本方法においては、圧縮ヘッダ内にUDPチェックサムを含ませるようになっており（図１１（ｂ）参照）、このUDPチェックサムを用いて、パケットが正しく復元できたか否かを判断するようになっている。しかしながら、図１６に示すように、パケットｋが喪失し、かつ、パケットｊからパケットｋの間で差分一定フィールドの差分値ΔＢに変化があった場合には、パケット喪失直後に受信されたパケットｌを正確に復元することができないという問題がある。特に、無線区間を含んでパケットの送受信が行われる場合にあっては、パケットの喪失が連続的に（すなわち、長い期間にわたって）発生する。かかる場合には、喪失された多数のパケット間で差分値ΔＢが変化しない場合は少ないと考えられるから、上記問題は特に顕著に現れる。
【００２４】
方法４：ROCCO（Internet-Draft）
本方法においては、送信されるメディアの特性に基づいて、差分値ΔＢを推測するようになっている。例えば、図１７においては、パケットｇおよびｈが喪失し、かつ、パケットｇからパケットｈの間で差分値ΔＢの値に変化があった場合を想定している。この場合、送信されるメディアの特性に基づいて、差分値ΔＢの変化が推測され、推測された差分値ΔＢをパケットｆに加えることにより、パケットｉを復元することができる。さらに、本方法においては、誤り検出符号（CRC）によって正しく復元できたか否かを確認するようになっている。本方法によれば、差分値ΔＢに変化があった場合であっても、その後のパケットを復元することができる。しかしながら、本方法においては、差分値ΔＢの変化をどのように推測するかが問題となる。
【００２５】
【発明が解決しようとする課題】
このように、IPパケットのRTP/UDP/IPヘッダを圧縮した場合であっても効率よくデータ通信を行うための方法として各種の方法が提案されてはいるものの、いずれの方法も何らかの問題を有しており、送信側ノードと受信側ノード間で生じたあるパケットの喪失に起因して破棄されるパケットの数を効果的に減らすには限界があるのが現状であった。
【００２６】
本発明は、上述した事情に鑑みてなされたものであり、送受信すべきパケットのヘッダを圧縮する場合であっても、あるパケットの喪失に起因して破棄されるパケットの数を有効に減らすことができるパケット伝送方法、中継装置およびデータ端末を提供することを目的としている。
【００２７】
【課題を解決するための手段】
上述した課題を解決するために、本発明は、送信側と受信側とを含むネットワークにおいて、前記送信側は、送信すべき非圧縮パケットを、フルヘッダを有するフルヘッダパケットまたは圧縮ヘッダを有するヘッダ圧縮パケットに変換して前記受信側に送信する一方、前記受信側は、前記送信側から送信されたフルヘッダパケットまたはヘッダ圧縮パケットを受信して非圧縮パケットに変換するパケット伝送方法であって、前記受信側は、前記送信側と受信側との間で前記フルヘッダパケットまたはヘッダ圧縮パケットの喪失が発生した場合には、当該パケット喪失後、次にフルヘッダパケットを受信するまでの間に受信したヘッダ圧縮パケットを保持し、前記パケット喪失後に受信したフルヘッダパケット内のフルヘッダの内容に基づいて、前記保持したヘッダ圧縮パケット内の圧縮ヘッダを復元することを特徴とするパケット伝送方法を提供するものである。
【００２８】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について説明する。かかる実施の形態は、本発明の一態様を示すものであり、この発明を限定するものではなく、本発明の範囲内で任意に変更可能である。
【００２９】
Ａ：第１実施形態
Ａ−１：第１実施形態の構成
図１は、本発明に係るパケット伝送方法を適用可能な通信システムの構成を模式的に例示するブロック図である。この通信システムにおいては、送信側データ端末１と受信側データ端末２とが、ネットワーク３を介してパケットの交換を行うことができるようになっている。なお、以下では、送信側データ端末１が受信側データ端末２に対してパケットを送信する場合を例に説明を進める。
【００３０】
ネットワーク３には、送信側ノード３ａおよび受信側ノード３ｂが含まれている。この送信側ノード３ａおよび受信側ノード３ｂは、送信側データ端末１と受信側データ端末２との間で交換されるパケットの中継を行う役割を担っている。なお、図１に示すネットワーク３には、送信側ノード３ａおよび受信側ノード３ｂが１つずつ含まれている場合を例示しているが、本発明を適用できるのはかかる場合に限られず、より多数のノードが含まれていてもよいことはいうまでもない。
【００３１】
かかる構成の下、送信側データ端末１は、受信側データ端末２を宛先に特定したパケットをネットワーク３に対して順次送信する。ここで、送信側データ端末１から送信されるパケットは、図１１（ａ）に示したRTP/UDP/IPヘッダを含むIPパケットである。送信側ノード３ａは、この送信側データ端末１から送信されたIPパケットを順次受信し、受信したIPパケットをフルヘッダを含むフルヘッダパケットまたは圧縮ヘッダを含むヘッダ圧縮パケットのいずれかに変換して受信側ノード３ｂに送信する。ここで、フルヘッダとは、上述したように、IPパケット内のRTP/UDP/IPヘッダにおけるIPヘッダまたはUDPヘッダに含まれるlength値を、CONTEXT_IDまたはlink_seqを含むデータに代えたものである。一方、こうして送信側ノード３ａから送信されたヘッダ圧縮パケットまたはフルヘッダパケットを受信した受信側ノード３ｂは、ヘッダ圧縮パケット内の圧縮ヘッダまたはフルヘッダパケット内のフルヘッダをRTP/UDP/IPヘッダに復元するとともに、当該RTP/UDP/IPヘッダを含むIPパケットを受信側データ端末２に送信する。受信側データ端末２は、受信側ノード３ｂから送信されたIPパケットを受信し、受信したIPパケットに従って所定の処理（例えば、RTPペイロードに従った画像の表示や音声の再生等）を行う。
【００３２】
なお、上記従来の技術にも示したように、フルヘッダパケットは、当該フルヘッダパケットに含まれるフルヘッダの内容のみに基づいてRTP/UDP/IPヘッダを含むIPパケットを復元可能なパケットである。なお、RTP/UDP/IPヘッダ内のlength値は、フルヘッダにおいてCONTEXT_STATEおよびlink_seqに置き換えられるが、下位レイヤの情報から復元可能である。これに対し、ヘッダ圧縮パケットは、当該ヘッダ圧縮パケットに含まれる圧縮ヘッダのみではRTP/UDP/IPヘッダを含むIPパケットを復元することはできないが、その他のパケット（フルヘッダパケット等）の内容に基づいて、IPパケットに復元可能なパケットである。
【００３３】
次に、図２を参照して、受信側ノード３ｂの構成を説明する。同図に示すように、受信側ノード３ｂは、受信部３１ｂ、送信部３２ｂ、制御部３３ｂおよび記憶部３４ｂと、これらの各部を接続するバス３５ｂとを含んで構成されている。
【００３４】
受信部３１ｂは、送信側ノード３ａから送信されたフルヘッダパケットまたはヘッダ圧縮パケットを通信回線を介して受信し、制御部３３ｂに出力するための手段である。また、送信部３２ｂは、制御部３３ｂから出力されたデータを通信回線を介して受信側データ端末２に送信するための手段である。
【００３５】
制御部３３ｂは、ＣＰＵ等を含んで構成され、記憶部３４ｂに記憶されたプログラムを実行することによりこの受信側ノード３ｂの各部を制御するための手段である。具体的には、制御部３３ａは、送信側ノード３ａから受信部３１ｂを介して受信したフルヘッダパケットまたはヘッダ圧縮パケットをIPパケットに変換し、送信部３２ｂを介して受信側データ端末２に送信する機能を有している。また、本実施形態における制御部３３ｂは、送信側ノード３ａと受信側ノード３ｂとの間で生じたパケットの喪失を検知することができる。そして、かかるパケットの喪失が検知された場合、制御部３３ｂは、送信側ノード３ａに対してフルヘッダパケットの送信を要求するためのCONTEXT_STATEを送信するようになっている。
【００３６】
ところで、上記従来の技術に示した各手法においては、送信側と受信側との間でパケットの喪失が生じた場合、喪失したパケット以後のパケットであって、次にフルヘッダパケットが受信されるまでの間に受信されたパケットは破棄されるようになっていた。これに対し、本実施形態における受信側ノード３ｂ内の制御部３３ｂは、パケットの喪失を検知した後、次にフルヘッダパケットを受信するまでの間に受信されたヘッダ圧縮パケットを記憶部３４ｂに順次書き込むようになっている。そして、当該パケットの喪失後にフルヘッダパケットを受信すると、当該フルヘッダパケット内のフルヘッダの内容に基づいて、記憶部３４ｂに記憶されたヘッダ圧縮パケット内の圧縮ヘッダを復元してIPパケットを生成し、受信側データ端末２に送信するようになっている。なお、制御部３３ｂが行う処理については、後の動作説明において詳述する。
【００３７】
なお、送信側ノード３ａも、上述した受信側ノード３ｂと同様の構成となっている。すなわち、送信側ノード３ａは、送信側データ端末１からのIPパケットを受信する受信部３１ａと、当該送信側ノード３ａ内の各部を制御する制御部３３ａと、記憶部３４ａと、制御部３３ａから出力されたパケットを受信側ノード３ｂに対して送信する送信部３２ａとを含んで構成されている。ただし、本実施形態においては、送信側ノード３ａ内の制御部３３ａは、送信側データ端末１から送信されたIPパケットのうち、少なくとも最初のIPパケットをフルヘッダパケットとして受信側ノード３ｂに送信する一方、その他のIPパケットをヘッダ圧縮パケットとして受信側ノード３ｂに送信するようになっている。また、送信側ノード３ａ内の制御部３３ａは、受信側ノード３ｂからCONTEXT_STATEを受信した場合、その直後に送信すべきIPパケットをフルヘッダパケットとして受信側ノード３ｂに送信するようになっている。
【００３８】
Ａ−２：第１実施形態の動作
図３は、本実施形態に係るパケット伝送方法における動作を例示するタイミングチャートである。
同図に示すように、送信側データ端末１から送信対象となる最初のIPパケットａを受信すると、送信側ノード３ａ内の制御部３３ａは、当該パケットをフルヘッダパケットとして受信側ノード３ｂに送信する。具体的には、当該IPパケット内のRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダに含まれるlengthフィールドをCONTEXT_IDおよびlink_seqを含む情報に置き換えたフルヘッダを生成し、当該フルヘッダと、IPパケット中のRTPペイロードとを含むフルヘッダパケットａを受信側ノード３ｂに対して送信する。
【００３９】
次に、送信側データ端末１からIPパケットｂを受信した場合、制御部３３ａは、当該IPパケットｂをヘッダ圧縮パケットとして受信側ノード３ｂに送信する。詳述すると、制御部３３ａは、まず、当該IPパケットのRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダ内の差分一定フィールドの値と、記憶部３４ａに記憶されているIPパケットａのRTP/UDP/IPヘッダの差分一定フィールドの値との差分値を演算する。そして、制御部３３ａは、当該差分値を含む圧縮ヘッダを生成し、この圧縮ヘッダと、IPパケットｂ内のRTPペイロードとを含むヘッダ圧縮パケットを、受信側ノード３ｂに対して送信する。
【００４０】
続いて、送信側データ端末１からIPパケットｃを受信すると、制御部３３ａは、当該IPパケット内のRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダの差分一定フィールドの値と、記憶部３４ａに記憶されているIPパケットｂのRTP/UDP/IPヘッダの差分一定フィールドの値との差分値を求め、当該差分値が、記憶部３４ａに記憶されている差分値（すなわちIPパケットｂとIPパケットａとの間の差分値）と同一であるか否かを判定する。この結果、同一であると判定した場合には、受信側ノード３ｂに対して新たに差分値を通知する必要はないから、制御部３３ａは、差分値を含まない圧縮ヘッダを生成するとともに、当該圧縮ヘッダを含むヘッダ圧縮パケットｃを受信側ノード３ｂに対して送信する。
これに対し、上記差分値が同一でないと判定した場合には、今回新たに求められた差分値を受信側ノード３ｂに対して通知すべく、当該差分値を含む圧縮ヘッダを生成するとともに、当該圧縮ヘッダとIPパケットｃ内のRTPペイロードとを含むヘッダ圧縮パケットを受信側ノード３ｂに対して送信する。さらに、制御部３３ａは、記憶部３４ａに既に記憶されている差分値（すなわち、IPパケットａとIPパケットｂとの間の差分値）を、今回新たに得られた差分値に更新する。
【００４１】
以後、送信側データ端末１からIPパケットｄ、ｅおよびｆを受信した場合も、上記IPパケットｃと同様の処理がなされ、差分値を含むヘッダ圧縮パケットまたは差分値を含まないヘッダ圧縮パケットが受信側ノード３ｂに送信される。
【００４２】
ここで、図３に示す例においては、送信側データ端末１からIPパケットｇを受信する直前に受信側ノード３ｂからのCONTEXT_STATEを受信した場合を想定している。この場合、送信側ノード３ａ内の制御部３３ａは、CONTEXT_STATEの受信直後に送信すべきIPパケットｇを、フルヘッダパケットｇとして送信する。以後同様に、送信側ノード３ａ内の制御部３３ａは、パケットｈ〜ｌについてはヘッダ圧縮パケットとして受信側ノードに送信する一方、CONTEXT_STATEの受信直後に送信すべきパケットｍについてはフルヘッダパケットとして受信側ノード３ｂに送信する。
【００４３】
一方、受信側ノード３ｂ内の制御部３３ｂは、フルヘッダパケットａを受信すると、これに含まれるフルヘッダからRTP/UDP/IPヘッダを復元し、これを含むIPパケットａを受信側データ端末２に送信するとともに、当該RTP/UDP/IPヘッダを記憶部３４ｂに記憶する。次に、ヘッダ圧縮パケットｂを受信すると、制御部３３ｂは、記憶部３４ｂに保持されたIPパケットａのRTP/UDP/IPヘッダの内容を参照してヘッダ圧縮パケットｂ内の圧縮ヘッダをRTP/UDP/IPヘッダに復元し、得られたIPパケットｂを受信側データ端末２に送信する。
【００４４】
ここで、図３においては、送信側ノード３ａから送信されたヘッダ圧縮パケットｃが何らかの理由により喪失された場合を例示している。この場合、受信側ノード３ｂ内の制御部３３ｂは、喪失したヘッダ圧縮パケットｃの次のヘッダ圧縮パケットｄを受信し、当該パケットｄ内のlink_seqがパケットｂ内のlink_seqから連続していないことによりパケットｃが喪失されたことを検知する。パケットｃの喪失が検知されると、制御部３３ｂは、送信側ノード３ａに対し、CONTEXT_STATEを送信するとともに、パケットの喪失から次のフルヘッダパケットを受信するまでの間に受信されるヘッダ圧縮パケットを記憶部３４ｂに順次書き込む。図３に示す例では、パケットｃの喪失が発生してからフルヘッダパケットｇを受信するまでの間に、ヘッダ圧縮パケットｄ〜ｆが受信され、これらのヘッダ圧縮パケットが順次記憶部３４ｂに書込まれることとなる。
【００４５】
次に、受信側ノード３ｂ内の制御部３３ｂは、CONTEXT_STATEに応じて送信側ノード３ａから送信されたフルヘッダパケットｇを受信する。ここで、本実施形態における制御部３３ｂは、このフルヘッダパケットｇ内の差分一定フィールドの値から、差分値Δを順次減じることによって、パケットｄ〜ｆのヘッダ内の差分一定フィールドを復元するようになっている。具体的には、図３に示すように、フルヘッダパケットｇ内の差分一定フィールドの値から差分値Δを減じることにより、パケットｆ内の差分一定フィールドの内容を復元し、こうして復元されたパケットｆ内の差分一定フィールドの値から差分値Δを減じることにより、パケットｅ内の差分一定フィールドの内容を復元する、といった具合である。さらに、本実施形態においては、記憶部３４ｂに記憶されたIPパケットｂのRTP/UDP/IPヘッダの内容に基づいて、パケットｄ〜ｆ内の一定値フィールドの内容も復元されるようになっている。こうして、パケットｄ〜ｆ内のRTP/UDP/IPヘッダの内容が復元されるのである。以下、図４に示すフローチャートを参照して、上記圧縮ヘッダの復元のために受信側ノード３ｂ内の制御部３３ｂが実行する処理の詳細について説明する。
【００４６】
まず、受信側ノード３ｂ内の制御部３３ｂは、link_seqの欠番によってパケットｃの喪失を検知すると、レジスタＮに「０」をセットする（ステップＳ１）。続いて、レジスタＮの内容を「１」だけインクリメントする（ステップＳ３）。
【００４７】
次に、ヘッダ圧縮パケットｄから復元されるべきRTP/UDP/IPヘッダのうち、一定値フィールド、length値、UDPチェックサムおよびマーカビットを復元する。具体的には、記憶部３４ｂに記憶されたIPパケットｂのRTP/UDP/IPヘッダを読み出し、当該ヘッダに含まれる一定値フィールドをパケットｄのRTP/UDP/IPヘッダの一定値フィールドとする。なお、UDPチェックサムおよびマーカビットは、図１１（ｂ）に示すように、圧縮ヘッダ内に含まれるものである。また、length値は、下位レイヤのヘッダに含まれる情報によって取得することができる。さらに、制御部３３ｂは、パケットｄに新たな差分値が含まれている場合（図１１（ｂ）に示す破線部分が含まれている場合）には当該差分値を抽出する（ステップＳ４）。
【００４８】
続いて、ステップＳ４において部分的（一定値フィールド等について）に復元されたRTP/UDP/IPヘッダと、ヘッダ圧縮パケットｄに含まれるRTPペイロードの内容をデータIP(1)として記憶部３４ｂに記憶するとともに、当該時点におけるIPヘッダのIDの差分値、RTPヘッダ内のシーケンス番号の差分値、およびタイムスタンプの差分値を、それぞれΔIP_ID(1)、ΔRTP_SN(1)およびΔRTP_TS(1)として記憶部３４ｂに書き込む（ステップＳ５）。なお、当該時点における各情報（ID、シーケンス番号およびタイムスタンプ）の差分値とは、パケットｄに新たな差分値が付加されている場合には当該差分値であり、含まれていない場合にはその時点において記憶部３４ｂに保持されている差分値である。
【００４９】
以後、フルヘッダパケットｇが受信されるまでの間に受信されるヘッダ圧縮パケットｅおよびｆ（ｎ＝２〜３）についても、ステップＳ２〜Ｓ５の処理が同様に行われる。
【００５０】
次に、フルヘッダパケットｇを受信すると、これに含まれるフルヘッダから取得されるRTP/UDP/IPヘッダを、IP(4)として記憶部３４ｂに記憶する（ステップＳ６）。続いて、パケットｆとフルヘッダパケットｇとの間で差分値に変更がないものとみなし、パケットｅとパケットｆとの間のID、SNおよびTSについての差分値、すなわち、ΔIP_ID(3)、ΔRTP_SN(3)、ΔRTP_TS(3)を、パケットｆとフルヘッダパケットｇとの間のIP、SNおよびTSについての差分値、すなわち、ΔIP_ID(4)、ΔRTP_SN(4)およびΔRTP_TS(4)とする（ステップＳ７）。つまり、
ΔIP_ID(4)＝ΔIP_ID(3)
ΔRTP_SN(4)＝ΔRTP_SN(3)
ΔRTP_TS(4)＝ΔRTP_SN(3)
とする。
【００５１】
次に、フルヘッダパケットｇの各差分一定フィールドの内容から、パケットｆとｇとの間の差分値とみなされた数値、すなわち、上述したΔIP_ID(4)、ΔRTP_SN(4)およびΔRTP_TS(4)を減じることにより、パケットｆの差分一定フィールドの内容を復元する（ステップＳ８）。具体的には、パケットｆについて、復元対象となるIPヘッダ内のID、RTPヘッダ内のシーケンス番号（SN）、およびRTPヘッダ内のタイムスタンプ（TS）の値を、それぞれIP(3).IP_ID、IP(3).RTP_SN、およびIP(3).RTP_TSとし、フルヘッダパケットｇについて、IPヘッダ内のID、RTPヘッダ内のシーケンス番号、およびRTPヘッダ内のタイムスタンプの値を、それぞれIP(4).IP_ID、IP(4).RTP_SN、およびIP(4).RTP_TSとすると、以下の演算によりパケットｆの差分一定フィールドの内容が復元できる。
IP(3).IP_ID＝IP(4).IP_ID−ΔIP_ID(4)
IP(3).RTP_SN＝IP(4).RTP_SN−ΔRTP_SN(4)
IP(3).RTP_TS＝IP(4).RTP_TS−ΔRTP_TS(4)
【００５２】
こうしてパケットｆのRTP/UDP/IPヘッダが復元されると、制御部３３ｂは、パケットｆに含まれていたUDPチェックサムを用い、正しく復元されたか否かを判定する（ステップＳ９）。この結果、正しく復元されたと判定される場合には、レジスタＮの値を「１」だけデクリメントした後（ステップＳ１０）、パケットｅおよびｄについても同様に、ステップＳ８およびＳ９の処理を実行する。
【００５３】
一方、ステップＳ９において、正しく復元できていないと判定される場合には、それよりも前に受信されたパケットについても正しく復元することはできないから、その時点で処理を止めてステップＳ１１に移行する。また、ステップＳ１０において、Ｎの値を「１」だけデクリメントした結果、Ｎの値が「０」となった場合には（ステップＳ１２）、復元対象となる全てのパケットの復元が終了したことを意味するから、ステップＳ１１に移行する。
【００５４】
制御部３３ｂは、ステップＳ１１において、正しく復元できた各パケットを、当該各パケットに含まれるRTPヘッダ内のシーケンス番号の順に、順次受信側データ端末２に送信する。なお、正しく復元できなかったパケットについては破棄される。
以上が本実施形態における動作である。
【００５５】
上述したように、本実施形態に係るパケット伝送方法によれば、パケット喪失が発生した後に受信されるヘッダ圧縮パケットを保持しておき、次に受信したフルヘッダパケットの内容に基づいてこれらのパケットのヘッダを復元するようになっている。ここで、上記従来の技術において示した各方法においては、パケットの喪失が発生した後、次のフルヘッダパケットが受信されるまでの間においては、各パケットが適切に受信されているにもかかわらず破棄しなければならないという問題があった。これに対し、本実施形態においては、パケットの喪失から次のフルヘッダパケット受信までの間に受信されたパケットを有効に利用することができる。従って、パケットの喪失によって、受信側データ端末におけるデータの再生等に与えられる影響を、従来の技術と比較して小さくすることができるという利点がある。
【００５６】
Ａ−３：第１実施形態の変形例
上記第１実施形態においては、パケットｃの喪失が発生してから次のフルヘッダパケットｇが受信されるまでの間に受信されたパケットｄ〜ｆの一定値フィールドを、当該パケットｃの喪失よりも前に受信されたIPパケットｂのRTP/UDP/IPヘッダの内容に従って復元するようにしたが、これに限らず、例えば、これらのパケットｄ〜ｆの一定値フィールドを、新たに受信されたフルヘッダパケットｇの内容に基づいて復元するようにしてもよい。図５は、本変形例におけるパケット復元のための動作を表すフローチャートである。なお、同図に示すフローチャートは、復元対象となるパケット内の一定値フィールドを、これらの各パケットの受信後に受信されたフルヘッダパケットｇの内容に基づいて復元する点を除いて前掲図４に示したものと同様であるため、以下では、図４と比較して異なる点についてのみ説明する。
【００５７】
まず、上記第１実施形態においては、ステップＳ４において、パケットの喪失後に受信されたヘッダ圧縮パケット内の一定値フィールドの情報を、既に受信され記憶部３４ｂに保持されているIPパケットｂのRTP/UDP/IPヘッダの一定値フィールドを用いて復元するようにしたが、本変形例においては、ステップＳ４’においては一定値フィールドの復元は行わず、length値、UDPチェックサムおよびマーカビットＭのみを復元するようになっている。従って、続くステップＳ５において、IP（Ｎ）として記憶部３４ｂに記憶されるのは、一定値フィールドおよび差分一定フィールドを含まないRTP/UDP/IPヘッダと、今回受信したヘッダ圧縮パケット内のRTPペイロードとを有するパケットである。
【００５８】
一方、復元対象となるパケットの一定値フィールドは、ステップＳ８’において、当該パケットの次のフルヘッダパケットｇの内容に基づいて復元される。すなわち、図５のステップＳ８’に下線を付して示すように、復元対象となるパケットの一定値フィールドを、当該パケットの直後に受信されたフルヘッダパケットに含まれる一定値フィールドの内容と同様の内容とみなすのである。例えば、図３に示した状況を例にとると、パケットｆの一定値フィールドの内容を、当該パケットｆの直後に受信されたフルヘッダパケットｇの一定値フィールドと同一とみなすことにより、パケットｆの一定値フィールドの内容を復元する。また、パケットｅの一定値フィールドの内容を、こうして復元されたパケットｆの一定値フィールドの内容と同一であるとみなすことにより、パケットｅの一定値フィールドの内容を復元するようになっている。
【００５９】
本変形例にあっても、最終的にはUDPチェックサムにより正確に復元されたか否かが判定され、正確に復元されたパケットのみが受信側データ端末に送信されることとなる。本変形例によっても上記第２実施形態と同様の効果を得ることができる。
【００６０】
Ｂ：第２実施形態
Ｂ−１：第２実施形態の構成
上記各実施形態においては、ネットワーク３内の受信側ノード３ｂにおいて、パケットの喪失が発生した後に受信したヘッダ圧縮パケットを保持するとともに、当該パケット喪失後に受信したフルヘッダパケットの内容に基づいて、保持したヘッダ圧縮パケットの内容を復元するようにした。しかしながら、上記各実施形態においては、パケットの喪失後に受信したフルヘッダパケットの差分一定フィールドと、当該フルヘッダパケットの直前に受信したヘッダ圧縮パケットの差分一定フィールドとの差分値に変更がないものと仮定して上記復元を行うようにしたため（図４中のステップＳ７）、この差分値に変更があった場合には、保持されたヘッダ圧縮パケットの内容を正しく復元できないという問題が発生し得る。本実施形態は、このような問題を解決可能なパケット中継方法に係るものである。
【００６１】
本実施形態に係る通信システムの構成、ならびに送信側ノード３ａおよび受信側ノード３ｂの構成は、前掲図１および図２に示したものと同様となる。ただし、上記実施形態における送信側ノード３ａから受信側ノード３ｂへの送信対象がフルヘッダパケットまたはヘッダ圧縮パケットであったのに対し、本実施形態における送信側ノード３ａは、これらのパケットに加え、所定の場合には差分値を含むフルヘッダパケットを送信対象とする点で異なっている。具体的には、本実施形態における送信側ノード３ａは、送信側データ端末１から受信したIPパケットをフルヘッダパケットとして送信すべき場合であって、かつ、当該IPパケットの差分一定フィールドと、その直前に受信したIPパケットの差分一定フィールドとの差分値が、記憶部３４ａに記憶された差分値と異なっている場合（すなわち、差分値に変更があった場合）には、当該新たな差分値を含むフルヘッダパケットを受信側ノード３ｂに対して送信するようになっている。
【００６２】
ここで、図６（ａ）は、差分値が付加されたフルヘッダパケットの内容を模式的に表す図である。同図に破線で示すように、このフルヘッダパケットには、RTP/UDP/IPヘッダ内の差分一定フィールド（すなわち、IPヘッダ内のID、ならびにRTPヘッダ内のシーケンス番号およびタイムスタンプ）のうちの差分値に変更があったものについて、当該変更後の差分値が含まれることとなる。また、上記各実施形態と同様に、フルヘッダパケット内のフルヘッダは、IPヘッダおよびUDPヘッダ内のlength（図６（ａ）において斜線を付した部分）をCONTEXT_IDおよびlink_seqに置き換えたものであるが、差分値を付加した場合のフルヘッダパケットにおいては、図６（ｂ）および（ｃ）に示すように、CONTEXT_IDおよびlink_seqに加え、フラグＳ、ＴおよびＩが含まれることとなる。これらの各フラグは、差分値に変更があった差分一定フィールドを示す情報である。例えば、RTPヘッダ内のシーケンス番号の差分値に変更があった場合、図６（ａ）に破線で示すように当該変更後の差分値ΔRTP_SNがヘッダに付加されるとともに、フラグＳに「１」がセットされるのである。また、ＩＰヘッダ内のＩＤの差分値に変更があった場合、当該変更後の差分値ΔIP_IDがヘッダに付加されるとともに、フラグＩに「１」がセットされる。同様に、ＲＴＰヘッダ内のタイムスタンプの差分値に変更があった場合には、変更後の差分値ΔRTP_TSがヘッダに付加されるとともに、フラグＴに「１」がセットされる。受信側ノード３ｂは、差分値が付加されたフルヘッダパケットを受信すると、上記フラグを参照することにより変更があった差分一定フィールド（ID、シーケンス番号、タイムスタンプのいずれであるか）を検知するとともに、当該差分一定フィールドの変更後の差分値を取得することができるのである。
【００６３】
Ｂ−２：第２実施形態の動作
次に、図７を参照して、本実施形態の動作を説明する。なお、以下では、上記第１実施形態と同様に、送信側ノード３ａが、受信側ノード３ｂからCONTEXT_STATEを受信することを契機として、IPパケットをフルヘッダパケットとして受信側ノード３ｂに送信する場合を例示する。
【００６４】
まず、送信側データ端末１からIPパケットａ乃至ｆを順次受信すると、送信側ノード３ａ内の制御部３３ａは、最初のIPパケットａについてはフルヘッダパケットとして受信側ノード３ｂに送信する一方、IPパケットｂ乃至ｃについてはヘッダ圧縮パケットとして受信側ノード３ｂに送信する。なお、この動作は、上記第１実施形態で示したものと同様であるため、その詳細な説明を省略する。
【００６５】
ここで、図７においては、送信側ノード３ａ内の制御部３３ａが、送信側データ端末１からIPパケットｇを受信する直前に、受信側ノード３ｂからCONTEXT_STATEを受信した場合を想定している。この場合、制御部３３ａは、当該CONTEXT_STATEの受信直後に送信側データ端末１から受信したIPパケットｇを、差分値を含まないフルヘッダパケットまたは差分値が付加されたフルヘッダパケットとして受信側ノード３ｂに送信する。具体的には、以下の通りである。
【００６６】
まず、制御部３３ａは、今回受信したIPパケットｇに含まれるRTP/UDP/IPヘッダを記憶部３４ａに書き込むとともに、当該RTP/UDP/IPヘッダの差分一定フィールドの値と、記憶部３４ａに記憶されているRTP/UDP/IPヘッダ（IPパケットｆに含まれていたもの）の差分一定フィールドの値との差分値を求める。続いて、制御部３３ａは、得られた差分値が、記憶部３４ａに記憶された差分値と同一であるか否かを判定する。この結果、記憶部３４ａに記憶された差分値と同一であると判定した場合には、当該差分値は既に受信側ノード３ｂに通知されているから、今回得られた差分値を受信側ノード３ｂに改めて通知する必要はない。従って、制御部３３ａは、IPパケットｇのRTP/UDP/IPヘッダ内のlengthをCONTEXT_ID（上記フルヘッダパケットａに含ませたCONTEXT_IDとは異なるもの）およびlink_seqを含む情報に置き換えたフルヘッダを生成し、当該フルヘッダとIPパケットｇ内のRTPペイロードとを含むフルヘッダパケットｇを受信側ノード３ａに対して送信する。
【００６７】
これに対し、上記判定において記憶部３４ａに記憶された差分値と同一でないと判定した場合、制御部３３ａは、今回得られた差分値を受信側ノード３ｂに対して通知すべく、当該差分値を含むフルヘッダパケットを受信側ノード３ｂに対して送信する。詳述すると、制御部３３ａは、まず、IPパケットｇのRTP/UDP/IPヘッダ内のlengthを、CONTEXT_IDおよびlink_seq、ならびに変更があった差分一定フィールドに対応して「１」がセットされたフラグ（図６（ｃ）参照）を含むデータに置き換えるとともに、上記変更後の新たな差分値（図６（ａ）に破線で示す部分）を含むフルヘッダを生成する。そして、制御部３３ａは、このフルヘッダと、IPパケットｇ内のRTPペイロードとを含むフルヘッダパケットｇを、受信側ノード３ｂに対して送信するのである。なお、図７においては、IPパケットｆとIPパケットｇとの間の差分一定フィールドの差分値に変更があり、当該IPパケットｇが差分値を含むフルヘッダパケットｇとして送信された場合を例示している。
【００６８】
送信側データ端末１から以後のIPパケットｈ乃至ｎを受信した場合にも上記と同様の処理がなされ、差分値を含まないヘッダ圧縮パケットまたはフルヘッダパケット、もしくは差分値を含むヘッダ圧縮パケットまたはフルヘッダパケットのいずれかが、適宜送信側ノード３ａから受信側ノード３ｂに対して送信される。
【００６９】
次に、受信側ノード３ｂの制御部３３ｂが、上記のようにして送信側ノード３ａから送信されたパケットを受信した場合の動作を説明する。
まず、送信側ノードから送信されたフルヘッダパケットａを受信すると、受信側ノード３ｂ内の制御部は、当該フルヘッダパケットａ内のフルヘッダに含まれるCONTEXT_IDおよびlink_seq等を抽出して記憶部３４ｂに書き込むとともに、フルヘッダ中のこれらの情報を、下位レイヤの内容に基づいて得られるlengthに置き換えて、RTP/UDP/IPヘッダを復元する。そして、このRTP/UDP/IPヘッダを、先に書込んだCONTEXT_IDおよびlink_seqに対応付けて記憶部３４ｂに書き込むとともに、当該RTP/UDP/IPヘッダを含むIPパケットａを受信側データ端末２に対して送信する。
【００７０】
次に、送信側ノード３ａから送信されたヘッダ圧縮パケットｂを受信すると、受信側ノード３ｂ内の制御部３３ｂは、当該ヘッダ圧縮パケットｂに含まれる差分値を記憶部３４ｂに書き込む。さらに、制御部３３ｂは、当該圧縮ヘッダに含まれるCONTEXT_IDと同一のCONTEXT_IDを記憶部３４ｂから検索し、検索されたCONTEXT_IDに対応付けられたRTP/UDP/IPヘッダ（この場合にはIPパケットａのRTP/UDP/IPヘッダ）を読み出す。そして、読み出したRTP/UDP/IPヘッダの差分一定フィールドに、今回取得した差分値を加算して得られる差分一定フィールドと、IPパケットａのRTP/UDP/IPヘッダ内の一定値フィールドとを含むRTP/UDP/IPヘッダを生成する。さらに、制御部３３ｂは、記憶部３４ｂに既に記憶されているIPパケットａのRTP/UDP/IPヘッダを、今回新たに得られたRTP/UDP/IPヘッダに更新するとともに、当該RTP/UDP/IPヘッダを含むIPパケットｂを、受信側データ端末２に対して送信する。
【００７１】
ここで、図７においては、送信側ノード３ａから送信されたヘッダ圧縮パケットｃが何らかの理由により喪失された場合を例示している。この場合、受信側ノード３ｂの制御部３３ｂは、ヘッダ圧縮パケットｄ内のlink_seqがパケットｂ内のlink_seqから連続していないことによってヘッダ圧縮パケットｃが喪失されたことを検知する。以下、図８に示すフローチャートを参照して、かかるパケットの喪失が検知された場合に制御部３３ｂによって実行される動作について説明する。
【００７２】
まず、受信側ノード３ｂ内の制御部３３ｂは、レジスタｎに「０」をセットするとともに（ステップＳ２１）、直前に受信したパケット（すなわち、喪失されたパケットの次のパケット）がヘッダ圧縮パケットであるか否かを判定する（ステップＳ２２）。図７に示す例では、パケット喪失直後に受信したのはヘッダ圧縮パケットｄであるから、この判定の結果は「Ｙｅｓ」となる。次に、制御部３３ｂは、このヘッダ圧縮パケットについて、一定値フィールド、length値、UDPチェックサムおよびマーカビット（Ｍbit）を復元し、復元された情報と今回受信したヘッダ圧縮パケット内のRTPペイロードとをIP(n)として記憶部３４ｂに記憶する（ステップＳ２３）。すなわち、ヘッダ圧縮パケットｄから復元されるべきIPパケットｄ内の差分一定フィールド以外のフィールドが復元され、IP(0)として記憶部３４ｂに記憶されることとなる。なお、この復元動作は、上記第１実施形態に示したものと同様にして行うことができる。
【００７３】
続いて、制御部３３ｂは、当該時点における差分一定フィールドの差分値、すなわち、IPヘッダのIDの差分値、RTPヘッダのシーケンス番号の差分値、およびRTPヘッダのタイムスタンプの差分値を、それぞれΔIP_ID(n)、ΔRTP_SN(n)、およびΔRTP_TS(n)として（以下、これらをまとめて「Δ(n)」と表記する）、記憶部３４ｂに記憶する（ステップＳ２４）。なお、当該時点における差分値とは、今回受信したヘッダ圧縮パケットに新たな差分値が付加されている場合には当該差分値であり、含まれていない場合には当該時点において記憶部３４ｂに記憶されている差分値である。
【００７４】
続いて、制御部３３ｂは、次のパケットを受信するまで待機し、当該次のパケットを受信すると（ステップＳ２５）、レジスタｎの値を「１」だけインクリメントする（ステップＳ２６）。以後、上記のステップＳ２２〜Ｓ２６に示した動作がヘッダ圧縮パケットｅおよびｆについても実行され、この結果、ヘッダ圧縮パケットｄ〜ｆについては、図９に例示する各情報（すなわち、IP(n)およびΔ(n)）が記憶部３４ｂに記憶される。
【００７５】
一方、ステップＳ２５においてフルヘッダパケットを受信すると、続くステップＳ２２における判定結果が「Ｎｏ」となってステップＳ２７に進む。すなわち、制御部３３ｂは、受信したフルヘッダパケットｇ内のフルヘッダに含まれるCONTEXT_IDおよびlink_seq等をlengthに置き換えたRTP/UDP/IPヘッダを生成し、当該RTP/UDP/IPヘッダと今回受け取ったフルヘッダパケットのRTPペイロードとからなるIPパケットを生成する。そして、得られたIPパケットを、IP(3)として記憶部３４ｂに記憶する（ステップＳ２７）。ここで、図９に示すように、すなわちフルヘッダパケットから得られたIPパケット（IP(3)）のRTP/UDP/IPヘッダには、差分一定フィールド（すなわち、ID、シーケンス番号およびタイムスタンプ）の値も含まれる。
【００７６】
続いて制御部３３ｂは、当該フルヘッダパケットとその前に受信されたヘッダ圧縮パケットとの間の各差分一定フィールドの差分値をΔ(n)として記憶部３４ｂに記憶する。図７の場合を例にとれば、以下の通りである。まず、制御部３３ｂは、今回受信したフルヘッダパケットｇに新たな差分値（図６（ａ）において破線で示された部分）が付加されているか否かを判定する（ステップＳ２８）。この結果、差分一定フィールドのいずれかについての差分値が付加されていると判定すると、当該差分一定フィールドについては新たな差分値を、他の差分一定フィールドについては、当該時点において記憶部３４ｂに記憶された差分値を、それぞれΔ(3)として記憶部３４ｂに記憶する（ステップＳ２９）。これに対し、今回受信したフルヘッダパケットｇに新たな差分値が付加されていない場合には、当該時点において記憶部３４ｂに記憶されている差分値を、Δ(3)として記憶部３４ｂに記憶する（ステップＳ３０）。
【００７７】
以上示した動作の結果、パケットｄ乃至ｇについて、図９に示す情報が記憶部３４ｂに記憶されることとなる。なお、この時点において、IP(3)として記憶されたIPパケットｇには差分一定フィールドの値も含まれているものの、パケットｄ乃至ｆの差分一定フィールドはIP(0)〜IP(2)には含まれていない。従って、以後、これらのパケットｄ乃至ｆ（すなわち、ヘッダ圧縮パケットとして受信されたパケット）のRTP/UDP/IPヘッダに含ませるべき差分一定フィールドの値を復元するための動作が実行される。
【００７８】
まず、制御部３３ｂは、レジスタｎの値を「１」だけデクリメントするとともに（ステップＳ３２）、フルヘッダパケットから復元されたRTP/UDP/IPヘッダ中の差分一定フィールドの値から、上記のようにして得られた差分値を減算することにより、当該フルヘッダパケットの直前に受信したヘッダ圧縮パケットの差分一定フィールドを復元する（ステップＳ３３）。図７に例示した場合にあっては、フルヘッダパケットｇの内容に基づいて記憶されたIP(3)に含まれる差分一定フィールドの各値から、Δ(3)として記憶された各差分一定フィールドの差分値を減算することにより、ヘッダ圧縮パケットｆの差分一定フィールドを復元する。具体的には、IP(3)に含まれるIDの値をIP(3).IP_ID、IP(3)に含まれるシーケンス番号の値をIP(3).RTP_SN、IP(3)に含まれるタイムスタンプの値をIP(3).RTP_TSとすると、ヘッダ圧縮パケットｆの差分一定フィールドIP(2).IP_ID、IP(2).RTP_SN、IP(2).RTP_TSの値は、
IP(2).IP_ID＝IP(3).IP_ID−ΔIP_ID(3)
IP(2).RTP_SN＝IP(3).RTP_SN−ΔRTP_SN(3)
IP(2).RTP_TS＝IP(3).RTP_TS−ΔRTP_TS(3)
なる演算によって得られる（図９参照）。
【００７９】
こうして差分一定フィールドの値を復元すると、制御部３３ｂは、当該差分一定フィールドと、IP(2)として記憶部３４ｂに記憶されている差分一定フィールド以外の部分とを合わせてIPパケットｆを生成する。この後、制御部３４ｂは、当該IPパケットｆに含まれるUDPチェックサムを用い、正しく復元されたか否かを判定する（ステップＳ３４）。この結果、正しく復元されていると判定した場合、制御部３３ｂは、当該IPパケットｆを記憶部３４ｂに記憶する（ステップＳ３５）。以後、制御部３３ｂは、他のヘッダ圧縮パケットｅおよびｄの差分一定フィールドを復元するための動作、すなわち、上述したステップＳ３２〜Ｓ３５に示したのと同様の動作を繰り返す。
【００８０】
ここで、ステップＳ３１において、レジスタｎの値が「０」となった場合には、保持されたすべてのヘッダ圧縮パケットの復元が終了したことを意味しているから、それまでに記憶部３４ｂに記憶されたIPパケット（フルヘッダパケットから得られたIPパケットも含む）を、RTPヘッダ中のシーケンス番号の順番に、受信側データ端末２に対して順次送信する（ステップＳ３７）。
【００８１】
一方、ステップＳ３４において、正しく復元できていないと判定される場合には、それよりも前に受信されたヘッダ圧縮パケットについても正しく復元することはできないから、復元が失敗したパケットを破棄するとともに（ステップＳ３６）、それ以前に復元が完了しているIPパケットを受信側データ端末２に対して送信する（ステップＳ３７）。
以上が本実施形態の動作である。
【００８２】
このように、本実施形態によれば、差分値の変更があった場合には、ヘッダ圧縮パケットのみならずフルヘッダパケットについても当該差分値を付加して送信するようになっている。従って、フルヘッダパケットとして送信すべきIPパケットとその直前のIPパケットとの間で差分値に変更があった場合であっても、受信側ノード３ｂにおいては正確にヘッダ圧縮パケットの内容を復元することができる。
【００８３】
Ｃ：第３実施形態
上記各実施形態においては、パケットの喪失直後に受信したフルヘッダパケット内の差分一定フィールドの値から、パケット喪失後に保持したヘッダ圧縮パケットに関する差分値を順次減算することによって、保持したヘッダ圧縮パケットをIPパケットに復元するようにした。しかしながら、パケット喪失後に受信したフルヘッダパケットに基づいて、保持したヘッダ圧縮パケットを復元するための方法は、これに限られるものではない。以下に示す本実施形態は、かかる方法の一例に関するものである。なお、以下では、本実施形態のうち、上記各実施形態と異なる部分についてのみ説明する。
【００８４】
上記各実施形態における送信側ノード３ａは、IPパケット中の差分一定フィールドの差分値に変更があった場合、ヘッダ圧縮パケットの圧縮ヘッダ中に当該変更後の差分値を含ませるようにした。これに対し、本実施形態においては、この差分値に代えて、各差分一定フィールドの値を表すビット列のうちの下位の数ビット（以下、「下位ビット列LSB」という）を、ヘッダ圧縮パケット中の圧縮ヘッダに含ませるようになっている。
【００８５】
すなわち、送信側ノード３ａは、送信側データ端末１からヘッダ圧縮パケットとして送信すべきIPパケットを受信すると、当該IPパケット内の差分一定フィールドの値と、記憶部３４ａに記憶されているIPパケット（その直前に受信したIPパケット）内の各差分一定フィールドの値との差分値を求め、記憶部に記憶されている差分値と比較する。この結果、いずれかの差分一定フィールドの差分値に変更があったと判定すると、送信側ノード３ａ内の制御部３３ａは、今回受信したIPパケット中の変更があった差分一定フィールドを表すビット列から下位ビット列LSBを抽出する。そして、この下位ビット列LSBと、変更があった差分一定フィールドに応じて「１」がセットされたフラグ（図１１（ｂ）におけるフラグＳ、ＴおよびＩに相当する）とを含む圧縮ヘッダを生成し、この圧縮ヘッダを含むヘッダ圧縮パケットを受信側ノード３ｂに対して送信するのである。一方、上記差分値の比較の結果、双方の差分値が同一である場合には、今回受信したIPパケットを圧縮したヘッダ圧縮パケット中には、下位ビット列LSBは含ませない。
【００８６】
ところで、上記下位ビット列LSBを、差分一定フィールドを表すビット列のうちの下位何ビットに設定するかは、送信対象となるデータや、差分一定フィールド（ID、シーケンス番号およびタイムスタンプ）ごとの性質等に応じて適宜選定される。例えば、差分一定フィールドを表すビット列のうち、変更が生じないと予想される上位数ビットを除いたビット列を、下位ビット列LSBとすることが考えられる。
【００８７】
次に、図１０を参照して、本実施形態の動作を説明する。なお、実際には、上記第１実施形態等にも示したように、差分一定フィールドにはIPヘッダ中のIDや、RTPヘッダ中のシーケンス番号およびタイムスタンプ等が含まれるが、以下では、簡単のため、これらを総称して単に「差分一定フィールド」と呼ぶこととする。
【００８８】
まず、送信側ノード３ａは、送信側データ端末１から最初に受信したIPパケットａをフルヘッダパケットとして、以後受信したIPパケットｂ乃至ｆをヘッダ圧縮パケットとして受信側ノード３ｂに送信する。さらに、図１０においては、IPパケットｇを受信する直前に、受信側ノード３ｂからCONTEXT_STATEを受信した場合を想定しているので、送信側ノード３ａは、IPパケットｇについてはフルヘッダパケットとして受信側ノード３ｂに送信する。ここで、上述したように、ヘッダ圧縮パケット中の圧縮ヘッダには、差分一定フィールドの差分値に変更があったものについてのみ下位ビット列LSBが含まれることとなる。図１０においては、ヘッダ圧縮パケットｂ、ｄおよびｆには下位ビット列LSBb、LSBdおよびLSBfがそれぞれ含まれる一方、ヘッダ圧縮パケットｅには下位ビット列LSBが含まれない場合を想定している。
【００８９】
一方、受信側ノード３ｂ内の制御部３３ｂは、送信側ノード３ａから最初に受信したフルヘッダパケットａからIPパケットａを復元して記憶部３４ｂに格納するとともに、このIPパケットａを受信側データ端末２に送信する。続いて制御部３３ｂは、次に受信したヘッダ圧縮パケットｂを、IPパケットａを用いて復元する。具体的には、図１０に示すように、記憶部３４ｂに格納されたIPパケットａのうちの差分一定フィールドを読み出し、この差分一定フィールドを表すビット列のうちの下位ビット列LSBaを、ヘッダ圧縮パケットｂに含まれる下位ビット列LSBbに置換することによってヘッダ圧縮パケットｂの差分一定フィールドを復元する（図１０中の▲１▼）。そして、制御部３３ｂは、この差分一定フィールドを含むIPパケットｂを生成して記憶部３４ｂに格納するとともに、このIPパケットｂを受信側データ端末２に送信するのである。
【００９０】
ここで、図１０においては、送信側ノード３ａから送信されたヘッダ圧縮パケットｃが、受信側ノード３ｂによって受信される前に、何らかの原因によって喪失された場合を想定している。受信側ノード３ｂ内の制御部３３ｂは、ヘッダ圧縮パケットｂの次にヘッダ圧縮パケットｄを受信したことによってヘッダ圧縮パケットｃが喪失されたことを検知すると、送信側ノード３ａに対してCONTEXT_STATEを送信する。
【００９１】
さらに、制御部３３ｂは、パケットｃの喪失後、次にフルヘッダパケットｇを受信するまでに受信したヘッダ圧縮パケットｄ乃至ｆを記憶部３４ｂに順次格納する。具体的には、下位ビット列LSBを含むヘッダ圧縮パケットを受信した場合には、当該ヘッダ圧縮パケットをそのまま記憶部３４ｂに格納する。一方、下位ビット列LSBを含まないヘッダ圧縮パケットを受信した場合には、当該ヘッダ圧縮パケットに対して、その直前に受信した、下位ビット列LSBを含むヘッダ圧縮パケットのLSBを付加して記憶部３４ｂに格納する。例えば、図１０に示す例においては、ヘッダ圧縮パケットｅは下位ビット列LSBを含まないので、その直前に受信した下位ビット列を含むヘッダ圧縮パケットｄの当該下位ビット列LSBdが、下位ビット列LSBeとして、ヘッダ圧縮パケットｅとともに記憶部３４ｂに格納されることとなる。
【００９２】
次に、先に送信したCONTEXT_STATEに応じて送信側ノード３ａから送信されたフルヘッダパケットｇを受信すると、制御部３３ｂは、このフルヘッダパケットｇの内容に基づいて、記憶部３４ｂに保持されたヘッダ圧縮パケットｄ乃至ｆをIPパケットに復元するための処理を実行する。以下、この復元処理について詳述する。
【００９３】
まず、制御部３３ｂは、フルヘッダパケットｇをIPパケットｇに復元して記憶部３４ｂに格納するとともに、当該IPパケットｇを受信側データ端末２に送信する。なお、図１０においては、当該IPパケットｇ中の差分一定フィールドを表すビット列のうち、下位ビット列を「LSBg」、それ以外のビットを「Ｇ」によってそれぞれ表記している。
【００９４】
次に、制御部３３ｂは、記憶部３４ｂに格納されたIPパケットｇ内の差分一定フィールドを読み出し、当該差分一定フィールドを表すビット列のうちの下位ビット列LSBgを、記憶部３４ｂに格納されたヘッダ圧縮パケットｆの下位ビット列LSBfに置き換え、ヘッダ圧縮パケットｆの差分一定フィールドを復元する（図１０中の▲２▼）。そして、制御部３３ｂは、この差分一定フィールドと、IPパケットｇの一定値フィールドとを含むIPパケットｆを生成するとともに、ヘッダ圧縮パケットｆ中に含まれていたチェックサムを用いて正しく復元できたか否かを判定する。
【００９５】
IPパケットｆが正しく復元できた場合には、このIPパケットｆを用いてヘッダ圧縮パケットeが復元される。すなわち、制御部３３ｂは、IPパケットｆの差分一定フィールドのうちの下位ビット列LSBfを、記憶部３４ｂに格納されたヘッダ圧縮パケットｅの下位ビット列LSBe（LSBdと同一の内容である）に置き換えて、ヘッダ圧縮パケットｅの差分一定フィールドを復元する（図１０中の▲３▼）。一方、IPパケットｆが正しく復元できなかった場合には、フルヘッダパケットとして受信・復元されたIPパケットｇを用いてヘッダ圧縮パケットｅが復元される。すなわち、制御部３３ｂは、IPパケットｇの差分一定フィールドのうちの下位ビット列LSBgを、記憶部３４ｂに格納されたヘッダ圧縮パケットｅに対応する下位ビット列LSBeに置き換えて、ヘッダ圧縮パケットｅの差分一定フィールドを復元する。
【００９６】
こうして、IPパケットｆまたはｇのいずれかの内容に基づいて、ヘッダ圧縮パケットｅについての差分一定フィールドを復元すると、制御部３３ｂは、この差分一定フィールドと、IPパケットｆまたはｇ内の一定値フィールドとを含むIPパケットｅを生成するとともに、ヘッダ圧縮パケットｅに含まれていたチェックサムを用いて正しく復元できたか否かを判定する。
【００９７】
以後、制御部３３ｂは、パケットｃの喪失後、フルヘッダパケットｇの受信までの間に受信したすべてのヘッダ圧縮パケットについて同様の処理を行う。そして、すべてのヘッダ圧縮パケットについて処理を終了すると、正しく復元できたIPパケットのみを、各々のRTPヘッダ中に含まれるシーケンス番号の順に、順次受信側データ端末２に送信する。一方、正しく復元できなかったパケットは破棄する。
【００９８】
このように、本実施形態においても、上記各実施形態と同様に、パケット喪失後に受信されたヘッダ圧縮パケットが、当該パケット喪失直後に受信されたフルヘッダパケットに基づいて順次復元されるようになっているため、上記各実施形態と同様の効果を得ることができる。さらに、本実施形態においては、あるヘッダ圧縮パケットの復元に際し、パケット喪失直後に受信したフルヘッダパケット、または当該ヘッダ圧縮パケットの直前に復元されたIPパケットのうちのいずれかを用いることができる。例えば、図１０においては、ヘッダ圧縮パケットｄの復元に際してフルヘッダパケットｇを復元したIPパケットｇ、またはヘッダ圧縮パケットeを復元したIPパケットeのうちのいずれかを用いることができる。従って、復元対象となるヘッダ圧縮パケットｄの直前の復元対象であるヘッダ圧縮パケットｅが正しく復元されなかった場合であっても、IPパケットｇの内容に基づいてヘッダ圧縮パケットｄを復元することができるのである。従って、本実施形態によれば、上記各実施形態と比較して復元の効率を向上させることができるという利点がある。
【００９９】
上記各実施形態に示したように、本発明においては、パケット喪失後に受信・保持したヘッダ圧縮パケットの内容を、当該パケット喪失直後に受信したフルヘッダパケットの内容に基づいて復元するものであればよい。すなわち、パケット喪失直後に受信したフルヘッダパケットを用いて、それ以前のヘッダ圧縮パケットを復元する方法は、上記各実施形態に示した方法に限られるものではなく、他の種々の方法をも用いることができるのである。
【０１００】
Ｄ：第４実施形態
上記各実施形態においては、送信側ノード３ａがIPパケットをヘッダ圧縮パケットまたはフルヘッダパケットに変換する機能（以下、「圧縮機能」という）を有する一方、受信側ノード３ｂがヘッダ圧縮パケットまたはフルヘッダパケットをIPパケットに変換する機能（以下、「復元機能」という）を有するようにした。これに対し、本実施形態においては、図１に示す送信側データ端末および受信側ノード３ｂが圧縮機能を有し、送信側ノード３ａおよび受信側データ端末２が復元機能を有するようになっている。
【０１０１】
具体的には、送信側データ端末１は、送信対象となるIPパケットを順次生成し、最初のIPパケットおよび送信側ノード３ａからCONTEXT_STATEを受信した直後に送信すべきIPパケットについては、フルヘッダパケットとして送信側ノード３ａに送信する一方、その他のIPパケットについては、ヘッダ圧縮パケットとして送信側ノード３ａに送信する。
【０１０２】
一方、送信側ノード３ａは、上記第１実施形態における受信側ノード３ｂと同様の動作を行うことにより、送信側データ端末１から送信されたフルヘッダパケットまたはヘッダ圧縮パケットをIPパケットに復元し、受信側ノード３ｂに送信する。受信側ノード３ｂは、これらのIPパケットを受信し、フルヘッダパケットまたはヘッダ圧縮パケットに変換して受信側データ端末に送信する。
【０１０３】
一方、受信側データ端末２は、受信側ノード３ｂから受信したフルヘッダパケットまたはヘッダ圧縮パケットをIPヘッダに変換する。ここで、受信側ノード３ｂと受信側データ端末２との間で生じたパケットの喪失を検知すると、受信側データ端末２は、当該パケットの喪失後、次にフルヘッダパケットが受信されるまでの間に受信されたヘッダ圧縮パケットを内部の記憶装置に記憶する。そして、当該パケットの喪失後にフルヘッダパケットを受信すると、当該フルヘッダパケット内のフルヘッダの内容に基づいて、上記記憶装置に記憶されたヘッダ圧縮パケット内の圧縮ヘッダを復元してIPパケットを生成するのである。この後、受信側データ端末２は、受信した各パケットに含まれるデータに従って画像の表示や音声の出力等の処理を行う。こうした場合にも、上記各実施形態と同様の効果が得られる。
【０１０４】
以上説明したように、パケットの喪失後、次にフルヘッダパケットを受信するまでに受信されたヘッダ圧縮パケットの圧縮ヘッダの内容を、当該フルヘッダパケット内のフルヘッダの内容に基づいて復元する機能を、受信側データ端末に持たせるようにしてもよいのである。すなわち、本発明にかかるパケット伝送方法は、ネットワーク内でパケットの送受信を行う任意の装置に対して適用可能である。つまり、特許請求の範囲における「送信側」および「受信側」は、データ端末間のパケットの交換を中継するパケット中継装置のみならず、パケットの送信元であるデータ端末およびパケットの送信先であるデータ端末をも含む概念である。
【０１０５】
Ｅ：変形例
＜変形例１＞
上記各実施形態においては、送信側ノード３ａは、受信側ノード３ｂからのCONTEXT_STATEを受信した直後に送信すべきIPパケットを、フルヘッダパケットとして受信側ノード３ｂに対して送信するようにした。しかしながら、送信側ノード３ａがフルヘッダパケットとして送信するIPパケットの条件は、これに限られるものではない。送信側ノード３ａからフルヘッダパケットとして送信されるIPパケットとしては、例えば以下のようなものが考えられる。
【０１０６】
ａ．第１の態様
送信対象となるIPパケット内のRTP/UDP/IPヘッダ内の一定値フィールドの値に変更が生じない場合、送信側ノード３ａは、上記実施形態に示したように、最初に送信すべきIPパケット、および受信側ノードからCONTEXT_STATEを受信した直後に送信すべきIPパケットについてのみフルヘッダパケットとして送信することも可能である。しかしながら、一定値フィールドの値に変更が生じ得る場合には、かかるパケットに加え、上記従来技術Ａにも示したように、一定値フィールドの内容に変更があったパケットもフルヘッダパケットとして送信される必要がある。すなわち、送信側ノード３ａ内の制御部３３ａは、RTP/UDP/IPヘッダ内の一定値フィールドに変更があったパケットについても、フルヘッダパケットとして送信するようにしてもよい。なお、CONTEXT_STATEを受信した直後に送信すべきIPパケットに代えて、一定値フィールドに変更があったIPパケットについてのみフルヘッダパケットとして送信するようにしてもよいことは言うまでもない。
【０１０７】
ｂ．第２の態様
送信側ノード３ａにおいては、上記従来の技術において方法１として示したように、送信側データ端末１から順次送信されるパケットのうちの１のパケットを一定個数間隔毎に選択し、選択したパケットをフルヘッダパケットとして受信側ノード３ｂに送信するようにしてもよい。
【０１０８】
なお、上記第１および第２の態様においても、受信側ノード３ｂは、パケットの喪失が発生してから、送信側ノード３ａからのフルヘッダパケットが受信されるまでに受信されたパケットを保持しておき、当該フルヘッダパケットの内容に基づいてこれらの保持したパケットを復元する点は上記各実施形態と同様である。
【０１０９】
＜変形例２＞
フルヘッダパケットおよびヘッダ圧縮パケットは、上記各実施形態に示したものに限られない。すなわち、本発明における「フルヘッダパケット」とは、送信側ノードにおける圧縮動作の内容と、受信側ノードにおける復元動作の内容とを一致させるための機能を有するパケットであればいかなる構成であってもよい。例えば、フルヘッダパケットは、上記機能を有していれば、必ずしもそれ自身の内容に基づいて非圧縮パケットを復元可能なパケットである必要はないし、また、必ずしもIPヘッダに基づいて生成されるパケットである必要はない。一方、圧縮ヘッダは、他のパケット（フルヘッダパケットや、ヘッダ圧縮パケットを復元したIPパケット）の内容に基づいて復元可能なパケットであれば、いかなる構成としてもよい。
【０１１０】
【発明の効果】
本発明においては、パケットの喪失時から次にフルヘッダが受信されるまでに受信されたヘッダ圧縮パケットを保持しておき、当該パケットの喪失後に受信したフルヘッダパケットの内容に基づいて、当該保持されたヘッダ圧縮パケット内の圧縮ヘッダを復元するようになっている。この結果、上記従来の技術と比較して、他のパケットの喪失に伴って破棄されるパケットを減らすことができるという利点がある。
【図面の簡単な説明】
【図１】 本発明の第１実施形態に係る通信システムの構成を例示するブロック図である。
【図２】 同通信システムにおける受信側ノードの構成を例示するブロック図である。
【図３】 同通信システムにおける動作を示すタイミングチャートである。
【図４】 同通信システムにおける受信側ノードの、パケット喪失時の動作を示すフローチャートである。
【図５】 第１実施形態の変形例におけるパケット喪失時の動作を示すフローチャートである。
【図６】 本発明の第２実施形態に係る通信システムにおける差分値付きフルヘッダパケットの構成を表す図である。
【図７】 同通信システムにおける動作を示すタイミングチャートである。
【図８】 同通信システムにおける受信側ノードの、パケット喪失時の動作を示すフローチャートである。
【図９】 同通信システムにおけるパケット喪失時の、受信側ノード内の記憶部の記憶内容を例示する図である。
【図１０】 本発明の第３実施形態に係る通信システムにおける動作を示すタイミングチャートである。
【図１１】 （ａ）はRTP/UDP/IPヘッダの内容を示す図であり、（ｂ）は圧縮ヘッダの内容を示す図である。
【図１２】 従来のパケット伝送方法（従来方法Ａ）の手順を示すタイミングチャートである。
【図１３】 同パケット伝送方法の問題点を説明するためのタイミングチャートである。
【図１４】 従来のパケット伝送方法（方法１）の手順を示すタイミングチャートである。
【図１５】 従来のパケット伝送方法（方法２）の手順を示すタイミングチャートである。
【図１６】 従来のパケット伝送方法（方法３）の手順を示すタイミングチャートである。
【図１７】 従来のパケット伝送方法（方法４）の手順を示すタイミングチャートである。
【符号の説明】
１……送信側データ端末、２……受信側データ端末、３……ネットワーク、３ａ……送信側ノード（中継装置）、３ｂ……受信側ノード（中継装置）、３１ａ……受信部、３２ａ……送信部、３３ａ……制御部、３４ａ……記憶部、３５ａ……バス。
Claims (8)
- 送信側と受信側とを含むネットワークにおいて、前記送信側は、送信すべき非圧縮パケットを、フルヘッダを有するフルヘッダパケットまたは圧縮ヘッダを有するヘッダ圧縮パケットに変換して前記受信側に送信する一方、前記受信側は、前記送信側から送信されたフルヘッダパケットまたはヘッダ圧縮パケットを受信して非圧縮パケットに変換するパケット伝送方法であって、
前記受信側は、
前記送信側と受信側との間で前記フルヘッダパケットまたはヘッダ圧縮パケットの喪失が発生した場合には、当該パケット喪失後、次にフルヘッダパケットを受信するまでの間に受信したヘッダ圧縮パケットを保持し、
前記パケット喪失後に受信したフルヘッダパケット内のフルヘッダの内容に基づいて、前記保持したヘッダ圧縮パケット内の圧縮ヘッダを復元する
ことを特徴とするパケット伝送方法。 - 前記非圧縮パケットに含まれる非圧縮ヘッダは、各非圧縮パケット間で所定の差分値ずつ変化する差分一定情報を含み、
前記受信側は、
前記パケット喪失後に受信したフルヘッダパケットのフルヘッダに含まれる差分一定情報から所定の差分値を減ずることにより、前記保持したヘッダ圧縮パケットの差分一定情報を復元する
ことを特徴とする請求項１に記載のパケット伝送方法。 - 前記非圧縮パケットに含まれる非圧縮ヘッダは、各非圧縮パケット間で所定の差分値ずつ変化する差分一定情報を含み、
前記送信側は、
前記非圧縮パケットを変換したフルヘッダパケットのうち少なくとも一部の前記フルヘッダパケットに対し、当該非圧縮パケットと他の非圧縮パケットとの間の前記差分一定情報の差分値を付加する一方、
前記受信部は、
前記パケット喪失後に、前記差分値が付加されたフルヘッダパケットを受信した場合には、当該差分値と、当該フルヘッダパケットのフルヘッダに含まれる差分一定情報とを用いて、前記保持したヘッダ圧縮パケットの差分一定情報を復元する
ことを特徴とする請求項１に記載のパケット伝送方法。 - 前記送信側は、
前記非圧縮パケットをフルヘッダパケットとして送信する場合であって、当該非圧縮パケットと、当該非圧縮パケットの直前の非圧縮パケットとの間の差分一定情報の差分値が、他の非圧縮パケット間の差分一定情報の差分値と異なる場合に、当該フルヘッダパケットに対して差分値を付加する
ことを特徴とする請求項３に記載のパケット伝送方法。 - 前記非圧縮パケットに含まれる非圧縮ヘッダは、各非圧縮パケット間で同一となる一定値情報を含み、
前記受信側は、
前記パケット喪失直前または直後に受信したフルヘッダパケット内のフルヘッダに含まれる一定値情報に基づいて、前記保持したヘッダ圧縮パケットの一定値情報を復元する
ことを特徴とする請求項１乃至４のいずれかに記載のパケット伝送方法。 - 前記非圧縮パケットに含まれる非圧縮ヘッダは、各非圧縮パケット間で所定の差分値ずつ変化する差分一定情報を含む一方、少なくとも一部の前記ヘッダ圧縮パケット内の圧縮ヘッダは、前記非圧縮ヘッダ内の差分一定情報を表すビット列のうちの一部である部分ビット列を含み、
前記受信側は、
前記パケット喪失後に受信したフルヘッダパケットのフルヘッダに含まれる差分一定情報を表すビット列のうちの一部を、所定のヘッダ圧縮パケットに含まれる前記部分ビット列に置き換えることによって、前記保持したヘッダ圧縮パケットの差分一定情報を復元する
ことを特徴とする請求項１に記載のパケット伝送方法。 - 複数のデータ端末間に介在し、各データ端末間で交換されるパケットを中継する中継装置において、
フルヘッダを有するフルヘッダパケットまたは圧縮ヘッダを有するヘッダ圧縮パケットを受信して、非圧縮パケットに変換する受信手段と、
前記フルヘッダパケットまたはヘッダ圧縮パケットが、前記受信手段によって受信される前に喪失した場合には、当該パケット喪失後、次にフルヘッダパケットを受信するまでの間に受信されたヘッダ圧縮パケットを保持する保持手段と、
前記パケット喪失後に受信されたフルヘッダパケット内のフルヘッダの内容に基づいて、前記保持手段によって保持されたヘッダ圧縮パケット内の圧縮ヘッダを復元する復元手段と
を具備することを特徴とする中継装置。 - 他のデータ端末との間でネットワークを介したパケット交換が可能なデータ端末であって、
フルヘッダを有するフルヘッダパケットまたは圧縮ヘッダを有するヘッダ圧縮パケットを受信して、非圧縮パケットに変換する受信手段と、
フルヘッダパケットまたはヘッダ圧縮パケットが、前記受信手段によって受信される前に喪失した場合には、当該パケット喪失後、次にフルヘッダパケットを受信するまでの間に受信されたヘッダ圧縮パケットを保持する保持手段と、
前記パケット喪失後に受信されたフルヘッダパケット内のフルヘッダの内容に基づいて、前記保持手段によって保持されたヘッダ圧縮パケット内の圧縮ヘッダを復元する復元手段と
を具備することを特徴とするデータ端末。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000146787A JP3730835B2 (ja) | 2000-03-03 | 2000-05-18 | パケット伝送方法、中継装置およびデータ端末 |
| SG200101043A SG100624A1 (en) | 2000-03-03 | 2001-02-22 | Method and apparatus for packet transmission with header compression |
| EP01104404A EP1137237B1 (en) | 2000-03-03 | 2001-02-26 | Method and apparatus for packet transmission with header compression |
| DE2001613906 DE60113906T2 (de) | 2000-03-03 | 2001-02-26 | Verfahren und Vorrichtung zur Paketübertragung mit Paketenkopfkompression |
| US09/794,842 US6385199B2 (en) | 2000-03-03 | 2001-02-26 | Method and apparatus for packet transmission with header compression |
| KR1020010011017A KR100359703B1 (ko) | 2000-03-03 | 2001-03-03 | 헤더 압축에 의한 패킷 전송 방법 및 장치 |
| CNB011109475A CN1165140C (zh) | 2000-03-03 | 2001-03-05 | 标题压缩分组的传输方法和设备 |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000059368 | 2000-03-03 | ||
| JP2000-59368 | 2000-05-01 | ||
| JP2000-132685 | 2000-05-01 | ||
| JP2000132685 | 2000-05-01 | ||
| JP2000146787A JP3730835B2 (ja) | 2000-03-03 | 2000-05-18 | パケット伝送方法、中継装置およびデータ端末 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002026963A JP2002026963A (ja) | 2002-01-25 |
| JP3730835B2 true JP3730835B2 (ja) | 2006-01-05 |
Family
ID=27342580
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000146787A Expired - Lifetime JP3730835B2 (ja) | 2000-03-03 | 2000-05-18 | パケット伝送方法、中継装置およびデータ端末 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6385199B2 (ja) |
| EP (1) | EP1137237B1 (ja) |
| JP (1) | JP3730835B2 (ja) |
| KR (1) | KR100359703B1 (ja) |
| CN (1) | CN1165140C (ja) |
| DE (1) | DE60113906T2 (ja) |
| SG (1) | SG100624A1 (ja) |
Families Citing this family (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI107000B (fi) * | 1999-02-17 | 2001-05-15 | Nokia Mobile Phones Ltd | Otsikon pakkaaminen reaaliaikaisissa palveluissa |
| US6754231B1 (en) | 1999-06-18 | 2004-06-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Robust header compression in packet communications |
| US6791982B2 (en) * | 1999-09-29 | 2004-09-14 | Telefonaktiebolaget Lm Ericsson | Segmentation protocol that supports compressed segmentation headers |
| US6711164B1 (en) * | 1999-11-05 | 2004-03-23 | Nokia Corporation | Method and apparatus for performing IP-ID regeneration to improve header compression efficiency |
| US6535925B1 (en) * | 1999-11-09 | 2003-03-18 | Telefonaktiebolaget L M Ericsson (Publ) | Packet header compression using division remainders |
| EP1146713B1 (en) * | 2000-03-03 | 2005-04-27 | NTT DoCoMo, Inc. | Method and apparatus for packet transmission with header compression |
| US20020001315A1 (en) * | 2000-03-21 | 2002-01-03 | Tran Hung V. | Method and apparatus for compressing IP/UDP/RTP headers in a lossy environment |
| US20040136380A1 (en) * | 2000-09-12 | 2004-07-15 | Daiji Ido | Packet transmitter, packet receiver and packet transmission method |
| JP3323483B2 (ja) * | 2000-09-12 | 2002-09-09 | 松下電器産業株式会社 | パケット送信装置およびパケット伝送方法 |
| EP1374524A1 (en) * | 2001-03-29 | 2004-01-02 | BRITISH TELECOMMUNICATIONS public limited company | Protocol conversion |
| JP3512177B2 (ja) | 2001-05-16 | 2004-03-29 | 松下電器産業株式会社 | パケット受信装置及びパケット伝送方法 |
| JP3617967B2 (ja) | 2001-09-28 | 2005-02-09 | 松下電器産業株式会社 | ヘッダ圧縮パケット受信装置及び方法 |
| US6954460B2 (en) | 2001-10-05 | 2005-10-11 | Ericsson Inc. | Method and apparatus for compressing packet headers |
| JP4549610B2 (ja) * | 2001-11-08 | 2010-09-22 | ソニー株式会社 | 通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラム |
| US7814068B2 (en) * | 2001-11-16 | 2010-10-12 | Gemalto Sa | Identifying changed records in a file stored on an electronic token |
| KR100765122B1 (ko) * | 2001-11-24 | 2007-10-11 | 엘지전자 주식회사 | 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법 |
| DE60229482D1 (de) * | 2001-11-24 | 2008-12-04 | Lg Electronics Inc | Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem |
| KR100425745B1 (ko) * | 2001-11-24 | 2004-04-06 | 엘지전자 주식회사 | 패킷의 헤더압축을 지원하는 통신 시스템에서 패킷의전송방법 |
| KR100443012B1 (ko) * | 2001-12-22 | 2004-08-04 | 엘지전자 주식회사 | 압축데이터의 바이트열 복원 방법 |
| US6760345B1 (en) * | 2002-01-16 | 2004-07-06 | Raytheon Company | Compressing cell headers for data communication |
| US20030196081A1 (en) * | 2002-04-11 | 2003-10-16 | Raymond Savarda | Methods, systems, and computer program products for processing a packet-object using multiple pipelined processing modules |
| JP3857611B2 (ja) * | 2002-05-20 | 2006-12-13 | 富士通株式会社 | データ圧縮プログラム、データ圧縮方法、およびデータ圧縮装置 |
| CA2432594C (en) * | 2002-06-12 | 2011-01-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for increased internet protocol (ip) headers compression performance by reporting cause of missing packets |
| KR100497357B1 (ko) * | 2002-06-26 | 2005-06-23 | 삼성전자주식회사 | 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법 |
| JP4317403B2 (ja) * | 2002-08-09 | 2009-08-19 | パナソニック株式会社 | ヘッダ圧縮装置及びヘッダ圧縮方法 |
| US7647421B2 (en) * | 2002-08-20 | 2010-01-12 | Nokia Corporation | Extension header compression |
| KR100663586B1 (ko) * | 2002-08-28 | 2007-01-02 | 삼성전자주식회사 | 헤더 압축에 의한 패킷 데이터의 송신 방법 및 장치 |
| KR20040040724A (ko) * | 2002-11-07 | 2004-05-13 | 엘지전자 주식회사 | 무선 이동 통신 시스템의 상향 공통채널 및 그 운용 방법 |
| JP4406816B2 (ja) * | 2002-12-11 | 2010-02-03 | ソニー株式会社 | 受信装置および受信方法、記録媒体、並びにプログラム |
| US7386013B1 (en) * | 2003-01-03 | 2008-06-10 | Juniper Networks, Inc. | Systems and methods for compressing packet headers |
| US20040225748A1 (en) * | 2003-05-09 | 2004-11-11 | Chong Huai-Ter Victor | Systems and methods for deleting transactions from multiple fast data streams |
| GB2403877A (en) * | 2003-07-09 | 2005-01-12 | Motorola Inc | Packet communication with header compression |
| US7450586B2 (en) * | 2003-07-22 | 2008-11-11 | Motorola, Inc. | Network header compression arrangement |
| US7512715B2 (en) * | 2003-09-26 | 2009-03-31 | Nokia Corporation | System and method for requesting a resource over at least one network with reduced overhead |
| US7372841B2 (en) | 2004-07-12 | 2008-05-13 | Research In Motion Limited | Packet-based communication system and method |
| KR100703494B1 (ko) * | 2004-08-09 | 2007-04-03 | 삼성전자주식회사 | 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치 |
| US8165104B2 (en) * | 2004-12-08 | 2012-04-24 | Qualcomm Incorporated | Methods and systems for enhancing local repair in robust header compression |
| US7864701B2 (en) * | 2005-03-31 | 2011-01-04 | Intel Corporation | Apparatus, system and method capable of decreasing management frame size in wireless networks |
| US7602778B2 (en) * | 2005-06-29 | 2009-10-13 | Cisco Technology, Inc. | System and methods for compressing message headers |
| US9031071B2 (en) | 2005-08-26 | 2015-05-12 | Alcatel Lucent | Header elimination for real time internet applications |
| KR100748342B1 (ko) | 2005-09-14 | 2007-08-09 | 매그나칩 반도체 유한회사 | 씨모스 이미지 센서의 제조방법 |
| US7948989B2 (en) * | 2006-05-04 | 2011-05-24 | Qualcomm, Incorporated | Methods and systems for enhancing local repair in robust header compression |
| JP4954622B2 (ja) | 2006-06-29 | 2012-06-20 | 京セラ株式会社 | 受信装置および復号方法 |
| CN101479985B (zh) * | 2006-06-29 | 2012-05-30 | 京瓷株式会社 | 内容数据、发送装置、接收装置以及解码方法 |
| US7616568B2 (en) * | 2006-11-06 | 2009-11-10 | Ixia | Generic packet generation |
| US7899025B2 (en) * | 2006-12-26 | 2011-03-01 | Alcatel-Lucent Usa Inc. | Header suppression in a wireless communication network |
| US8027328B2 (en) * | 2006-12-26 | 2011-09-27 | Alcatel Lucent | Header compression in a wireless communication network |
| JP4937005B2 (ja) * | 2007-06-13 | 2012-05-23 | 三菱電機株式会社 | 音声伝送装置 |
| US7885294B2 (en) * | 2007-08-23 | 2011-02-08 | Cisco Technology, Inc. | Signaling compression information using routing protocols |
| US8059651B2 (en) * | 2007-12-17 | 2011-11-15 | Motorola Solutions, Inc. | Method for recovering lost header |
| US8559463B2 (en) * | 2008-02-20 | 2013-10-15 | General Dynamics C4 Systems, Inc. | Systems and methods for providing efficient bandwidth utilization in packet switched networks |
| US7898985B1 (en) * | 2008-04-23 | 2011-03-01 | Juniper Networks, Inc. | Composite next hops for forwarding data in a network switching device |
| JP4985565B2 (ja) * | 2008-06-30 | 2012-07-25 | 富士通株式会社 | 送受信回路、受信回路及び送受信回路の制御方法 |
| KR101236033B1 (ko) * | 2008-07-21 | 2013-02-21 | 한국전자통신연구원 | 통신 오버헤드를 제거하는 통신 시스템 |
| US8014317B1 (en) | 2008-08-21 | 2011-09-06 | Juniper Networks, Inc. | Next hop chaining for forwarding data in a network switching device |
| WO2010032318A1 (ja) * | 2008-09-19 | 2010-03-25 | 富士通株式会社 | パケットの送信方法及びノード |
| US7899056B2 (en) * | 2009-01-13 | 2011-03-01 | Fujitsu Limited | Device and method for reducing overhead in a wireless network |
| US8023513B2 (en) * | 2009-02-24 | 2011-09-20 | Fujitsu Limited | System and method for reducing overhead in a wireless network |
| WO2010124472A1 (zh) * | 2009-04-30 | 2010-11-04 | 华为技术有限公司 | 一种数据的传输方法、相关设备和通信系统 |
| US8509237B2 (en) * | 2009-06-26 | 2013-08-13 | Wisconsin Alumni Research Foundation | Architecture and system for coordinated network-wide redundancy elimination |
| CN102484643B (zh) | 2009-07-08 | 2015-11-25 | 汤姆森特许公司 | 后向鲁棒性首标压缩接收器 |
| CN101764811B (zh) * | 2009-12-30 | 2013-02-13 | 飞天诚信科技股份有限公司 | 数据流的生成方法 |
| CN113301015A (zh) * | 2011-12-20 | 2021-08-24 | 华为技术有限公司 | 网际协议头置换映射关系的获取方法及网络节点 |
| US20140153580A1 (en) * | 2013-02-15 | 2014-06-05 | Comtech Ef Data Corp. | Reference encoding and decoding for improving network header compression throughput for noisy channels |
| JP6654136B2 (ja) * | 2014-08-08 | 2020-02-26 | 京セラ株式会社 | 受信端末及び送信端末 |
| US11073822B2 (en) * | 2014-09-25 | 2021-07-27 | Siemens Aktiengesellschaft | Provision of process values in a process installation |
| JP6524771B2 (ja) * | 2015-03-23 | 2019-06-05 | 日本電気株式会社 | 通信装置、パケット伝送方法、及び、プログラム |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9617553D0 (en) * | 1996-08-21 | 1996-10-02 | Walker Christopher P H | Communication system with improved routing switch |
| US5987022A (en) * | 1996-12-27 | 1999-11-16 | Motorola, Inc. | Method for transmitting multiple-protocol packetized data |
| JPH10247935A (ja) * | 1997-03-05 | 1998-09-14 | Yazaki Corp | データ通信システムに用いられるデータフォーマット |
| US6032197A (en) * | 1997-09-25 | 2000-02-29 | Microsoft Corporation | Data packet header compression for unidirectional transmission |
| US6111924A (en) * | 1998-02-03 | 2000-08-29 | Videoserver, Inc. | Error-correction-code synchronization in a videoconferencing gateway |
| US6092120A (en) * | 1998-06-26 | 2000-07-18 | Sun Microsystems, Inc. | Method and apparatus for timely delivery of a byte code and serialized objects stream |
-
2000
- 2000-05-18 JP JP2000146787A patent/JP3730835B2/ja not_active Expired - Lifetime
-
2001
- 2001-02-22 SG SG200101043A patent/SG100624A1/en unknown
- 2001-02-26 US US09/794,842 patent/US6385199B2/en not_active Expired - Lifetime
- 2001-02-26 DE DE2001613906 patent/DE60113906T2/de not_active Expired - Lifetime
- 2001-02-26 EP EP01104404A patent/EP1137237B1/en not_active Expired - Lifetime
- 2001-03-03 KR KR1020010011017A patent/KR100359703B1/ko active IP Right Grant
- 2001-03-05 CN CNB011109475A patent/CN1165140C/zh not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1137237A2 (en) | 2001-09-26 |
| EP1137237A3 (en) | 2003-10-15 |
| JP2002026963A (ja) | 2002-01-25 |
| US6385199B2 (en) | 2002-05-07 |
| KR100359703B1 (ko) | 2002-11-04 |
| DE60113906T2 (de) | 2006-07-06 |
| EP1137237B1 (en) | 2005-10-12 |
| DE60113906D1 (de) | 2005-11-17 |
| US20010030963A1 (en) | 2001-10-18 |
| CN1165140C (zh) | 2004-09-01 |
| SG100624A1 (en) | 2003-12-26 |
| KR20010087314A (ko) | 2001-09-15 |
| CN1311591A (zh) | 2001-09-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3730835B2 (ja) | パケット伝送方法、中継装置およびデータ端末 | |
| EP1146713B1 (en) | Method and apparatus for packet transmission with header compression | |
| JP4317403B2 (ja) | ヘッダ圧縮装置及びヘッダ圧縮方法 | |
| JP3751823B2 (ja) | 実時間サービスにおけるヘッダ圧縮 | |
| JP4582565B2 (ja) | パケット通信におけるロバストヘッダ圧縮 | |
| JP3559019B2 (ja) | 信頼できないネットワークが存在する場合にロバストなｉｐ／ｕｄｐ／ｒｔｐヘッダ圧縮を達成するシステム及び方法 | |
| KR101649374B1 (ko) | 가속화된 처리율을 달성하는 시스템 및 방법 | |
| US7164680B2 (en) | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications | |
| JP4592935B2 (ja) | ヘッダ復元装置およびヘッダ復元方法 | |
| JP2001320422A (ja) | ヘッダ圧縮を伴うパケット伝送のための方法および装置 | |
| JP4859323B2 (ja) | チェックサムに基づくヘッダ圧縮におけるトランスポート層チェックサムの代替 | |
| JP2003500933A (ja) | インターネットプロトコルを使用する遠隔通信のための方法および装置 | |
| EP1187417B1 (en) | Method and apparatus for transmitting data packets | |
| JP4814864B2 (ja) | パケット多重化装置及びパケット多重化プログラム | |
| KR100497357B1 (ko) | 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법 | |
| US20060259845A1 (en) | Method and apparatus for acknowledging a bitwise data chunk in wireline and wireless communication systems | |
| JP2002541724A (ja) | デジタル・データ転送方法および装置 | |
| CN102006295A (zh) | 基于atm承载ip语音的数据压缩方法 | |
| US20040165542A1 (en) | Packet transmitter and packet transmitter method | |
| JP2002094553A (ja) | パケット伝送装置およびパケット伝送方法 | |
| JP2008141633A (ja) | データ通信システム、データ受信装置、データ受信方法、データ送信装置およびデータ送信方法 | |
| JP4529883B2 (ja) | パケット伝送装置 | |
| JP2001313673A (ja) | パケット伝送方法、パケット中継装置およびデータ端末 | |
| Madsen et al. | IP header compression for media streaming in wireless networks | |
| EP1482700A1 (en) | Packet transmitter and packet transmission method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050301 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050510 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050711 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051007 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3730835 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091014 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101014 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111014 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121014 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131014 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |