JP4602568B2 - パケットサーバで用いられる通信方法 - Google Patents

パケットサーバで用いられる通信方法 Download PDF

Info

Publication number
JP4602568B2
JP4602568B2 JP2001014224A JP2001014224A JP4602568B2 JP 4602568 B2 JP4602568 B2 JP 4602568B2 JP 2001014224 A JP2001014224 A JP 2001014224A JP 2001014224 A JP2001014224 A JP 2001014224A JP 4602568 B2 JP4602568 B2 JP 4602568B2
Authority
JP
Japan
Prior art keywords
gtp
header
rtp
udp
packet
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 - Fee Related
Application number
JP2001014224A
Other languages
English (en)
Other versions
JP2001244993A5 (ja
JP2001244993A (ja
Inventor
チュー チュア ムーイ
Original Assignee
アルカテル−ルーセント ユーエスエー インコーポレーテッド
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by アルカテル−ルーセント ユーエスエー インコーポレーテッド filed Critical アルカテル−ルーセント ユーエスエー インコーポレーテッド
Publication of JP2001244993A publication Critical patent/JP2001244993A/ja
Publication of JP2001244993A5 publication Critical patent/JP2001244993A5/ja
Application granted granted Critical
Publication of JP4602568B2 publication Critical patent/JP4602568B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • 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
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、通信に関し、特に、パケット通信システムに関する。
【０００２】
【従来の技術】
ワイヤレスシステムが発展するとともに、移動通信交換センタ（ＭＳＣ）と基地局の間の通信は、インターネットプロトコル（ＩＰ）に基づくトランスポートメカニズムに移行しつつある。（ここで、ワイヤレスシステムという用語は、例えば、ＣＤＭＡ（符号分割多元接続）、ＧＳＭ(Global System for Mobile Communications)、提案されているＵＭＴＳ(Universal Mobile Telecommunications System)などを指す。）ワイヤレス通信の性質（例えば、リアルタイム音声）を考慮すると、ＩＰベースのトランスポートは、リアルタイムアプリケーションを収容するプロトコルを利用する必要がある。
【０００３】
そのようなプロトコルの１つは、ＲＴＰ(Real Time Protocol)である（例えば、H. Schulzrinne, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889、を参照）。ＲＴＰが注目されているのは、それが、リアルタイムストリームを扱うために利用可能なＩＥＴＦ(Internet Engineering Task Force)プロトコルであるためである。ＲＴＰトラフィックは、ＵＤＰ（ユーザデータグラムプロトコル）、およびＩＰパケットにカプセル化される。
【０００４】
【発明が解決しようとする課題】
残念ながら、ＲＴＰ／ＵＤＰ／ＩＰを使用すると、voice-over-ＩＰアプリケーションがワイヤレスネットワークで実行される際に大きいオーバーヘッドが生じる。音声ペイロードは通常小さい（例えば、１０から２０バイト）が、ＲＴＰ／ＵＤＰ／ＩＰヘッダは４０バイトであるためである。
【０００５】
【課題を解決するための手段】
ＲＴＰ／ＵＤＰ／ＩＰヘッダに伴う大きいオーバーヘッド以外にも、この状況は、ＧＴＰ(General Packet Radio Service Tunneling Protocol)カプセル化パケットを使用することによってさらに悪化する。この場合、ＧＴＰ／ＵＤＰ／ＩＰオーバーヘッドは、１０バイトの音声ペイロードの約９８０％となる。そこで、本発明によれば、ＧＴＰ／ＵＤＰ／ＩＰヘッダは送信のために圧縮される。
【０００６】
本発明の実施例では、ＵＭＴＳコアネットワークは、ＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮（以下、「ＧＴＰヘッダ圧縮」あるいは「圧縮ＧＴＰヘッダ」という）を行う圧縮フレームワークをサポートする。さらに、ＵＭＴＳコアネットワークは、ＧＴＰヘッダ圧縮とは独立に、ＲＴＰ／ＵＤＰ／ＩＰヘッダ圧縮（以下、「ＲＴＰヘッダ圧縮」あるいは「圧縮ＲＴＰヘッダ」という）もサポートする。その結果、ＵＭＴＳコアネットワークは、小さいマルチメディアＲＴＰパケットをより効率的にトランスポートすることが可能となる。
【０００７】
【発明の実施の形態】
当業者に知られている（リリース９７バージョン）非圧縮（圧縮されていない）ＧＴＰカプセル化ＲＴＰパケット１０の例示的フォーマットを図１に示す。ＧＴＰ／ＵＤＰ／ＩＰヘッダ１１は、ＩＰ／ＵＤＰヘッダ１２およびＧＴＰヘッダ１３からなる。ＧＴＰ／ＵＤＰ／ＩＰヘッダ１１は、当業者に知られているように、ＧＴＰペイロード１４の最上位に位置する。例えば１０バイトに等しい音声ペイロード（例えば、図１のペイロード１５）の場合、ＧＴＰ／ＵＤＰ／ＩＰヘッダ１１の結果として、オーバーヘッドは約９８０％となる。そこで、本発明によれば、ＧＴＰ／ＵＤＰ／ＩＰヘッダは送信のために圧縮される。図１からわかるように、ＧＴＰペイロード１４は、ＩＰヘッダおよびＵＤＰヘッダもトランスポートする。当業者に知られているように、ＩＰ／ＵＤＰヘッダ１２は、トンネルに関する発信側および着信側情報を含むが、ＧＴＰペイロード１４のＩＰヘッダおよびＵＤＰヘッダは、通信エンドポイントに関する発信側および着信側情報を含む。（注意すべき点であるが、ＴＩＤ値は、"Global System for Mobile Communications (GSM) 04.08 document, Digital cellular telecommunications system (Phase 2+); mobile radio interface layer 3 - specification"で定義されたリリース９７バージョンに基づいている。ＴＩＤ値は、以下の８バイトを含む：ＭＣＣ １２ビット、ＭＮＣ ８ビット、ＭＳＩＮ ４０ビットおよびＮＳＡＰＩ ４ビット。ＭＣＣ、ＭＮＣ、ＭＳＩＮおよびＮＳＡＰＩは、GSM 04.08 documentで定義されたＩＭＳＩの一部である。）
【０００８】
本発明の原理に従って修正された例示的なＵＭＴＳネットワーク２００を図２に示す。本発明の概念以外は、図２に示した要素は周知であり、詳細に説明しない。例えば、ＵＭＴＳネットワーク２００は、無線アクセスネットワーク（ＲＡＮ：radio access network）、コアネットワーク（ＣＮ：core network）、バックボーンネットワーク、および、ＩＰエンドホスト２４０によって表される例示的なエンドポイントを有する。バックボーンネットワークは、インターネットおよび公衆交換電話網（ＰＳＴＮ）を含む。ＲＡＮは、移動局（ＭＳ）２０５、ノードＢ２１０および無線ネットワークコントローラ（ＲＮＣ：radio network controller）２１５を有する。（ＵＭＴＳは「ノードＢ」(node B)という用語を使用しているが、これは基地局ともいう。）ＣＮは、サービスＧＰＲＳサポートノード（ＳＧＳＮ：serving GPRS support node）２２０、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ：gateway GPRS support node）２２５および要素２３０を有する。要素２３０は、ゲートキーパ（ＧＫ）（ＩＴＵ Ｈ．３２３のコンポーネント）およびＩＰ／ＰＳＴＮゲートウェイ（ＧＷ）（Ｈ．３２３とＰＳＴＮの間の翻訳のため）を有する。図では、ＵＭＴＳネットワーク２００の要素は、単一ブロックの要素として示されているが、蓄積プログラム制御プロセッサ、メモリ、および適当なインタフェースカード（図示せず）を有する。本発明の説明のため、あるエンドツーエンドコネクションがＭＳ２０５とＩＰエンドホスト２４０（これはエンドポイントともいう）の間にあるとする。以下、「パケットサーバ」という用語は、任意のパケットプロセッサを指す。その例は、上記のＵＭＴＳ２００の要素である。
【０００９】
本発明によれば、ＵＭＴＳネットワーク２００は、ＧＴＰヘッダ圧縮を行う圧縮フレームワークをサポートする。さらに、ＵＭＴＳネットワーク２００は、ＧＴＰヘッダ圧縮とは独立に、ＲＴＰヘッダ圧縮もサポートする。（ここで、「ＧＴＰヘッダ圧縮」あるいは「圧縮ＧＴＰヘッダ」という用語は、ＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮を指す。同様に、「ＲＴＰヘッダ圧縮」あるいは「圧縮ＲＴＰヘッダ」という用語は、ＲＴＰ／ＵＤＰ／ＩＰヘッダの圧縮を指す。）ＧＴＰヘッダ圧縮は、ＲＴＰヘッダ圧縮とは独立であるため、ＧＴＰピアは、ＲＴＰピアとは異なることが可能である（しかしこれが要求されるわけではない）。これは、多少の設計の自由度（フレキシビリティ）も提供する。マルチメディアトラフィックには、ＲＴＰを使用せず、純粋にＵＤＰカプセル化を使用するものもあるからである。その結果、ＵＭＴＳネットワーク２００は、小さいマルチメディアパケットをより効率的にトランスポートすることができる。以下で、本発明の概念について説明する。
【００１０】
ヘッダ圧縮の概観
理解されるべき点であるが、本発明によれば、ＲＴＰヘッダ圧縮およびＧＴＰヘッダ圧縮は、ピア間で独立にネゴシエートすることができる（詳細は後述）。本発明の概念以外については、圧縮／伸長技術は周知であり、ここでは説明しない。例えば、通常、圧縮／伸長を行うもの（コンプレッサ(compressor)／デコンプレッサ(decompressor)）は、例えばＭＳ２０５のメモリ（図示せず）に記憶されたソフトウェアモジュールであり、例えばＭＳ２０５の蓄積プログラム制御マイクロプロセッサ（図示せず）によって実行される。このソフトウェアモジュールは、従来のプログラミング技法（したがって、同じくここでは説明しない）を用いて、共有情報を記憶し（後述）、伝送用に圧縮（短縮）された形式のＧＴＰ／ＵＤＰ／ＩＰヘッダあるいはＲＴＰ／ＵＤＰ／ＩＰヘッダを形成（フォーマット）する。
【００１１】
移動局（例えば、図２のＭＳ２０５）に関して、コンプレッサ／デコンプレッサを有する２つの例示的なプロトコルスタックを図３および図４に示す。図３のプロトコルスタックでは、ＲＴＰコンプレッサ／デコンプレッサは、ＩＰ層とＲＬＣ／ＭＡＣ（無線リンク制御／メディアアクセス制御）リンク層との間に位置する。（簡単のため、プロトコルスタックの物理層は図示していない。）図４のプロトコルスタックでは、ＲＴＰコンプレッサ／デコンプレッサは、アプリケーション層とＲＬＣ／ＭＡＣリンク層との間に位置する。（これも、物理層は図示していない。）（ＲＴＰヘッダ圧縮の形式については以下で説明するが、注意すべき点として、図４の実施例は、ＲＴＰヘッダが単に完全に除去されるようなＲＴＰヘッダ圧縮の形式も表している（ＲＴＰヘッダは図１３に例示する）。）
【００１２】
相補的に、対応するＲＴＰコンプレッサ／デコンプレッサおよびＧＴＰコンプレッサ／デコンプレッサが、ＵＭＴＳネットワーク内に配置される。ＵＭＴＳネットワーク２００におけるＲＴＰコンプレッサ／デコンプレッサおよびＧＴＰコンプレッサ／デコンプレッサの配置例を図５に示す。図５において、ＲＴＰコンプレッサ／デコンプレッサ（Ｃ／Ｄ）は、ＭＳ２０５およびＩＰエンドホスト２４０内に配置され（すなわち、ＭＳ２０５とＩＰエンドホスト２４０はＲＴＰピアである）、ＧＴＰコンプレッサ／デコンプレッサ（Ｃ／Ｄ）は、ＲＮＣ２１５およびＧＧＳＮ２２５内に配置される（すなわち、ＲＮＣ２１５とＧＧＳＮ２２５はＧＴＰピアである）。
【００１３】
ＲＴＰは、ポイントツーポイントプロトコルである。したがって、ＲＴＰヘッダ圧縮ピアにとって注意すべき点であるが、このことは、リンク層識別子（ＩＤ）が各ＲＴＰセッション識別子にマップされると仮定している。本発明の実施例のＲＴＰセッション識別子は、ＩＰ終点（宛先、デスティネーション）アドレスおよびＩＰ終点ポート番号（これらはエンドポイントのものである）、ＳＳＲＣ識別子（例えば、図１３を参照）、ならびに、ＵＤＰ終点ポート（例えば、図１２を参照）を含む。ＡＴＭ（非同期転送モード）がトランスポートとして使用される場合、例示的なリンク層ＩＤは、対応するＶＰＩ／ＶＣＩ（仮想パス識別子／仮想コネクション識別子）である。リンク層ＩＤとＲＴＰセッションのマッピングは、各ＲＴＰピア内で行われる。
【００１４】
また、注意すべき点であるが、ＲＴＰコンプレッサ／デコンプレッサは、別法として、無線アクセスネットワーク内に（例えば、ＲＮＣ２１５内に）、あるいは、コアネットワーク内に（例えば、ＳＧＳＮ２２０に）置くことも可能である。
【００１５】
コアネットワーク内では、ＧＧＳＮ２２５にＧＴＰコンプレッサ／デコンプレッサを置くことが（要求されるわけではないが）好ましい。ＧＴＰコンプレッサ／デコンプレッサがＳＧＳＮ２２０に配置される場合、ＳＲＮＳ（サービス無線ネットワークサブシステム：Serving Radio Network Subsystem）再配置によるハンドオーバ（「ハンドオフ」ともいう）も考慮しなければならないことがあるからである。（ＵＭＴＳで知られているように、ＳＲＮＳは、特定のＲＡＮだけでなく、サポート要素（例えばデータベース（図示せず））をも含む。）しかし、ＧＴＰコンプレッサ／デコンプレッサがＧＧＳＮ２２５に配置される場合、ＳＲＮＳ再配置の場合でもコンテクスト転送は不要である。
【００１６】
次に、図６〜図１０に、ＵＭＴＳネットワーク２００でＧＴＰヘッダ圧縮およびＲＴＰヘッダ圧縮を使用するための例示的なメッセージフローを示す。本発明の概念以外は、以下の説明では周知のＵＭＴＳメッセージフローを利用し、これについては説明しない。図６〜図１０では、ＧＴＰヘッダピアはＲＮＣ２１５とＧＧＳＮ２２５であり、ＲＴＰヘッダピアはＭＳ２０５とＩＰエンドホスト２４０であると仮定する。
【００１７】
図６に、図２および図５の移動局（例えば、ＭＳ２０５）が、どのようにしてＧＴＰヘッダ圧縮／伸長をネゴシエートするかを示す。"Attach Procedures"がＭＳ２０５とＲＮＣ２１５の間で実行（当業者に知られているように）された後、ＭＳ２０５は、本発明に従って、あらかじめ定義された識別子"GTP_Comp"によって表されるＧＴＰヘッダ圧縮要求を含むように修正された"Activate PDP context" request（ＰＤＰ(packet data protocol)コンテクスト起動要求）メッセージをＳＧＳＮ２２０へ送信する。これに応答して、ＳＧＳＮ２２０は、ＧＴＰヘッダ圧縮に対する要求を意味する"Create PDP context" request（ＰＤＰコンテクスト作成要求）メッセージ（"GTP_Comp"識別子を含むように修正したもの）をＧＧＳＮ２２５へ送る。ＧＧＳＮ２２５は、確認応答(acknowledgment)として、"Create PDP context" response（ＰＤＰコンテクスト作成応答）メッセージ（"GTP_Comp"識別子を含むように修正したもの）で応答する。ＳＧＳＮ２２０は、この"Create PDP context" responseメッセージを受信すると、"Activate PDP context" response（ＰＤＰコンテクスト起動応答）メッセージ（"GTP_Comp"識別子を含むように修正したもの）をＭＳ２０５に送る。
【００１８】
上記のように、ＧＴＰヘッダ圧縮コンテクストを設定するためには、GTP_Compressed（ＧＴＰ圧縮）フラグ（例えば、あらかじめ定義されたビットパターン）またはGTP Header Compression_Context IE（ＧＴＰヘッダ圧縮コンテクスト情報エレメント（ＩＥ：information element））を、従来のメッセージセットに追加する。このGTP Header Compression_Context IEは、ＧＴＰの完全なヘッダ情報を含むことになる。このエレメントが存在する場合、ＧＴＰヘッダコンテクストを設定するために完全なＧＴＰヘッダを送る必要はない。そうでない場合、ＧＴＰヘッダコンテクストを設定するために、完全なＧＴＰヘッダとともに１個以上のパケットを送信する必要が生じる場合がある。（注意すべき点であるが、ＧＴＰコンプレッサ／デコンプレッサがＳＧＳＮに配置され、ＳＲＮＳ再配置の結果ＳＧＳＮの変更が生じる場合、新ＳＧＳＮは旧ＳＧＳＮにＧＴＰコンテクスト問合せメッセージを送り、旧ＳＧＳＮが適当なＧＴＰコンテクスト応答メッセージで応答することにより、新ＳＧＳＮがＧＴＰヘッダ圧縮のための新たなコンプレッサ／デコンプレッサポイントとなることができる。
【００１９】
次に、図７に、例示的なパケットフローを示す。ＧＴＰヘッダ圧縮の場合、ＧＴＰピア（ここでは、ＲＮＣ２１５とＧＧＳＮ２２５によって表される）間でＧＴＰ圧縮ヘッダコンテクストを確立する（図７、（Ａ））ために、完全なＧＴＰヘッダを有する少なくとも１つのパケットを送信する。前述のように、パケットは、ＧＧＳＮ２２５とＲＮＣ２１５の間でＧＴＰを用いて通信される（すなわち、ＧＴＰは、ＧＧＳＮ２２５およびＲＮＣ２１５で終端する）。ＧＴＰヘッダ圧縮がネゴシエートされた後、各ＧＴＰピア（例えば、ＧＧＳＮ２２５）は、ＧＴＰに従ってパケットをフォーマットしてから、そのＧＴＰピア（ここではＲＮＣ２１５）へパケットを送信する前にＧＴＰヘッダを圧縮し（後述）、このＧＴＰピアは、ＧＴＰヘッダを圧縮解除して、ＭＳ２０５へ送信するためにペイロード（これは、ＲＴＰを含むことも含まないこともある）を回復する。同様に、逆向きには、ＲＮＣ２１５は、ＧＧＳＮ２２５へ送信するためにＧＴＰヘッダを圧縮し、ＧＧＳＮ２２５は、ＧＴＰヘッダを圧縮解除して、ペイロードを回復する。パケットは、当業者に知られているように、リンク層で、ＧＧＳＮ２２５とＩＰエンドホスト２４０の間で通信される。ＧＴＰヘッダ圧縮ネゴシエーションに続き、オプションとして、図６のＧＴＰヘッダ圧縮ネゴシエーションの場合に示したのと同様にして、ＲＴＰヘッダ圧縮を、ＭＳ２０５とＩＰエンドホスト２４０の間でネゴシエートすることも可能である（図７、（Ｂ））。
【００２０】
ＲＴＰヘッダ圧縮コンテクストメッセージ交換の例を図８に示す。（この場合も、従来のシグナリングメッセージの修正を仮定する。したがって、追加のメッセージ要件、例えば、これが"RTP context set up"（ＲＴＰコンテクスト設定）メッセージであることを識別するために、あらかじめ定義されたビット値が追加される。）最初に、２つのＲＴＰピアは、ＲＴＰヘッダ圧縮コンテクストを設定するためにシグナリングメッセージを交換する。"RTP context set up" request（ＲＴＰコンテクスト設定要求）メッセージが、一方のＲＴＰピア（例えば、ＭＳ２０５）から、他方のＲＴＰピア（例えば、ＩＰエンドホスト２４０）に送られる。"RTP context set up" response（ＲＴＰコンテクスト設定応答）メッセージが、ハンドシェイクを完了する。ＲＴＰコンテクストに変更がある場合、ＲＴＰ圧縮ヘッダ内で運ばれる追加変更（差分、デルタ）情報を示すために、適当なコンテクスト更新コードが圧縮ＲＴＰヘッダ（後述）の第１バイトに用いられる。このように、"RTP context update" request（ＲＴＰコンテクスト更新要求）メッセージは、ＲＴＰ圧縮ヘッダ内のインプリシット（暗黙的）なメッセージである。しかし、"RTP context update" response（ＲＴＰコンテクスト更新応答）メッセージは、オプションである。（注意すべき点であるが、２つのＲＴＰピア（ここでは、ＭＳ２０５およびＩＰエンドホスト２４０によって表される）の間のＲＴＰヘッダ圧縮は、帯域外シグナリングメッセージを交換してＲＴＰヘッダ圧縮を開始することも可能である。この場合も、ＧＴＰヘッダ圧縮とＲＴＰヘッダ圧縮は互いに独立であるため、必ずしもＲＴＰヘッダ圧縮をネゴシエートする必要はない（その場合、パケットは、圧縮ＧＴＰヘッダおよび非圧縮ＲＴＰペイロードからなる）。同様に、ＲＴＰヘッダ圧縮を使用するかどうかにかかわらず、必ずしもＧＴＰヘッダ圧縮をネゴシエートする必要はない。）
【００２１】
図７に戻り、ＲＴＰヘッダ圧縮コンテクストが設定された後、ＧＴＰヘッダ圧縮およびＲＴＰヘッダ圧縮を用いて、後続のパケットが送信される（図７、（Ｃ））（上記のように、ＧＴＰヘッダ圧縮およびＲＴＰヘッダ圧縮が両方とも開始されると仮定する）。ＲＴＰコンテクスト再同期が要求される場合、受信側ＲＴＰピアは、"RTP context repair"（ＲＴＰコンテクスト修復）メッセージを送信側ＲＴＰピアへ送ることができる。これを、図９、（Ｄ）に示す。ここで、受信側ＲＴＰピアはＩＰエンドホスト２４０によって表され、送信側ＲＴＰピアは、ＭＳ２０５によって表される。その後、送信側ＲＴＰピアは、完全なヘッダを有する１個以上のＲＴＰパケットを送信（図９（Ｅ））した後、圧縮ＲＴＰパケットを送信する（図９（Ｆ））。
【００２２】
同様に、ＧＴＰパケットが損失した場合、受信側ＧＴＰピアは、"GTP context repair"（ＧＴＰコンテクスト修復）メッセージを送信側ＧＴＰピアへ送ることができる。これを図１０、（Ｇ）に示す。ここで、受信側ＧＴＰピアはＧＧＳＮ２２５によって表され、送信側ＧＴＰピアはＲＮＣ２１５によって表される。その後、送信側ＧＴＰピアは、完全なＧＴＰヘッダを有する１個以上のパケットを送信（図１０、（Ｈ））した後、圧縮ＧＴＰヘッダを有するパケットを送信する（図１０、（Ｉ））。（理解されるように、この例では、ＲＴＰヘッダ圧縮同期は喪失していない。）
【００２３】
ＧＴＰヘッダ圧縮あるいはＲＴＰヘッダ圧縮のいずれに対する上記のコンテクスト修復メカニズムも、損失パケットがあれば実行される。注意すべき点であるが、再同期のために明示的なコンテクスト修復メッセージが一定期間後に送信側へ送られるように、あらかじめ定義された期間しきい値を設定することも可能である。）
【００２４】
いずれかのＧＴＰピアがＧＴＰコンテクストを破棄したい場合、ＧＴＰコンテクスト破棄メッセージ（図示せず）を送信することができる。同様に、ＲＴＰピアは、ＲＴＰコンテクスト破棄メッセージ（図示せず）の送信により、ＲＴＰコンテクストを破棄することができる。
【００２５】
ＲＴＰヘッダ圧縮
ＵＭＴＳ環境に直接に適用可能ではないが、４０バイトのＲＴＰ／ＵＤＰ／ＩＰヘッダを４〜５バイトに短縮する従来のいくつかの提案がある（例えば、
・S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", IETF RFC2508
・L. Jonsson, M. Degermark, H. Hannu and K. Svanbro, "Robust Checksum-based Header Compression", IETF internet draft, Oct 1999を参照）。そこで、図１１〜図１３に、従来のＩＰ、ＲＴＰおよびＵＤＰのヘッダフォーマットを参考のために示すが、これらについて詳細にはここでは説明しない。
【００２６】
一般に、ＩＰヘッダに関しては（現在使用されているＩＰバージョンであるＩＰｖ４の使用を仮定する）、通常、全長（パケット長、total length）、パケットＩＤ（識別）およびヘッダチェックサムフィールドのみが変化する。しかし、全長は、リンク層によっても提供されるため、冗長である。パケットＩＤは通常、各パケットごとに１または小さい数だけインクリメントされる。仮にＩＰパケット断片化がないとすると、このフィールドも通信する必要がなくなる。しかし、無損失圧縮を維持するために、パケットＩＤの変化を送信することも可能である。
【００２７】
ＵＤＰヘッダに関しては、ＩＰ全長フィールドと、長さがリンク層によって示されることのため、長さフィールドは冗長である。始点（送信元、ソース）がＵＤＰチェックサムを生成しないことを選択した場合、ＵＤＰチェックサムフィールドは常に０となる。そうでない場合、無損失圧縮を保持するために、ＵＤＰチェックサムはもとのまま通信されなければならないことを発明者は認識した。
【００２８】
ＲＴＰヘッダに関しては、与えられたコンテクストにおいて、ＳＳＲＣ（同期始点：synchronization source）識別子は一定である。これは、特定のコンテクストを識別するものの一部であるからである。ほとんどのパケットの場合、シーケンス番号およびタイムスタンプのみがパケットごとに変化する。パケットがコンプレッサの上流で損失または順序誤りを生じない場合、シーケンス番号は各パケットごとに１だけインクリメントされることになる。一定期間のオーディオパケットの場合、タイムスタンプは、各パケットで運ばれるサンプル周期の数だけインクリメントされる。ビデオの場合、タイムスタンプは、各フレームの最初のパケットで変化するが、フレーム内の後続のパケットでは一定のままである。各ビデオフレームが１パケットのみを占めるが、ビデオフレームは一定レートで生成される場合も、フレームからフレームへのタイムスタンプ変化は一定である。注意すべき点であるが、これらの各場合で、シーケンス番号およびタイムスタンプフィールドの２次差分は０であるため、次のパケットヘッダは、前の非圧縮ヘッダとともにセッションコンテクストに記憶されているこれらのフィールドに対する１次差分を加えることによって、前のパケットヘッダから構成することができる。２次差分が０でない場合、変化量は通常、フィールド内の全ビット数よりもずっと小さいため、絶対値ではなく新たな１次差分を符号化し送信することによって、サイズを縮小することができる。
【００２９】
オーディオ有音部(talkspurt)の最初のパケットおよびビデオフレームの最後のパケットではＭビットがセットされる。仮にこれを、変化ごとに完全なＲＴＰヘッダの送信を要求するような定数フィールドとして扱うと、ヘッダ圧縮の効率が大幅に低下する。従って、以下でさらに詳細に説明するように、ＲＴＰ圧縮ヘッダはＭビットを明示的に運ぶことにする。
【００３０】
パケットがＲＴＰミキサを通る場合（オーディオではほとんどの場合そうである）、ＣＳＲＣリストおよびＣＣカウントも変化する。しかし、ＣＳＲＣリストは通常、有音部以上の期間で一定であるため、変化したときにのみ送信すればよい。
【００３１】
ＲＴＰヘッダ圧縮プロトコルの一部として使用するための、圧縮ＲＴＰヘッダの例示的なフォーマットを図１４に示す。上記のように、ＲＴＰピアは圧縮ＲＴＰヘッダを送信し、ある共有情報の集まり（例えば、コンプレッサとデコンプレッサの間で一貫した状態でメモリ（図示せず）に記憶される）を維持すると仮定する。圧縮ＲＴＰヘッダは、以下のフィールドを有する。
・コンテクスト更新コード（１バイト）
・ＲＴＰ Ｍビットに対するＭフィールド（１ビット）
・タイムクリックフィールド（７ビット）
・ＵＤＰチェックサムフィールド（２バイト）
・ＩＰパケットＩＤ（２バイト）
・ＣＳＲＣリスト（２バイト）
・ＲＴＰヘッダ拡張（２バイト）
【００３２】
コンテクスト更新フィールドの値は、どのような情報が図１４に示すＲＴＰ圧縮ヘッダに含まれるかを示す。ＲＴＰ圧縮ヘッダの最小の長さは２バイトである。ＲＴＰタイムスタンプは、タイムクリック番号（１バイト）で置換される。ＵＤＰチェックサム、ＩＰｖ４パケットＩＤ、ＣＳＲＣリストおよびＲＴＰヘッダ拡張を含める必要がある場合、圧縮ＲＴＰヘッダは図１４に示すよりも長くなる。しかし、ほとんどの場合、圧縮ＲＴＰヘッダは２バイトのみ（コンテクスト更新コードバイトと、Ｍ＋タイムクリックバイト）となる。
【００３３】
各ＲＴＰピアに記憶される共有情報に関しては、ＩＰ始点および終点アドレス、ＵＤＰ始点および終点アドレス、ならびにＲＴＰ ＳＳＲＣフィールド（前述）の特定の組合せによって定義される、各ＩＰ／ＵＤＰ／ＲＴＰパケットストリームごとに個別のセッションコンテクストがある。維持されるセッションコンテクストの数は、コンプレッサとデコンプレッサの間でネゴシエートすることが可能である。各ＲＴＰコンテクストを、ＧＴＰ ＴＩＤ（ＧＴＰトンネルＩＤ）にマップすることが可能である（ネゴシエート可能な最大数は６５５３６である）。各ＲＴＰヘッダ圧縮コンテクストは、固有の別個のシーケンス番号空間を有し、単一のパケット損失が１つのコンテクストしか無効にする必要がないようにしている。
【００３４】
各ＲＴＰヘッダ圧縮コンテクストにおける共有情報は、以下の項目を有する。
・完全なＩＰ、ＵＤＰおよびＲＴＰヘッダ。おそらくは、コンプレッサにより送信された、または、デコンプレッサにより再構築された最終パケットに対するＣＳＲＣリストを含む。
・ＩＰｖ４ ＩＤフィールドに対する１次差分。このコンテクストに対する非圧縮ＩＰヘッダが受信されると１に初期化され、デルタＩＰｖ４ＩＤフィールドが圧縮パケットで受信されるごとに更新される。
【００３５】
上記のように、また、図１４に示すように、圧縮ＲＴＰヘッダには、ＲＴＰヘッダ（例えば、図１３を参照）のＲＴＰタイムスタンプフィールドを置き換えるタイムクリックフィールドがある。そこで、ＲＴＰ受信側ピアにおいて、タイムクリックフィールド値からタイムスタンプ値およびシーケンス番号を計算（すなわち、回復）するメカニズムが必要である。このため、以下の定義をする。
ｓｄ：サンプル期間（単位：ｍｓ）
ＴＳold：前のパケットのタイムスタンプ番号
ＴＳnew：このパケットのタイムスタンプ番号
ＷＴold：前のパケットのウォールクロックの読み（ウォールクロック（壁掛け時計）とは、単に、ネットワーク基準クロックのことである）
ＷＴnew：このパケットのウォールクロックの読み
ＴＮold：圧縮ヘッダにおける前のパケットのタイムクリック番号
ＴＮnew：圧縮ヘッダにおけるこのパケットのタイムクリック番号
ＳＮold：前のパケットのＲＴＰシーケンス番号
ＳＮnew：このパケットのＲＴＰシーケンス番号
Ｔ：サンプル期間を単位として、ｎビットを用いて表される期間（１サイクル周期）。Ｔ＝２nサンプル（Ｔ＝２n（ｓｄ）ミリ秒（ｍｓ））
Ｍ：圧縮ヘッダにおけるＭビットの値
【００３６】
以下の式を用いて、ＲＴＰ受信側ピアにおいて、タイムクリックフィールド値からタイムスタンプ値およびシーケンス番号を計算（すなわち、回復）する。
【数１】
Figure 0004602568
【００３７】
有音期間中、タイムクリックフィールド値は１サンプルだけ増大する。無音期間中、タイムクリックフィールド値は、アイドル期間分（サンプル数で表される）だけ増大する。
【００３８】
タイムスタンプフィールドについて、解決すべき主要な問題は、７ビットタイムクリック番号がラップアラウンドした場合にどうするかである。無音期間中に、コンプレッサにより送信されるパケットがない場合、その無音期間の時間経過を（何個のクロックサイクルが経過したかに関して）検出しなければならない。例えば、この問題を解決するために、当業者に知られているウォールクロック（上記のように、例えば、ＷＴoldおよびＷＴnew）が用いられる。デコンプレッサにおけるこの別個のウォールクロックが、サイクルをカウントするために使用される。このウォールクロックは、粗い粒度（刻み、グラニュラリティ）で進行する（例えば、Ｔ／４の期間ごとに１だけ増大する。ただし、Ｔは、７ビットを用いて表される１サイクルの期間である）。
【００３９】
ＲＴＰシーケンス番号フィールドに関して、順序づけ（シーケンシング）が必要な場合、シーケンス番号を有する圧縮ヘッダが、Ｔ／４サンプルごとに、有音部の開始時に含められるべきである。必要であれば、完全なＲＴＰヘッダを要求するために、コンテクスト修復メッセージを送信することができる。タイムクリック値がＴ／４を超え、しかも、損失パケットがある場合には、ＲＴＰ受信側がシーケンス番号情報を有するパケットを得るまで、ＲＴＰシーケンス番号を適切に更新することができない。
【００４０】
タイムスタンプおよびシーケンス番号の回復を行うためにこの更新アルゴリズムがどのように動作するかを以下で例示する。連続するシーケンス番号１〜１８を有する１８個のパケットが、例えばＭＳ２０５から送信されると仮定する。ＲＴＰ受信側（例えば、ＩＰエンドホスト２４０）では、パケット１８のみが受信される（パケット７〜１７が失われる）とする。
【００４１】
第１の例として、シーケンス番号６のパケットが受信されるときのウォールクロック値が３（３（Ｔ／４）を意味する）であり、ＴＳold＝１１０であると仮定する。パケット１８が受信されるとき、ウォールクロック値は６である。パケット６および１８の受信時のタイムクリック値はそれぞれ１１０および７５である。上記の式を用いると、以下の計算結果が得られる。
【数２】
Figure 0004602568
【００４２】
次の第２の例では、ＴＳold＝３８であり、パケット６に対するウォールクロック値は５であり、パケット１８に対するウォールクロック値は９であると仮定する。パケット６および１８の受信時のタイムクリック値はそれぞれ３８および３２である。
【数３】
Figure 0004602568
【００４３】
次の第３の例では、ＴＳold＝５７であり、パケット６に対するウォールクロック値は６であり、パケット１８に対するウォールクロック値は９であると仮定する。パケット６および１８の受信時のタイムクリック値はそれぞれ５７および２８である。
【数４】
Figure 0004602568
【００４４】
ＧＴＰヘッダ圧縮
図１５に、圧縮ＧＴＰヘッダの例示的フォーマットを示す。圧縮ＧＴＰヘッダは、バージョンフィールド（Vers、３ビット）、ペイロードタイプフィールド（ＰＴ、１ビット）、拡張ビットフィールド（Ｅ、１ビット）、シーケンス番号フィールド（Ｓ、１ビット）、トンネル識別子（ＴＩＤ）存在フィールド（Ｔ、１ビット）、ＳＮＤＣＰ存在フィールド（Ｎ、１ビット）、メッセージタイプフィールド（Msg TYPE、１バイト）、２バイトの長さ（ヘッダ長、LENGTH）フィールド、２または４バイトのトンネル識別子（ＴＩＤ）フィールド、２バイトのシーケンス番号フィールド、４ビットの拡張コードフィールド、４ビットの拡張長さフィールド、および拡張内容フィールドからなる。
【００４５】
ＴＩＤフィールドに関して、最上位ビットは、ＴＩＤフィールドのサイズを示すために使用される。最上位ビットの値が０の場合、ＴＩＤフィールドサイズは２バイトである。このビットの値が１の場合、ＴＩＤフィールドサイズは４バイトである。さらに、ＴＩＤフィールドは、Ｔビットフィールドの値がセットされている場合、すなわち、２進数１に等しい場合にのみ存在する。Ｅビットフィールドは、拡張ヘッダが存在するかどうかを示すために使用される。それぞれの拡張ヘッダは、４ビットの拡張ヘッダタイプ(EXT. TYPE)フィールド、４ビットの拡張ヘッダ長(EXT. LENGTH)フィールド、および拡張内容(EXT. CONTENT)フィールド（そのサイズは、拡張ヘッダ長フィールドの値によって示される）からなる。拡張ヘッダ長フィールドの値は、２バイトの倍数で表される。例えば、ＵＤＰチェックサムが存在する必要がある場合、適当な拡張ヘッダタイプがこれに対して定義され、拡張ヘッダ長は１である（これは、ＵＤＰチェックサムの長さが２バイトであるため、拡張内容フィールドのサイズが２バイトであることを意味する）。
【００４６】
拡張ヘッダタイプフィールドの幅は４ビットであるため、１６個の拡張タイプを定義することができる。拡張ヘッダ長フィールドの幅は４ビットであるため、拡張内容フィールドの最大サイズは３２バイト（すなわち、２バイトの１６倍）である。注意すべき点であるが、さらに多くの拡張タイプを割り当てる必要がある場合、これらのフィールドのサイズを調整（例えば、それぞれのサイズを１バイトに）することも可能である。
【００４７】
各ＧＴＰヘッダ圧縮コンテクスト内の（すなわち、各ＧＴＰピアに記憶された）共有情報は、以下の項目を含む（これらの項目は、最初の「完全な」ＧＴＰヘッダで受信される値に基づいて初期化される）。
・完全なＩＰおよびＵＤＰヘッダ（この場合も、ＵＤＰチェックサムが必要な場合、受信側ＧＴＰピアは単に、受信ＵＤＰデータに基づいてそれを再計算する）。
・２バイトのフローラベルおよびＬＬＣフレーム番号。
・ＴＩＤ値。
【００４８】
上記のように、図１５に示すＧＴＰヘッダ圧縮フォーマットは、２または４バイトの選択的なＴＩＤ値をサポートする。（上記のように、ＴＩＤの９７リリースバージョンは８バイトである。しかし、ＴＩＤ値は、さらに少ないバイト数からなるように将来再定義される可能性がある（そのため、圧縮ＧＴＰヘッダにおいては、ＴＩＤ値を２または４バイトのいずれかにする選択肢がある）。図１５のＧＴＰヘッダ圧縮フォーマットにおけるＴＩＤフィールドは、ＴＩＤ情報を更新するために（Ｔビットの値を通じて）オプションとして使用される。
【００４９】
次に、図１６に、本発明の原理に従って使用される代表的なパケットサーバの高水準ブロック図を示す。パケットサーバ６０５は、蓄積プログラム制御方式のプロセッサアーキテクチャであり、プロセッサ６５０、メモリ６６０（例えば、上記のＧＴＰヘッダ圧縮などに従って通信するためのプログラム命令およびデータを記憶するためのもの）、および、パス６６６によって表される１つまたは複数のパケット通信ファシリティに接続するための通信インタフェース６６５を有する。
【００５０】
以上は本発明の原理の単なる例示であり、理解されるように、当業者であれば、ここに明示していなくても、本発明の技術的範囲内で、本発明の原理を実現するさまざまな代替実施例を考えることが可能である。例えば、ここではＵＭＴＳの場合を例示したが、本発明の概念は、トンネリングプロトコルの使用を必要とする任意のワイヤレス方式（例えば、ＵＭＴＳなど）あるいはアプリケーションに適用可能である。
【００５１】
【発明の効果】
以上述べたごとく、本発明によれば、ＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮により、ＵＭＴＳコアネットワークにおいて、小さいマルチメディアＲＴＰパケットをより効率的にトランスポートすることが可能となる。
【図面の簡単な説明】
【図１】従来の圧縮されていないＧＴＰカプセルかＲＴＰパケットを示す図である。
【図２】本発明の原理を実現するＵＭＴＳネットワークを示す図である。
【図３】移動局で用いられる例示的なプロトコルスタックを示す図である。
【図４】移動局で用いられる例示的なプロトコルスタックを示す図である。
【図５】図２のＵＭＴＳネットワークにおける例示的なコンプレッサ／デコンプレッサ配置を示す図である。
【図６】例示的なメッセージフローを示す図である。
【図７】例示的なメッセージフローを示す図である。
【図８】例示的なメッセージフローを示す図である。
【図９】例示的なメッセージフローを示す図である。
【図１０】例示的なメッセージフローを示す図である。
【図１１】従来のＩＰヘッダフォーマットを示す図である。
【図１２】従来のＵＤＰヘッダフォーマットを示す図である。
【図１３】従来のＲＴＰヘッダフォーマットを示す図である。
【図１４】圧縮ＲＴＰヘッダの例示的フォーマットを示す図である。
【図１５】圧縮ＧＴＰヘッダの例示的フォーマットを示す図である。
【図１６】本発明の原理に従ってＧＴＰヘッダ圧縮を実行する際に用いられるパケットサーバの例示的な高水準ブロック図である。
【符号の説明】
１０ 非圧縮ＧＴＰカプセル化ＲＴＰパケット
１１ ＧＴＰ／ＵＤＰ／ＩＰヘッダ
１２ ＩＰ／ＵＤＰヘッダ
１３ ＧＴＰヘッダ
１４ ＧＴＰペイロード
１５ ペイロード
２０ バイトＩＰヘッダ
２００ ＵＭＴＳネットワーク
２０５ 移動局（ＭＳ）
２１０ ノードＢ
２１５ 無線ネットワークコントローラ（ＲＮＣ）
２２０ サービスＧＰＲＳサポートノード（ＳＧＳＮ）
２２５ ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）
２４０ ＩＰエンドホスト
６０５ パケットサーバ
６５０ プロセッサ
６６０ メモリ
６６５ 通信インタフェース

Claims (3)

  1. パケットサーバで用いられる方法であって、
    ＧＰＲＳ（General Packet Radio Service）に基づくトンネリングプロトコル（ＧＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル（ＩＰ）のヘッダ情報を含むＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮をＧＴＰピアとネゴシエートするステップを備え、該ネゴシエートするステップが、
    まずＧＴＰピアへＧＴＰ／ＵＤＰ／ＩＰヘッダを送信するステップ、及び
    次に圧縮ＧＴＰ／ＵＤＰ／ＩＰヘッダをＧＴＰピアへ送信するステップ
    を含み、
    圧縮ＧＴＰ／ＵＤＰ／ＩＰヘッダが少なくとも、拡張フィールドの有無を示す拡張ビットフィールド、及びトンネル識別子フィールドの有無を示すトンネル識別子存在フィールドを含む、方法。
  2. 請求項１の方法において、圧縮ＧＴＰ／ＵＤＰ／ＩＰヘッダが長さ４バイト以下のトンネル識別子フィールドを少なくとも含む方法。
  3. 請求項１の方法であって、さらに、
    ＵＤＰおよびＩＰのヘッダ情報を有するＲＴＰ（Real Time Protocol）に従ってデータパケットをフォーマットするステップ、及び
    パケットを送信する前にＲＴＰ／ＵＤＰ／ＩＰヘッダを圧縮するステップであって、
    圧縮ＲＴＰ／ＵＤＰ／ＩＰヘッダの１つのフィールドがＵＤＰチェックサムフィールドの有無を定義している、ステップ
    からなる方法。
JP2001014224A 2000-02-02 2001-01-23 パケットサーバで用いられる通信方法 Expired - Fee Related JP4602568B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/497,002 US6839339B1 (en) 2000-02-02 2000-02-02 Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets
US09/497002 2000-02-02

Publications (3)

Publication Number Publication Date
JP2001244993A JP2001244993A (ja) 2001-09-07
JP2001244993A5 JP2001244993A5 (ja) 2008-02-14
JP4602568B2 true JP4602568B2 (ja) 2010-12-22

Family

ID=23975057

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001014224A Expired - Fee Related JP4602568B2 (ja) 2000-02-02 2001-01-23 パケットサーバで用いられる通信方法

Country Status (5)

Country Link
US (1) US6839339B1 (ja)
EP (1) EP1122925B1 (ja)
JP (1) JP4602568B2 (ja)
CA (1) CA2329457C (ja)
DE (1) DE60007829T2 (ja)

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU4373799A (en) * 1999-06-04 2000-12-28 Nokia Corporation Packet data transmission control
EP1083768A1 (en) * 1999-09-08 2001-03-14 TELEFONAKTIEBOLAGET LM ERICSSON (publ) A method for facilitating data transmission
US8117291B1 (en) * 1999-11-02 2012-02-14 Wireless Technology Solutions Llc Use of internet web technology to register wireless access customers
US6865169B1 (en) 1999-11-02 2005-03-08 Ipwireless, Inc. Cellular wireless internet access system using spread spectrum and internet protocol
US8463231B1 (en) 1999-11-02 2013-06-11 Nvidia Corporation Use of radius in UMTS to perform accounting functions
US7158491B1 (en) * 1999-11-05 2007-01-02 Nokia Corporation Terminal-based link adaptation scheme having a detector which monitors application signaling and a requestor which requests a special channel based on the detection
US6678281B1 (en) * 2000-03-08 2004-01-13 Lucent Technologies Inc. Hardware configuration, support node and method for implementing general packet radio services over GSM
US7539130B2 (en) * 2000-03-28 2009-05-26 Nokia Corporation Method and system for transmitting and receiving packets
CA2408993C (en) * 2000-05-16 2008-01-08 Siemens Aktiengesellschaft Method for transferring a tunnel between nodes in a gprs system
WO2001093540A1 (en) * 2000-05-31 2001-12-06 Nokia Corporation Method and apparatus for generating a connection identification
FI112014B (fi) 2000-06-28 2003-10-15 Nokia Corp Tiedonsiirtoresurssien varaus pakettivälitteisessä tiedonsiirrossa
FI20001544A (fi) * 2000-06-29 2001-12-30 Nokia Networks Oy Poikkeavan päätelaitteen tukeminen verkossa
JP3936290B2 (ja) 2000-08-14 2007-06-27 ノキア コーポレイション モード選択手順を備えた通信システム及びその方法
DE60018927T2 (de) * 2000-09-07 2005-07-28 Matsushita Electric Industrial Co. Ltd., Kadoma Verfahren und Vorrichtung zur Datenpaketenübertragung
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 松下電器産業株式会社 パケット送信装置およびパケット伝送方法
US20020101859A1 (en) * 2000-09-12 2002-08-01 Maclean Ian B. Communicating between nodes in different wireless networks
EP1696672B1 (en) * 2000-09-28 2010-06-30 Nokia Corporation Method and compressor for compressing packet timestamp information
US6967964B1 (en) * 2000-10-03 2005-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Context identification using header compression key at link layer
FI110739B (fi) * 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
US7095744B2 (en) * 2000-11-22 2006-08-22 Dune Networks Method and system for switching variable sized packets
FI20002890A (fi) * 2000-12-29 2002-06-30 Nokia Corp Kompression määrittäminen pakettivälitteisessä tiedonsiirrossa
US7290063B2 (en) * 2001-01-10 2007-10-30 Nokia Corporation Relocating context information in header compression
WO2002069519A1 (en) * 2001-02-23 2002-09-06 Nokia Inc. System and method for fast gprs for ipv6 communications
US7155173B2 (en) * 2001-03-14 2006-12-26 Nokia Corporation Method and system for providing a context for message compression
FI118244B (fi) 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
CA2354722C (en) * 2001-08-01 2015-11-24 Certicom Corp. Disabling header compression over point-to-point protocol (ppp)
US8837471B2 (en) * 2001-08-01 2014-09-16 Certicom Corp. Disabling header compression over point-to-point protocol (PPP)
US20030051005A1 (en) * 2001-09-13 2003-03-13 Burch Charles Carroll Apparatus for encapsulating data within a self-defining file and method thereof
JP3617967B2 (ja) 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
US7155521B2 (en) 2001-10-09 2006-12-26 Nokia Corporation Starting a session in a synchronization system
US7336952B2 (en) * 2001-10-24 2008-02-26 Qualcomm, Incorporated Method and system for hard handoff in a broadcast communication system
KR100447060B1 (ko) * 2001-12-26 2004-09-04 유티스타콤코리아 유한회사 일반 패킷 무선 서비스 사용자 평면 터널링 프로토콜계층에서의 사용자 패킷 처리 장치 및 그 방법
US20030134651A1 (en) 2002-01-16 2003-07-17 Hsu Raymond T. Method and apparatus for flow treatment and mapping on multicast/broadcast services
TW588524B (en) * 2002-01-23 2004-05-21 Ind Tech Res Inst System and method to apply multi-protocol label switching network in GPRS
US8959230B2 (en) 2002-01-28 2015-02-17 Qualcomm Incorporated Method and apparatus for negotiation of transmission parameters for broadcast/multicast services
AU2002328809A1 (en) * 2002-06-07 2003-12-22 Siemens Aktiengesellschaft Method and device for transmitting ip packets between a radio network controller (rnc) and another element of a mobile radio network
KR100497357B1 (ko) * 2002-06-26 2005-06-23 삼성전자주식회사 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법
US7209491B2 (en) * 2002-06-28 2007-04-24 Nokia Corporation Method and system for transmitting data in a packet based communication network
US7920590B2 (en) * 2002-07-12 2011-04-05 Spyder Navigations L.L.C. Wireless communications system having built-in packet data compression and support for enabling non-standard features between network elements
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
KR100889864B1 (ko) * 2002-08-14 2009-03-24 엘지전자 주식회사 멀티미디어 데이터의 압축 전송 방법 및 시스템
KR100936586B1 (ko) 2002-09-19 2010-01-13 엘지전자 주식회사 멀티미디어 방송 및 멀티캐스트 서비스에서의 데이터 전송 방법 및 시스템
EP1401168A1 (en) * 2002-09-20 2004-03-24 Alcatel A method to transport an internet packet and related network elements
US7286536B2 (en) * 2002-10-28 2007-10-23 Nokia Corporation Method and system for early header compression
AU2003279480A1 (en) * 2002-12-04 2004-06-23 Koninklijke Philips Electronics N.V. Packetization of layered media bitstreams
US20040125770A1 (en) * 2002-12-31 2004-07-01 Pitt Randall Evans Method and apparatus for transferring state information between communication networks
KR100594115B1 (ko) * 2003-07-30 2006-06-28 삼성전자주식회사 패킷 데이터 서비스의 채널 타입 변경에 따른 헤더 압축 컨텍스트 설정 장치 및 방법
US20050094670A1 (en) * 2003-08-20 2005-05-05 Samsung Electronics Co., Ltd. Method for acquiring header compression context in user equipment for receiving packet data service
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
CN100505729C (zh) * 2003-10-30 2009-06-24 Ut斯达康(中国)有限公司 采用头压缩技术的实时ip分组的无线传输装置和方法
US7792158B1 (en) 2004-08-18 2010-09-07 Atheros Communications, Inc. Media streaming synchronization
US8149880B1 (en) 2004-08-18 2012-04-03 Qualcomm Atheros, Inc. Media streaming synchronization
US7680105B2 (en) * 2004-12-03 2010-03-16 Cisco Technology, Inc. Voice over internet protocol (VOIP) subcell multiplexing
US20060153196A1 (en) * 2005-01-11 2006-07-13 Conexant Systems, Inc. Systems and methods for achieving improved ADSL data rates over USB 1.1 channel
US8675631B2 (en) * 2005-03-10 2014-03-18 Qualcomm Incorporated Method and system for achieving faster device operation by logical separation of control information
US20100157833A1 (en) * 2005-03-10 2010-06-24 Qualcomm Incorporated Methods and systems for improved timing acquisition for varying channel conditions
CN1969475B (zh) * 2005-03-25 2012-07-04 桥扬科技有限公司 用于蜂窝广播和通信系统的方法和设备
US20060268820A1 (en) * 2005-05-19 2006-11-30 Heikki Mahkonen IP header compression with IPv6 mobile node
US7623607B2 (en) 2005-10-31 2009-11-24 Qualcomm Incorporated Methods and apparatus for determining timing in a wireless communication system
US8948329B2 (en) * 2005-12-15 2015-02-03 Qualcomm Incorporated Apparatus and methods for timing recovery in a wireless transceiver
US8826442B2 (en) * 2006-07-28 2014-09-02 Nxp B.V. Media playback decoder tracing
US7848280B2 (en) * 2007-06-15 2010-12-07 Telefonaktiebolaget L M Ericsson (Publ) Tunnel overhead reduction
KR101236033B1 (ko) * 2008-07-21 2013-02-21 한국전자통신연구원 통신 오버헤드를 제거하는 통신 시스템
WO2010011054A2 (en) * 2008-07-21 2010-01-28 Electronics And Telecommunications Research Institute Communication system for removing transmission overhead
US8902805B2 (en) * 2008-10-24 2014-12-02 Qualcomm Incorporated Cell relay packet routing
JP5479571B2 (ja) * 2009-03-20 2014-04-23 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 高度ｌｔｅにおけるセルフバックホール処理及びリレー処理用の無線ベアラ識別
US20100260098A1 (en) * 2009-04-10 2010-10-14 Qualcomm Incorporated Header compression for ip relay nodes
WO2010121416A1 (zh) * 2009-04-21 2010-10-28 华为技术有限公司 中继链路中处理数据的方法、中继节点和系统
CN102369753B (zh) * 2009-05-19 2014-08-06 华为技术有限公司 语音包发送、接收的方法、装置和系统
US8588227B2 (en) 2009-07-17 2013-11-19 Qualcomm Incorporated Recursive header compression for relay nodes
US9674311B2 (en) * 2009-08-14 2017-06-06 Qualcomm Incorporated Robust header compression for relay nodes
CN102143527B (zh) 2010-02-03 2013-09-11 华为技术有限公司 嵌套协议包头的压缩方法及装置
US9769287B2 (en) * 2010-05-10 2017-09-19 Telefonaktiebolaget Lm Ericsson (Publ) Reducing protocol overhead in single-block packet access procedures
CN101860552A (zh) * 2010-07-02 2010-10-13 河南伯示麦新能源科技有限公司 基于gprs的车载语音数据实时传输方法
CN102255906B (zh) * 2011-07-08 2014-07-23 中国联合网络通信集团有限公司 数据发送和接收方法、设备及系统
US8923816B2 (en) * 2011-07-28 2014-12-30 Samsung Electronics Co., Ltd. Apparatus and method for providing seamless service between a cellular network and wireless local area network for a mobile user
US8676159B1 (en) * 2012-09-28 2014-03-18 Juniper Networks, Inc. Mobile network interoperability
US9992021B1 (en) 2013-03-14 2018-06-05 GoTenna, Inc. System and method for private and point-to-point communication between computing devices
JP2014179844A (ja) * 2013-03-15 2014-09-25 Nec Corp パケット伝送装置、パケット伝送方法及びパケット伝送システム
WO2015180046A1 (zh) 2014-05-28 2015-12-03 华为技术有限公司 一种协议栈适配方法及装置
US9609035B2 (en) * 2015-03-04 2017-03-28 Oracle International Corporation Compressed headers for encapsulated real-time communications
CN107026887B (zh) * 2016-02-02 2019-12-06 上海交通大学 一种多媒体系统中快速信息交互方法及网络传输方法
CN111726347B (zh) * 2016-02-26 2022-04-15 上海交通大学 一种多媒体系统中信息交互机制及网络传输方法
EP3469780B1 (en) 2016-06-08 2022-09-21 Huawei Technologies Co., Ltd. Context information processor, profile distribution unit and method for a communication network
KR102123676B1 (ko) * 2016-12-06 2020-06-29 주식회사 엘지화학 주택용 ESS에 탑재되는 직류변압기(DC-DC converter)와 배터리관리시스템(BMS) 소프트웨어의 통합관리 및 업데이트 방법
TWI776270B (zh) * 2020-11-05 2022-09-01 財團法人資訊工業策進會 基於隧道協定的中繼節點與封包封裝方法
CN112566180B (zh) * 2020-12-09 2023-03-24 东方通信股份有限公司 一种提升tetra系统分组数据传输速率的方法
CN114629963B (zh) * 2022-03-16 2023-10-20 西安电子科技大学 基于层次聚类的网络协议报头压缩方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08223222A (ja) * 1995-02-14 1996-08-30 Hitachi Cable Ltd リモート中継装置
WO1999016266A1 (en) * 1997-09-25 1999-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Selectable packet-switched and circuit-switched services in a mobile communications network
JP2000201172A (ja) * 1998-12-07 2000-07-18 Lucent Technol Inc 通信システムにおけるル―ト最適化のための方法および装置
JP2003500933A (ja) * 1999-05-25 2003-01-07 ルーセント テクノロジーズ インコーポレーテッド インターネットプロトコルを使用する遠隔通信のための方法および装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI962381A (fi) * 1996-06-07 1997-12-08 Nokia Telecommunications Oy Datan pakkaaminen tietoliikenneyhteydellä
US6104929A (en) * 1997-06-20 2000-08-15 Telefonaktiebolaget Lm Ericsson Data packet radio service with enhanced mobility management
FI972725A (fi) * 1997-06-24 1998-12-25 Nokia Telecommunications Oy Uudelleenreititys
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
US6469998B1 (en) * 1998-10-06 2002-10-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for communicating data packets from an external packet network to a mobile radio station
US6438123B1 (en) * 1998-11-10 2002-08-20 Cisco Technology, Inc. Method and apparatus for supporting header suppression and multiple microflows in a network
US6314095B1 (en) * 1999-02-11 2001-11-06 Motorola, Inc. Method and apparatus for a high-speed multimedia content switch with compressed internet protocol header
US6438108B1 (en) * 1999-03-11 2002-08-20 Telefonaktiebolaget L M Ericsson (Publ) System for improved transmission of acknowledgements within a packet data network
US6542504B1 (en) * 1999-05-28 2003-04-01 3Com Corporation Profile based method for packet header compression in a point to point link
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08223222A (ja) * 1995-02-14 1996-08-30 Hitachi Cable Ltd リモート中継装置
WO1999016266A1 (en) * 1997-09-25 1999-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Selectable packet-switched and circuit-switched services in a mobile communications network
JP2000201172A (ja) * 1998-12-07 2000-07-18 Lucent Technol Inc 通信システムにおけるル―ト最適化のための方法および装置
JP2003500933A (ja) * 1999-05-25 2003-01-07 ルーセント テクノロジーズ インコーポレーテッド インターネットプロトコルを使用する遠隔通信のための方法および装置

Also Published As

Publication number Publication date
DE60007829D1 (de) 2004-02-26
EP1122925A1 (en) 2001-08-08
US6839339B1 (en) 2005-01-04
CA2329457C (en) 2004-07-20
CA2329457A1 (en) 2001-08-02
DE60007829T2 (de) 2004-12-02
JP2001244993A (ja) 2001-09-07
EP1122925B1 (en) 2004-01-21

Similar Documents

Publication Publication Date Title
JP4602568B2 (ja) パケットサーバで用いられる通信方法
JP3694241B2 (ja) インターネットプロトコルを使用する遠隔通信のための方法および装置
US7209491B2 (en) Method and system for transmitting data in a packet based communication network
JP3751823B2 (ja) 実時間サービスにおけるヘッダ圧縮
EP1329078B1 (en) Defining header field compression for data packet connection
EP1362446B1 (en) Transfer of ip data in communications system, using several logical connections for compressed fields on the basis of different contexts
US7212511B2 (en) Systems and methods for VoIP wireless terminals
US20060104278A1 (en) Apparatus and method for compressing headers in a broadband wireless communication system
KR100742868B1 (ko) 이동 데이터 통신망에서의 핸드오버 동안의 헤더 압축문맥 제어 방법
JP2006521050A (ja) インターネットプロトコルデータパケットの通信の通信装置及び通信方法
EP1360818B1 (en) Compression method, transmitter and receiver for radio data communication
KR100807455B1 (ko) 통신 시스템에서 송신 오버헤드를 감소시키기 위한 방법및 장치
KR100689473B1 (ko) 통신시스템에서 프로토콜 헤더 압축장치 및 방법
CN100428733C (zh) 移动通信网络中ip报头压缩的错误恢复方法及装置
West et al. IP header and signalling compression for 3G systems
JP4975806B2 (ja) 共有トランザクション（群）を有する複数通信機能
Kishi et al. A new inter-core built-in-self-test circuits for tri-state buffers in the system on a chip

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071207

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071207

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100430

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100531

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100714

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20100714

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: 20100906

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100930

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131008

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

LAPS Cancellation because of no payment of annual fees