(57)【特許請求の範囲】
【請求項１】
端末にコアネットワークへのアクセスを提供するアクセスネットワークのネットワーク装置におけるデータ伝送方法であって、
下りデータパケットを解析して対応するアプリケーションを学習し、既定の規則を活用して前記アプリケーションのアプリケーション分類を確定し、ベアラ確立時に、前記アプリケーション分類に従って、エアインタフェース接続に前記アプリケーションをマッピングし、
前記端末へ送信するための、高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得し、
マッピングされた前記エアインタフェース接続を介して前記高層プロトコルスタック・ヘッダを持たない下りデータパケットを前記端末へ送信する、
ことを含む、
データ伝送方法。
【請求項２】
前記端末へ送信する高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得することが、
前記端末へ送信するための、高層プロトコルスタック・ヘッダを有する前記下りデータパケットを受信し、前記下りデータパケットから前記高層プロトコルスタック・ヘッダを除去して、前記端末へ送信する高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得すること、及び／又は、
高層プロトコルスタック・ヘッダを持たない上りデータパケットを別の端末から受信し、前記上りのデータパケットを前記端末へ送信する高層プロトコルスタック・ヘッダを持たない下りデータパケットとして利用すること、
を含む請求項１に記載のデータ伝送方法。
【請求項３】
前記下りデータパケットから前記高層プロトコルスタック・ヘッダを除去して前記端末へ送信する高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得する場合において、前記下りデータパケットから前記高層プロトコルスタック・ヘッダを除去するときに、前記高層プロトコルスタック・ヘッダに関連するコンテキスト情報を維持する、
ことをさらに含む、請求項２に記載のデータ伝送方法。
【請求項４】
前記除去される高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ、または伝送制御プロトコル（ＴＣＰ）ヘッダの内の少なくとも１つまたはその組合せからなり、かつ、
前記下りデータパケットから前記高層プロトコルスタック・ヘッダを除去するときに、前記高層プロトコルスタック・ヘッダに関連するコンテキスト情報を維持することは、
前記インターネット・プロトコル（ＩＰ）ヘッダを除去し、下りの送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含みかつ前記コンテキスト情報に属する、前記インターネット・プロトコル（ＩＰ）ヘッダ内の情報を記録、維持すること、または、
前記ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダを除去し、下りの送信元／宛先ポート番号を含みかつ前記コンテキスト情報に属する、前記ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ内の情報を記録、維持すること、または、
前記伝送制御プロトコル（ＴＣＰ）ヘッダを除去し、下りのシーケンス番号と下りの送信元／宛先ポート番号を含みかつ前記コンテキスト情報に属する、前記伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報を記録、維持すること、または、
前記リアルタイム転送プロトコル（ＲＴＰ）ヘッダを除去し、同期送信元識別子及び／又は寄与送信元識別子を含みかつ前記コンテキスト情報に属する、前記リアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報を記録、維持すること、
を含む、請求項２または請求項３に記載のデータ伝送方法。
【請求項５】
前記下りデータパケットを解析して対応するアプリケーションを学習することが、アプリケーション−エアインタフェース統合サブレーヤを設定し、前記アプリケーション−エアインタフェース統合サブレーヤを利用して実行される、
請求項１〜４のいずれか一項に記載のデータ伝送方法。
【請求項６】
前記ベアラ確立時に前記アプリケーション分類に従って前記アプリケーションを前記エアインタフェース接続上にマッピングすることが、
前記エアインタフェース接続が前記アプリケーションのみを輸送する場合に、前記アプリケーションを前記エアインタフェース接続上にマッピングするために、前記アプリケーション分類を利用してエアインタフェース接続識別子及び／又はアクセスネットワーク内部チャネル識別子を前記アプリケーションに直接関連付けするか、
前記エアインタフェース接続が少なくとも２つのアプリケーションを輸送する場合に、前記アプリケーション分類を利用して少なくとも２つのアプリケーションを前記エアインタフェース接続上に関連付けする、
ことを含む、
請求項１〜４のいずれか一項に記載のデータ伝送方法。
【請求項７】
前記エアインタフェース接続が少なくとも２つのアプリケーションを輸送する場合に、前記アプリケーション分類を利用して少なくとも２つのアプリケーションを前記エアインタフェース接続上に関連付けすることが、
前記エアインタフェース接続識別子内に、前記エアインタフェース接続を標示するための接続標示識別と、前記エアインタフェース接続に対応するアプリケーションを標示するためのアプリケーション識別とを設定すること、または、
前記高層プロトコルスタック・ヘッダを持たない下りデータパケット内に、アプリケーションと前記エアインタフェース接続との間の対応関係を標示するアプリケーション補助ヘッダを設定すること、または、
前記高層プロトコルスタック・ヘッダを持たない下りデータパケットの無線アクセス制御ヘッダ内に、アプリケーションと前記エアインタフェース接続との間の対応関係を標示する、拡張識別を設定すること、または、
前記下りデータパケット上で詳細パケット検出を実行し、前記下りデータパケットのアプリケーションに対応する前記エアインタフェース接続を確定すること、
を含む、
請求項６に記載のデータ伝送方法。
【請求項８】
前記エアインタフェース接続を介して前記高層プロトコルスタック・ヘッダを持たない下りデータパケットを前記端末へ送信する前に、
システムのブロードキャスト・メッセージを通して、前記端末に、アクセスネットワークによりサポートされる超平坦プロトコルスタック能力を通知するか、または
ベアラ確立処理時に、ベアラ確立要求メッセージを介して、前記端末に、アクセスネットワークによりサポートされる超平坦プロトコルスタック能力を通知する、
ことをさらに含み、
前記超平坦プロトコルスタック能力とは、前記アクセスネットワークが不必要な高層プロトコルスタック・ヘッダをサポートする能力、及び／又は前記高層プロトコルスタック・ヘッダの特定情報の欠落を実装する方式である、
請求項１〜７のいずれか一項に記載のデータ伝送方法。
【請求項９】
高層プロトコルスタック・ヘッダを持たない上りデータパケットを端末から受信し、
前記上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、
前記高層プロトコルスタック・ヘッダを用いてカプセル化された前記上りデータパケットを転送する、
ことを更に含む、請求項１〜８のいずれか一項に記載のデータ伝送方法。
【請求項１０】
前記上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化することが、
下りの送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含む、保持されたインターネット・プロトコル（ＩＰ）ヘッダ情報を利用して上りデータパケットのためのインターネット・プロトコル（ＩＰ）ヘッダをカプセル化すること、及び／又は、
下りの送信元／宛先ポート番号を含む、保持されたユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ情報を利用して上りデータパケットのためのユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダをカプセル化すること、及び／又は、
下りのシーケンス番号と下りの送信元／宛先ポート番号を含む、保持された伝送制御プロトコル（ＴＣＰ）ヘッダ情報を利用して上りデータパケットのための伝送制御プロトコル（ＴＣＰ）ヘッダをカプセル化すること、及び／又は、
同期送信元識別子及び／又は寄与送信元識別子を含む、保持されたリアルタイム転送プロトコル（ＲＴＰ）ヘッダ情報を利用して上りデータパケットのためのリアルタイム転送プロトコル（ＲＴＰ）ヘッダをカプセル化すること、
を含む、
請求項９に記載のデータ伝送方法。
【請求項１１】
端末にコアネットワークへのアクセスを提供するアクセスネットワークのネットワーク装置であって、
下りデータパケットを解析して対応するアプリケーションを学習し、既定の規則を利用して前記アプリケーションのアプリケーション分類を確定するアプリケーション分類モジュールと、
ベアラ確立時に、前記アプリケーション分類モジュールによって確定された前記アプリケーション分類に従って、前記アプリケーションを、エアインタフェース接続にマッピングするベアラマッピングモジュールと、
前記端末へ送信するための、高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得する、下りデータパケット取得ユニットと、
前記下りデータパケット取得ユニットにより取得された前記高層プロトコルスタック・ヘッダを持たない下りデータパケットを、マッピングされた前記エアインタフェース接続を介して前記端末へ送信する送信ユニットと、
を備える、
ネットワーク装置。
【請求項１２】
前記下りデータパケット取得ユニットは、第１の取得モジュール、及び／又は第２の取得モジュールを備え、
前記第１の取得モジュールは、前記端末に送信するための、高層プロトコルスタック・ヘッダを有する前記下りデータパケットを受信し、かつ前記下りデータパケットから前記高層プロトコルスタック・ヘッダを除去して、前記端末へ送信する高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得し、
前記第２の取得モジュールは、高層プロトコルスタック・ヘッダを持たない上りデータパケットを別の端末から受信し、前記上りデータパケットを前記端末へ送信する高層プロトコルスタック・ヘッダを持たない下りデータパケットとして利用する、
請求項１１に記載のネットワーク装置。
【請求項１３】
前記第１の取得モジュールはプロトコル情報除去ユニットをさらに備え、
前記プロトコル情報除去ユニットは、
インターネット・プロトコル（ＩＰ）ヘッダを除去し、かつ下り送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含む前記インターネット・プロトコル（ＩＰ）ヘッダ中の情報を記録及び保持し、及び／又は、
ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダを除去し、かつ下り送信元／宛先ポート番号を含む前記ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ中の情報を記録及び保持し、及び／又は、
伝送制御プロトコル（ＴＣＰ）ヘッダを除去し、かつ下りシーケンス番号と下り送信元／宛先ポート番号とを含む前記伝送制御プロトコル（ＴＣＰ）ヘッダ中の情報を記録及び保持し、及び／又は、
リアルタイム転送プロトコル（ＲＴＰ）ヘッダを除去し、かつ同期送信元識別子及び／又は寄与送信元識別子を含む前記リアルタイム転送プロトコル（ＲＴＰ）ヘッダ中の情報を記録及び保持し、
前記高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ、または伝送制御プロトコル（ＴＣＰ）ヘッダの内の少なくとも１つまたはその組合せを含む、
請求項１２に記載のネットワーク装置。
【請求項１４】
前記ベアラマッピングモジュールは、
エアインタフェース接続識別子内に、前記エアインタフェース接続を標示するための接続標示識別と、前記エアインタフェース接続に対応するアプリケーションを標示するためのアプリケーション識別とを設定するか、
前記高層プロトコルスタック・ヘッダを持たない下りデータパケット内に、前記アプリケーションと前記エアインタフェース接続との間の対応関係を標示するアプリケーション補助ヘッダを設定するか、
前記高層プロトコルスタック・ヘッダを持たない下りデータパケットの無線アクセス制御ヘッダ内に、前記アプリケーションと前記エアインタフェース接続との間の対応関係を標示する、拡張識別を設定するか、
前記下りデータパケット上で詳細パケット検出を実行し、前記下りデータパケットのアプリケーションに対応する、少なくとも２つのアプリケーションを輸送する前記エアインタフェース接続を確定する、
請求項１１〜１３のいずれか一項に記載のネットワーク装置。
【請求項１５】
高層プロトコルスタック・ヘッダを持たない上りデータパケットを端末から受信するデータ受信ユニットと、
前記データ受信ユニットにより受信された、前記上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化するプロトコル情報復元ユニットと、
前記プロトコル情報復元ユニットにより、高層プロトコルスタック・ヘッダを用いてカプセル化された前記上りデータパケットを転送する転送ユニットと、
を更に備える、請求項１１〜１４のいずれか一項に記載のネットワーク装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線ネットワーク技術に関し、特に、データ伝送方法、装置及びシステムに関する。
【背景技術】
【０００２】
無線サービスに対する継続的な需要増大に伴い、データサービス、オーディオ／ビデオサービス、移動体ブログなどの様々なサービスが出現してきている。そしてこのことが、データ伝送の効率、すなわちデータ伝送の有効性に対するより高い要求をもたらしている。それと同時に、移動通信ネットワークとインターネットとの融合がより大きな注目を集めるようになってきている。
【０００３】
将来の無線インターネット応用においては、端末がサービスの送信元として作用する可能性はますます増大するであろう。そして、上りの伝送リソースへの需要もさらに増していくであろう。しかしながら無線周波数の資源は少なく、運用者がより多くの周波数資源を利用しようとすると、運用コストが増大する。通信データの伝送量を増やすためにより高次の変調方式を採用すると、それだけ高い信号対雑音比が必要となり、その結果として基地局及び端末により高い伝送電力が必要となる。それはエネルギー消費量を増大させることになって環境調和の通信に逆行することになる。現在のところ、エアインタフェース伝送の効率を如何に増すかが、無線サービスの発展規模制約の鍵となっている。
【０００４】
データサービスが無線で行われる場合、データパケット中のプロトコルスタック・ヘッダがリソースのかなりの部分を占める。この部分のリソースは実際にはユーザのアプリケーションに必要な有効データではない。図１は、無線ネットワークで行われるリアルタイム転送プロトコル（ＲＴＰ）ビデオサービスのプロトコルスタック構造を模式的に示す図である。例えば、ＩＰｖ６音声通信グループでは、ユーザが実際に必要とするペイロードは通常、グループ全体の約２２％に過ぎず、残りの大部分はプロトコルヘッダ情報である。エアインタフェース伝送の有効性を向上させるためには、無線エアインタフェースで伝送されるプロトコルデータパケットのヘッダ情報を減少させなければならない。
【０００５】
従来、この無線エアインタフェースで伝送されるプロトコルデータパケットのヘッダ情報を低減するために複数のヘッダ圧縮機構が提供されている。例えば、ロバストヘッダ圧縮（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ，  ＲＯＨＣ）機構は、高ビットエラーと長時間遅延を持つリンクに適用可能なヘッダ圧縮機構を提供する。ＲＯＨＣ機構は、フローに基づく圧縮法である。ＲＯＨＣ機構では、特定のフローから参照グループが取り出され、それ以外のグループに対しては、参照グループと異なるヘッダ項目情報のみが送信されて、圧縮の目的を達成する。こうしてグループのヘッダのオーバヘッドを節約し、バンド幅をより効果的に利用する。同時に、ＲＯＨＣは、フィードバックメッセージの頻度と量の制御、非同期論理の検出、及びエラーチェックを通して、ＲＯＨＣ機構が確実に高効率でありかつ合理的なロバストネスを有するようにする。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明を実装するに当たり、従来技術には少なくとも以下の問題があることがわかった。
【０００７】
既存のヘッダ圧縮機構は、インターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）を対象として、層分割の概念に基づいて異なる層でのプロトコルヘッダ情報の圧縮を主に行う。そのような圧縮機構は、層間のデータの冗長性、特にアプリケーション層と他の層との間のデータの冗長性に関しては考慮せず、従って圧縮効果は非常に限定的である。また、圧縮機構は有線ネットワークに対して設計されており、無線ネットワークの特徴への配慮が欠けている。この圧縮機構を無線ネットワークに利用してインタフェース伝送の効率を向上させようとすると、期待される効果が得られず、ユーザの要求は充たされない。
【課題を解決するための手段】
【０００８】
従来技術における問題点を解決するために、本発明の実施形態では、エアインタフェースにより伝送されるデータ量を大幅に低減し、エアインタフェース伝送の効率を実質的に向上させ、かつエアインタフェースのリソースを節約することのできる、データ伝送方法、装置及びシステムが提供される。
【０００９】
その目的を達成するために、本発明の実施形態は以下の技術的解法を採用する。
【００１０】
本発明の一実施形態はデータ伝送方法を提供し、その方法は、端末向けの、高層プロトコルスタック・ヘッダを持たない下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信することを含む。
【００１１】
本発明の一実施形態は別のデータ伝送方法を提供する。その方法は、      アクセスネットワークへ送信するための、高層プロトコルスタック・ヘッダを持たない上りデータパケットを生成し、エアインタフェースを介してその上りのデータパケットを前記アクセスネットワークへ送信することを含む。
【００１２】
本発明の一実施形態は別のデータ伝送方法を提供する。その方法は、      端末から上りのデータパケットを受信し、その上りデータパケットは高層プロトコルスタック・ヘッダを持たず、その上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、高層プロトコルスタック・ヘッダを用いてカプセル化されたその上りデータパケットを転送することを含む。
【００１３】
本発明の一実施形態はネットワーク装置を提供する。この装置は、端末に送信される、高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得する下りデータパケット取得ユニットと、下りデータパケット取得ユニットにより取得された下りデータパケットを、エアインタフェースを介して端末へ送信する送信ユニットと、を備える。
【００１４】
本発明の一実施形態は端末を提供する。これは、高層プロトコルスタック・ヘッダを持たない上りのデータパケットをアクセスネットワークへ送信する上りデータパケット生成モジュールと、上りデータパケット生成モジュールにより生成された上りデータパケットを、エアインタフェースを介してアクセスネットワークへ送信するデータ送信ユニットと、を備える。
【００１５】
本発明の一実施形態は別のネットワーク装置を提供する。この装置は、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信するデータ受信ユニットと、データ受信ユニットにより受信された上りデータパケットのための、対応する高層プロトコルスタック・ヘッダをカプセル化するプロトコル情報復元ユニットと、プロトコル情報復元ユニットにより、高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送するように構成された、転送ユニットとを備える。
【００１６】
本発明の一実施形態はさらに通信システムを提供し、このシステムにはアクセスネットワークにあるネットワーク装置が含まれる。
【００１７】
このネットワーク装置は、端末に送信される、高層プロトコルスタック・ヘッダを持たない下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信するか、あるいは、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信し、その上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、その高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送する。
【００１８】
本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを伴う必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、アクセスネットワークが上りのデータパケットの高層プロトコルスタック・ヘッダを復元することができる。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【図面の簡単な説明】
【００１９】
【図１】従来技術の無線ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）ビデオサービスのプロトコルスタック構造を模式的に示す図である。
【図２】本発明の一実施形態において提供される超平坦プロトコルスタックのアーキテクチャの模式図である。
【図３】本発明の実施形態１で提供されるデータ伝送方法の模式的フロー図である。
【図４】本発明の実施形態２で提供されるデータ伝送方法の模式的フロー図である。
【図５】本発明の実施形態３で提供されるデータ伝送方法の模式的フロー図である。
【図６】本発明の実施形態により提供される、ユーザ設備（ＵＥ）のネットワークアクセスネゴシエーションプロセスのフロー図である。
【図７】本発明の一実施形態により提供される分類器の模式図である。
【図８Ａ】本発明の一実施形態により提供されるアプリケーション補助層の模式図である。
【図８Ｂ】本発明の一実施形態により提供されるアプリケーション補助ヘッダの模式図である。
【図８Ｃ】本発明の一実施形態により提供される媒体アクセス制御（ＭＡＣ）ヘッダの模式図である。
【図９Ａ】本発明の一実施形態により提供されるアプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ  ＣＳ）の模式図である。
【図９Ｂ】本発明の一実施形態により提供される別のアプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ  ＣＳ）の模式図である。
【図１０】本発明の一実施形態で提供される、伝送制御プロトコル（ＴＣＰ）ヘッダのコンテキスト保持と再送信機構の模式的フロー図である。
【図１１】本発明の一実施形態で提供される、リアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元とコンテキスト保持の模式的フロー図である
【図１２】本発明の一実施形態により提供されるネットワーク装置の模式的構造図である。
【図１３】本発明の一実施形態により提供される端末の模式的構造図である。
【図１４】本発明の一実施形態により提供される別のネットワーク装置の模式的構造図である。
【発明を実施するための形態】
【００２０】
本発明の実施形態による技術的解法あるいは従来技術による解法をより明らかに示すために、実施形態または従来技術に関する添付の図面を以下に簡単に説明する。以下の説明において、添付の図面は本発明のいくつかの実施形態だけに関するものであり、当業者であれば創造的努力なしに添付の図面から別の図面を派生させることが可能であることは、明らかであろう。
【００２１】
本発明の技術的解法を以下に添付の図面を参照して、明快かつ完全に説明する。説明する実施形態は、本発明の実施形態のすべてというより、その一部分に過ぎないことは明らかである。本発明の実施形態に基づき、当業者が創造的努力なしに取得する他のすべての実施形態は、本発明の保護範囲内に含まれる。
【００２２】
無線ネットワークを平坦化する開発動向は、ますます顕著になってきている。例えば、ロングターム・エボリューション・ネットワーク（ＬＴＥ／ＬＴＥ＋）においては、関連する機能エンティティは発展型基地局（ｅ−ＮｏｄｅＢ）へ移行し、機能エンティティ間の接続の強化によりｅ−ＮｏｄｅＢ機能エンティティ／層の境界がぼやけてきて、無線ネットワークは超平坦プロトコルスタックを持つようになる。すなわち無線ネットワークの特性により、すべての不要なプロトコル層構造を除去することが可能となる。
【００２３】
本発明の実施形態の技術概念は、主として、無線ネットワークのポイント・ツー・ポイントの通信特性とネットワーク側にある端末のために保存されているコンテキストとを利用して、既存のプロトコルスタックに平坦化処理を行なうことである。端末とアクセスノードとの間が単一ホップ特性であることにより、それ以外のルーティング機構が不要である。従って、インタフェース伝送時に、不要なプロトコルヘッド情報ユニットを除去することが可能であり、その結果エアインタフェース伝送時のデータパケットサイズを大幅に低減できる。また、無線ネットワーク側のエンティティが端末のコンテキスト情報を保持しており、例えば、サービス品質（ＱｏＳ）情報／分類器情報は、インターネット・プロトコル（ＩＰ）五要素や対応するプロトコルスタック情報などの多くのプロトコルスタック関連情報を有しているので、対応するプロトコルスタック情報は無線ネットワーク側で復元される。本発明の実施形態における技術的解法によって、エアインタフェース伝送における効率が大幅に強化され、かつエアインタフェースのリソースが節約される。その結果、無線サービスの強化及び発展が促進される。
【００２４】
本発明の一実施形態は、無線ネットワーク側と対応する端末側に超平坦なプロトコルスタックを実現する。そのアーキテクチャの模式図を図２に示す。ここでは、エアインタフェース伝送時に、アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）層データは物理層（ＰＨＹ）と媒体アクセス制御（ＭＡＣ）層との上に直接輸送され、エアインタフェースリソースが節約される。
【００２５】
本発明の一実施形態で提供される通信システムにおいて、下りの伝送に関しては、コアネットワーク（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）から下りのデータパケットを受信した後、アクセスネットワーク（Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）は要求に従って、アクセスネットワークによって保持されているコンテキスト情報を更新し、データパケットのインターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）を除去し、下りのデータパケットのアプリケーションを対応するエアインタフェース接続またはエアインタフェースチャネルへマッピングし、そして、対応するコンテキスト情報を保持する。その後、アクセスネットワークは、アクセスネットワークの内部トンネルと、アクセスネットワークのエアインタフェース接続あるいはインタフェースチャネルにその下りのデータパケットを直接輸送して、その下りのデータパケットをユーザ設備（ＵＥ）へ伝送するか、あるいは、下りのデータパケットに必要な情報を付加した後に、アクセスネットワークの内部トンネルと、アクセスネットワークのエアインタフェース接続あるいはインタフェースチャネルにその下りのデータパケットを輸送し、その下りのデータパケットをユーザ設備（ＵＥ）へ伝送する。下りのデータパケットを受信した後、ユーザ設備（ＵＥ）は物理層（ＰＨＹ）と媒体アクセス制御（ＭＡＣ）ヘッダを除去し、データパケットを対応するアプリケーションへ転送する。
【００２６】
上りの伝送に対しては、ユーザ設備（ＵＥ）は生成された上りのデータパケットを対応するエアインタフェース接続にマッピングする。ここで上りのデータパケットは超平坦プロトコルスタックをサポートするデータパケットである。その後、ユーザ設備（ＵＥ）は、アクセスネットワークのエアインタフェースと（チャネルがある場合には）アクセスネットワークの内部チャネル上にその上りデータパケットを直接輸送して、上りデータパケットをアクセスネットワークへ伝送するか、あるいは必要な情報を付加した後に、ユーザ設備（ＵＥ）は、アクセスネットワークのエアインタフェースと（チャネルがある場合には）アクセスネットワークの内部チャネル上にその上りデータパケットを輸送して、上りデータパケットをアクセスネットワークへ伝送する。上りデータパケットを取得した後、ユーザ設備（ＵＥ）に対応するアプリケーションのコンテキスト情報に従って、アクセスネットワークは対応するプロトコルスタックデータパケットのヘッダ情報を復元または再生し、その対応情報をインターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）データパケット内にカプセル化し、データパケットを有線リンク上に輸送し、そうしてデータパケットをコアネットワークへ送信する。
【００２７】
エアインタフェース伝送において、ユーザ設備（ＵＥ）と基地局（ＢＳ）との間にポイント・ツー・ポイントのエアインタフェース接続が存在し、基地局（ＢＳ）とゲートウェイ（ＧａｔｅＷａｙ，  ＧＷ）との間にポイント・ツー・ポイントのトンネルが存在するので、インターネット・プロトコル（ＩＰ）にルート情報を提供しなくてもよい。関連するユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）情報はアクセスネットワークによって保持されている分類器情報内に存在し、関連するデータパケットのポート情報またはそれに類するものをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）に提供しなくてもよい。端末がサービス元として作用する場合、リアルタイム転送プロトコル（ＲＴＰ）に関しては、無線スケジューリングが連続性を有しており、シーケンス番号（ＳＮ）やタイムスタンプ（ｔｉｍｅｓｔａｍｐ）などの関連情報は、予測可能である。このようにして、本発明の実施形態において、インターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）プロトコルヘッダをエアインタフェース伝送において除去することが可能であり、結果として超平坦プロトコルスタック構造が実現される。
【００２８】
本発明の実施形態１にデータ伝送方法が提供され、図３に示すようにこの方法は以下のステップを含む。
【００２９】
ステップ３１：端末向けの下りのデータパケットを取得する。ここで、この下りのデータパケットは高層プロトコルスタック・ヘッダを持たない。
【００３０】
ステップ３２：エアインタフェースを介してその下りのデータパケットを端末へ送信する。
【００３１】
本発明の実施形態において、ステップ３１とステップ３２は、例えば、アクセスネットワーク内のｅ−ＮｏｄｅＢ、ゲートウェイ、アプリケーションプロキシ／アプリケーション機能、などのような関連するネットワーク要素や機能エンティティによって実装されてもよい。本発明の実施形態において、アクセスネットワークと端末はいずれも、下り方向のデータ伝送において超平坦プロトコルスタックをサポートすることが必要である。
【００３２】
ステップ３１において、アクセスネットワークは、高層プロトコルスタック・ヘッダを持ち、コアネットワークから送信された下りデータパケットを受信し、その下りデータパケットから高層プロトコルスタック・ヘッダを除去し、そしてその下りデータパケットを端末へ送信することができる。及び／又は、ローカル伝送がサポートされている場合、同一のアクセスネットワークへアクセスする２つの端末に対して、一方の端末が高層プロトコルスタック・ヘッダを持たないデータパケットをアクセスネットワークに送信し、アクセスネットワークは、データパケットを受信した後に下りデータパケットとしてもう一方の端末にそのデータパケットを送信する。
【００３３】
高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、伝送制御プロトコル（ＴＣＰ）ヘッダ、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダのうちの少なくとも１つまたはその組合せを含む。高層プロトコルスタック・ヘッダを除去する場合、アクセスネットワークは、要請により、インターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべてを除去するか、インターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべてを除去するか、あるいはまた、インターネット・プロトコル（ＩＰ）ヘッダだけを除去するか、またはインターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダだけを除去するか、またはインターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダだけを除去するか、などが可能である。
【００３４】
本発明の実施形態においては、高層プロトコルスタック・ヘッダを除去する場合、アクセスネットワークはさらに、データパケットのタイプと関連する規則に従って、高層プロトコルスタック・ヘッダに関連するコンテキスト情報を保持することができる。保持されるコンテキスト情報は主として、超平坦プロトコルをサポートする上りデータパケットの高層プロトコルスタック・ヘッダを復元するために利用される。ヘッダが異なれば対応するコンテキスト情報も異なる。
【００３５】
本発明の実施形態において提供される技術的解法では、無線ネットワークにおける伝送のポイント・ツ―・ポイント特性を利用して、既存のプロトコルスタックに平坦化処理を実行し、エアインタフェースを介してアクセスネットワークと端末との間で伝送されるデータパケットは、不要な高層プロトコルスタック・ヘッダを搬送する必要がない。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【００３６】
本発明の実施形態２にデータ伝送方法が提供され、図４に示すようにこの方法は以下のステップを含む。
【００３７】
ステップ４１：アクセスネットワーク向けの上りデータパケットを生成する。ここで、この上りデータパケットは高層プロトコルスタック・ヘッダを持たない。
【００３８】
ステップ４２：エアインタフェースを介してその上りのデータパケットを前記アクセスネットワークへ送信する。
【００３９】
本発明の実施形態２において、ステップ４１とステップ４２は、ユーザ設備（ＵＥ）などの端末によって実装することができる。本発明の実施形態において、アクセスネットワークと端末はいずれも、上り方向のデータ伝送において超平坦プロトコルスタックをサポートすることが必要である。
【００４０】
高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、伝送制御プロトコル（ＴＣＰ）ヘッダ、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダのうちの少なくとも１つまたはその組合せを含む。データパケットを生成する場合、端末は要求に従って、インターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべて、あるいはインターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべてを生成しなくてもよく、インターネット・プロトコル（ＩＰ）ヘッダだけを生成するか、またはインターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダだけを生成するか、またはインターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダだけを生成してもよい。
【００４１】
具体的には、以下に述べる少なくとも１つまたはその組合せに従って、端末は、アクセスネットワーク向けの上りのデータパケットを生成することができる。アプリケーションデータパケットを、媒体アクセス制御（ＭＡＣ）データパケットとして直接カプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットをリアルタイム転送プロトコル（ＲＴＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。ここで、「／」は「あるいは」ということを表し、アプリケーションデータパケットはまずユーザ・データグラム・プロトコル（ＵＤＰ）データパケットとしてカプセル化され、次に媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化されるか、あるいは、アプリケーションデータパケットはまず伝送制御プロトコル（ＴＣＰ）データパケットとしてカプセル化され、次に媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化される、ということである。そして、または、先ずアプリケーションデータパケットをインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットを順番にユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。
【００４２】
本発明の実施形態において提供される技術的解法では、無線ネットワークにおける伝送のポイント・ツ―・ポイント特性を利用して、既存のプロトコルスタックに平坦化処理を実行し、エアインタフェースを介してアクセスネットワークと端末との間で伝送されるデータパケットは、不要な高層プロトコルスタック・ヘッダを搬送する必要がない。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【００４３】
本発明の実施形態３においてデータ伝送方法が提供され、図５に示すようにこの方法は以下のステップを含む。
【００４４】
ステップ５１：端末から上りのデータパケットを受信する。ここでこの上りデータパケットは高層プロトコルスタック・ヘッダを持たない。
【００４５】
ステップ５２：上りデータパケット用の対応する高層プロトコルスタック・ヘッダをカプセル化する。
【００４６】
ステップ５３：その高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送する。
【００４７】
本発明の実施形態において、ステップ５１〜ステップ５３は、例えば、アクセスネットワーク内のｅ−ＮｏｄｅＢ、ゲートウェイ、アプリケーションプロキシ／アプリケーション機能、などのような関連するネットワーク要素や機能エンティティによって実装されてもよい。本発明の実施形態において、アクセスネットワークと端末はいずれも、下り方向のデータ伝送において超平坦プロトコルスタックをサポートすることが必要である。
【００４８】
アクセスネットワークは、例えば下りのデータパケットの伝送時に記録された、高層プロトコルスタック・ヘッダのコンテキスト情報、並びにネットワークに保持されている関連するアプリケーションのコンテキスト情報などの、高層プロトコルスタック・ヘッダのそれぞれに保持されているコンテキスト情報を利用して、高層プロトコルスタック・ヘッダを復元する。あるいは、特定のアプリケーションに対して、アクセスネットワークが対応する高層プロトコルスタック・ヘッダの情報を個別に復元することに失敗した場合、そして、端末が関連するプロトコルスタックの第１のデータパケット、例えば伝送制御プロトコル（ＴＣＰ）データパケット、を送信する場合、端末は完全な高層プロトコルスタック・ヘッダを持っているデータパケットを送信して、アクセスネットワークが高層プロトコルスタック・ヘッダの情報を学習し、後続の関連する上りのデータパケットのヘッダの復元にその情報を利用する。
【００４９】
本発明の実施形態において提供される技術的解法では、無線ネットワークにおける伝送のポイント・ツ―・ポイント特性を利用して、既存のプロトコルスタックに平坦化処理を実行し、エアインタフェースを介してアクセスネットワークと端末との間を伝送する際に、データパケットの不要な高層プロトコルスタック・ヘッダが除去される。データをコアネットワークへ転送する場合、アクセスネットワークが上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量を大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【００５０】
要求に従って、本発明の実施形態において提供される超平坦プロトコルスタック構造が上り方向にだけ実装されるか、または本発明の実施形態において提供される超平坦プロトコルスタック構造が下り方向にだけ実装されるか、あるいは本発明の実施形態において提供される超平坦プロトコルスタック構造が上りと下りの両方向に同時に実装される可能性があることは理解されるであろう。
【００５１】
本発明の実施形態４において提供されるデータ伝送方法を以下に詳細に説明する。
【００５２】
超平坦プロトコルスタックアーキテクチャにおける正常なデータ伝送を保証するために、まず、無線アクセスネットワークは、ユーザ設備（ＵＥ）が超平坦プロトコルスタックをサポート可能であることを学習する必要があり、ユーザ設備（ＵＥ）は無線アクセスネットワークが超平坦プロトコルスタックをサポート可能であることを学習する必要がある。ここで、超平坦プロトコルスタックの能力とは、アクセスネットワークまたは端末が、不必要な高層プロトコルスタック・ヘッダ及び／又は高層プロトコルスタック・ヘッダ特定の情報の欠落を実装する仕方、をサポートする能力のことである。
【００５３】
本発明の実施形態において、ネットワークのアクセスプロセス中に、ユーザ設備（ＵＥ）は無線側と、ユーザ設備（ＵＥ）によりサポートされている超平坦プロトコルスタック、あるいはその超平坦プロトコルスタックに対応するプロファイル（Ｐｒｏｆｉｌｅ）に関してネゴシエートして、ユーザ設備（ＵＥ）がサポートしている超平坦プロトコルスタックの能力について無線アクセスネットワークに情報提供しなければならない。超平坦プロトコルスタックの定義が異なれば、異なるプロファイルが対応する。プロファイルは、データパケットが必ずしも保持していない高層プロトコルスタック・ヘッダと、プロファイルの適用に必要なそのほかの情報とを示す。表１にある種のプロファイルセットの例が示されている。
【表１】
0005877160.tif 000002
【００５４】
アクセスネットワークは、システムのブロードキャスト・メッセージを介して、サポートする超平坦プロトコルスタックをサポート可能であることをユーザ設備（ＵＥ）に通知する。例えば、ｅ−ＮｏｄｅＢは、ｅ−ＮｏｄｅＢがサポートする超平坦プロトコルスタックの能力を、システムの周期的なブロードキャスト・メッセージによってユーザ設備（ＵＥ）へ一斉同報する。また、ｅ−ＮｏｄｅＢは、ｅ−ＮｏｄｅＢがサポートする超平坦プロトコルスタックの能力を、システムメッセージ中に超平坦プロトコルスタックのサポートされるプロファイルを送ることによってユーザ設備（ＵＥ）へ一斉同報することも選択可能である。ユーザ設備（ＵＥ）はシステムのブロードキャスト・メッセージを通して、無線アクセスネットワークがサポートしていることを学習する。
【００５５】
図６には、ユーザ設備（ＵＥ）と無線アクセスネットワークの間のネットワークアクセスのネゴシエーション過程が詳細に示されている。ここで、説明の例としてインターネット・プロトコル／ユーザ・データグラム・プロトコル／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ／ＲＴＰ）高層プロトコルスタックを例として説明する。ただし、本発明はこのプロトコルスタック構造に限るものではない。
【００５６】
ステップＴ１：ｅ−ＮｏｄｅＢがシステムブロードキャスト・メッセージをユーザ設備（ＵＥ）に送信し、アクセスネットワークがサポートする超平坦プロトコルスタックの能力をユーザ設備（ＵＥ）に通知する。
【００５７】
ステップＴ２：ネットワークアクセス過程において、ユーザ設備（ＵＥ）は能力のネゴシエーション時に、能力ネゴシエーションメッセージを介してユーザ設備（ＵＥ）の超平坦プロトコルスタックの能力をアクセスネットワークへ通知する。ユーザ設備（ＵＥ）の能力、ユーザの加入者情報、及びその能力に従って、アクセスネットワークはユーザ設備（ＵＥ）が使用できるプロファイルセットを決定する。ここでこのプロファイルセットは１つまたは複数のプロファイルを含んでよい。
【００５８】
ステップ１とステップ２を通して、ユーザ設備（ＵＥ）とアクセスネットワークはお互いの超平坦プロトコルスタックの能力を学習することができる。これを基にしてユーザ設備（ＵＥ）とアクセスネットワークとの間でデータ伝送が実装される。
【００５９】
ステップＴ３：ネットワークアクセスの基本過程が完了すると、ユーザ設備（ＵＥ）は対応するサービスフローまたはベアラバインディング（Ｂｅａｒｅｒ  Ｂｉｎｄｉｎｇ）を確立し、対応するインターネット・プロトコル（ＩＰ）アドレスを取得する。
【００６０】
ステップＴ４：ゲートウェイなどのアクセスネットワークは、ユーザ設備（ＵＥ）の関連するコンテキスト情報、及び、例えばユーザ設備（ＵＥ）のインターネット・プロトコル（ＩＰ）アドレスとバージョン数情報などの、特にインターネット・プロトコル（ＩＰ）プロトコル関連情報を確立する。
【００６１】
ステップＴ５：ユーザ設備（ＵＥ）が特定のアプリケーションの使用を必要とする場合、ユーザ設備（ＵＥ）はアプリケーション層信号を介して、コアネットワーク（または別のユーザ設備（ＵＥ））とのアプリケーションネゴシエーション確立過程を終了する。
【００６２】
ステップＴ６：アプリケーション確立過程において、アクセスネットワークがこのアプリケーションに関するプロトコルスタックのコンテキスト情報をまだ持ってないか、元のプロトコルスタックのコンテキスト情報が変更される場合には、アクセスネットワークは、ユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）情報などの関連するプロトコルスタック情報と、ユーザ・データグラム・プロトコル（ＵＤＰ）ポート番号や伝送制御プロトコル（ＴＣＰ）ポート番号やシーケンス番号などのユーザ設備（ＵＥ）コンテキストへのリアルタイム転送プロトコル（ＲＴＰ）情報とアプリケーション情報と、リアルタイム転送プロトコル（ＲＴＰ）タイムスタンプとシーケンス番号とを付加あるいは更新する。
【００６３】
ステップＴ７：アクセスネットワークは、ユーザ設備（ＵＥ）に対するアプリケーションの関連するベアラを確立し、新規作成または既存の特定のベアラにアプリケーションをバインドする。
【００６４】
ステップＴ８：データ伝送を実行する。ここには主に以下の過程が含まれる。
【００６５】
１つのコアネットワークからデータを受信する場合、アクセスネットワークは、対応する高層プロトコルスタック・ヘッダ、例えばＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰヘッダを除去し、アプリケーション層データをアクセスネットワーク内部のエアインタフェース上に直接輸送し、そしてエアインタフェースを介してそのデータをユーザ設備（ＵＥ）へ送信する。アクセスネットワークへデータを送信する場合、ユーザ設備（ＵＥ）はエアインタフェース上のアプリケーション層データを直接送信し、このアプリケーション層データはアクセスネットワーク内部を直接送信されて、ユーザ設備（ＵＥ）のコンテキスト情報とアプリケーションデータパケット情報（アプリケーションデータヘッダ情報またはアプリケーションデータ情報のいずれか）とに従って、アクセスネットワークが対応するＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ  ヘッダを復元し、そのヘッダを対応するコアネットワークへ伝送する。
【００６６】
本発明の実施形態５で提供されるデータ伝送方法において、超平坦プロトコルスタック構造が採用され、アプリケーションのデータパケットはエアインタフェース接続（例えば媒体アクセス制御（ＭＡＣ）接続）上に直接輸送される。そして１つの媒体アクセス制御（ＭＡＣ）接続上には１つまたは複数のアプリケーションを輸送することができる。データの正常な伝送を保証するために、アプリケーションを対応する媒体アクセス制御（ＭＡＣ）接続上に輸送するための、アプリケーションデータの分類と統合方法が本発明の実施形態３で提供される。
【００６７】
アプリケーション−エアインタフェース統合サブレーヤ、例えば、アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｓｕｂｌａｙｅｒ，  ＡＰＰ−ＭＡＣ  ＣＳ）が、端末とアクセスネットワークでサポートされるプロトコルスタック構造中に設定されてもよい。アクセスネットワークは、この新規に設定されたアプリケーション−エアインタフェース統合サブレーヤを利用して関連するアプリケーション上で分類と統合を実行する。あるいは、この機能がアクセスネットワーク内の他の装置によって実装されてもよい。
【００６８】
アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ  ＣＳ）が一連の分類器（Ｃｌａｓｓｉｆｉｅｒｓ）を規定する。分類器は、下りデータパケット内のアプリケーションデータパケットを解析し、対応するアプリケーション情報を学習し（上りのデータパケットに対しては、端末は対応するアプリケーション情報を直接学習できる）、既定の規則を利用してアプリケーション分類を確定して、ベアラを確立する際に、アプリケーション分類に従ってアプリケーションをエアインタフェース接続上にマッピングする。本発明の実施形態において、説明のために、媒体アクセス制御（ＭＡＣ）接続をエアインタフェース接続の一例とする。しかし、本発明はこれに限定されるものではなく、特定のネットワーク構造及びアプリケーションの状況によって、エアインタフェース接続がもう１つの好適な無線接続であってもよい。以下の関連する内容に関しても同じ説明が当てはまる。
【００６９】
既定の規則は、アプリケーションの種類に従って、各アプリケーションを異なる媒体アクセス制御（ＭＡＣ）接続上にマッピングするか、あるいは、そのアプリケーションのサイズと実行時間に従って、各アプリケーションを異なる媒体アクセス制御（ＭＡＣ）接続上にマッピングするか、あるいはまたいくつかの因子を結合することによって各アプリケーションを異なる媒体アクセス制御（ＭＡＣ）接続上にマッピングしてもよい。例えば、既定の規則は、インターネット・プロトコル（ＩＰ）五要素であってもよいし、あるいは、詳細なパケット検出技術を直接利用して分類と統合の機能を実現してもよい。
【００７０】
例えば図７を参照すると、映像（Ｖｉｄｅｏ）、音声（Ａｕｄｉｏ）、ストリーミング媒体、ハイパーテキスト転送（ＨＴＴＰ）サービス、ファイル転送（ＦＴＰ）サービスなどのアプリケーション種類、並びにアプリケーションに要求されるサービス品質（ＱｏＳ）仕様などのアプリケーション特性とアプリケーション識別とに従って、分類器はアプリケーションを分類し、対応する媒体アクセス制御（ＭＡＣ）接続上にアプリケーションを輸送する。媒体アクセス制御（ＭＡＣ）接続上に輸送されたアプリケーションの量に従って、アプリケーションを媒体アクセス制御（ＭＡＣ）接続上にマッピングする方法の説明に２つのケースを使用する。
【００７１】
第１のケースでは、１つの媒体アクセス制御（ＭＡＣ）接続が１つのアプリケーションにマッピングされる。
【００７２】
このケースでは、１つのアプリケーションのみが媒体アクセス制御（ＭＡＣ）接続上に輸送され、アプリケーション分類に従って、媒体アクセス制御（ＭＡＣ）接続に対応するエアインタフェース接続識別子がそのアプリケーションに直接関連付けられるか、エアインタフェース接続識別子とアクセスネットワーク内部チャネル識別子（内部チャネルがある場合）の両方がアプリケーションに関連付けられる。
【００７３】
下り方向において、アプリケーション分類に従って、アクセスネットワークがエアインタフェース接続識別子、及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに関連付け、アプリケーションデータパケットを対応するアクセスネットワーク内部チャネル識別子及び／又は媒体アクセス制御（ＭＡＣ）接続上で伝送する。上り方向においては、アプリケーション分類に従って、ユーザ設備（ＵＥ）がエアインタフェース接続識別子、及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに関連付け、対応する媒体アクセス制御（ＭＡＣ）接続、及び／又はアクセスネットワーク内部チャネル内のアプリケーションデータパケットを伝送する。
【００７４】
第２のケースでは、１つの媒体アクセス制御（ＭＡＣ）接続が複数のアプリケーションにマッピングされる。
【００７５】
このケースでは、複数のアプリケーションが媒体アクセス制御（ＭＡＣ）接続上に輸送され、媒体アクセス制御（ＭＡＣ）接続上の複数のアプリケーションの識別は、少なくとも以下の４つの方式で実装することができる。
【００７６】
「第１の方式」
【００７７】
ユーザ設備（ＵＥ）またはアクセスネットワークは接続標示識別子とアプリケーション識別子をエアインタフェース接続識別子の中に設定する。例えば、エアインタフェース接続識別子中の数ビットを接続標示識別子としてグループ化し、残りのビットをアプリケーション識別子としてグループ化する。ここで、接続標示識別子は媒体アクセス制御（ＭＡＣ）接続を輸送するために特定のインタフェースが使用されていることを示し、またアプリケーション識別子は媒体アクセス制御（ＭＡＣ）接続上に輸送された特定のアプリケーションをマッピングするために使用される。
【００７８】
「第２の方式」
【００７９】
図８Ａを参照すると、アプリケーション補助層（Ａｐｐｌｉｃａｔｉｏｎ  Ａｓｓｉｓｔａｎｔ  Ｌａｙｅｒ）がアプリケーション層と媒体アクセス制御（ＭＡＣ）層の間に追加されて、超平坦プロトコルスタックの実装を補助する。すなわち、図８Ｂに示すように、媒体アクセス制御（ＭＡＣ）ヘッダと、アプリケーションデータ及びヘッダ（Ａｐｐｌｉｃａｔｉｏｎ  Ｄａｔａ  ＆  Ｈｅａｄｅｒ）の間にアプリケーション補助ヘッダ（Ａｐｐｌｉｃａｔｉｏｎ  Ａｓｓｉｓｔａｎｔ  Ｈｅａｄｅｒ）が追加される。アプリケーション補助ヘッダは、対応するコンテキスト情報、及びアプリケーションと媒体アクセス制御（ＭＡＣ）接続との間の対応を示すために使用される。
【００８０】
「第３の方式」
図８Ｃを参照すると、無線アクセス制御ヘッダ、例えば媒体アクセス制御（ＭＡＣ）ヘッダまたは無線回線制御（ＲＬＣ）ヘッダは、拡張されて超平坦プロトコルスタックの実装を補助する。例えば、媒体アクセス制御（ＭＡＣ）ヘッダまたはＲＬＣヘッダ中の数ビットを利用して拡張識別を設定し、この拡張識別は、対応するコンテキスト情報と、アプリケーションと媒体アクセス制御（ＭＡＣ）接続の間の対応とを標示するのに利用される。
【００８１】
「第４の方式」
アクセスネットワークは、下りデータパケット上で詳細パケット検出を実行し、下りデータパケットのアプリケーションに対応する媒体アクセス制御（ＭＡＣ）接続を確定する。
【００８２】
アプリケーションンプロキシ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｘｙ）／アプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）が、アクセスネットワーク内に設定され、アプリケーションンプロキシ／アプリケーション機能は、アプリケーションデータパケット上での詳細なパケット検出の実行に利用される。アプリケーションデータパケットの解析を通してアプリケーションデータパケットの特定のデータコンテンツが検出され、アクセスネットワーク中に保持されているユーザ設備（ＵＥ）のアプリケーションコンテキスト情報と組合せることにより、このアプリケーションの媒体アクセス制御（ＭＡＣ）接続が確定される。
【００８３】
図９Ａと図９Ｂを参照することにより、本発明の実施形態において、プロトコルスタック構造中でのＡＰＰ−ＭＡＰ  ＣＳの２つの可能な位置が与えられる。図９Ａと図９Ｂにおいて、プロトコルスタック中のＡＰＰ−ＭＡＰ  ＣＳの構造の表示に、第２の方式が例として取られている。第２の方式が採用されない場合には、図９Ａと図９Ｂのアプリケーション補助層が除去されうることを理解されたい。
【００８４】
図９Ａにおいて、アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ  ＣＳ）はアプリケーション補助層の上に位置している。すなわち、アプリケーションデータパケットに対して、プロトコルスタックはまずアプリケーションデータを分類し、アプリケーションンデータを特定の媒体アクセス制御（ＭＡＣ）接続にマッピングし、そうして、そのアプリケーションに関係するリアルタイム転送プロトコル／ユーザ・データグラム・プロトコル（／伝送制御プロトコル）／インターネット・プロトコル（ＲＴＰ／ＵＤＰ（／ＴＣＰ）／ＩＰ）層のエアインタフェース伝送に必要なコンテキスト情報を読み出す。
【００８５】
図９Ｂにおいては、アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ  ＣＳ）はアプリケーション補助層の下に位置している。すなわち、アプリケーションに関係するリアルタイム転送プロトコル／ユーザ・データグラム・プロトコル（／伝送制御プロトコル）／インターネット・プロトコル（ＲＴＰ／ＵＤＰ（／ＴＣＰ）／ＩＰ）層のエアインタフェース伝送に必要なコンテキスト情報がまず読み出され、その後にアプリケーションデータが分類されて、特定の媒体アクセス制御（ＭＡＣ）接続にマッピングされる。
【００８６】
本発明の実施形態６において、本発明の実施形態で提供されるデータ伝送方法を説明するための一例としてインターネット・プロトコル／ユーザ・データグラム・プロトコル（／伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（／ＴＣＰ）／ＲＴＰ）ヘッダの除去及び復元を主として取り上げる。
【００８７】
下り方向において、アクセスネットワークはあるプロトコルスタック・ヘッダに対して、データパケット内の対応するヘッダを除去し、そのヘッダに対応するコンテキスト情報を保持する。例えば、アプリケーションプロキシ／アプリケーション機能を利用して、インターネット・プロトコル（ＩＰ）ヘッダ内の情報、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ内の情報、伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報を含むコンテキスト情報を保持する。上り方向においては、保持されたコンテキスト情報に従って、アクセスネットワークはデータパケットのヘッダを復元する、あるいはアクセスネットワークは対応するヘッダを直接生成して復元を行う。特定のアプリケーションに対しては、ネットワークアクセス過程でユーザ設備（ＵＥ）により送信された、または上り方向にユーザ設備（ＵＥ）によって送信された、第１のデータパケットのヘッダ（完全なプロトコルスタック情報を伴うヘッダ）に従って、アクセスネットワークは、高層プロトコルスタック・ヘッダを復元するために、インターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）（ＩＰ／ＵＤＰ（ＴＣＰ））に関連するコンテキスト情報を取得することも可能である。
【００８８】
各ヘッダを処理する方法を以下に説明する。
【００８９】
表２はインターネット・プロトコル（ＩＰ）ヘッダの模式的な構造図である。バージョンはデータ伝送のためのインターネット・プロトコル（ＩＰ）バージョンを示し、サイズは４ビットである。ヘッダ長はヘッダの長さの特定に利用される。サービスの種類は、データ伝送の優先順位または優先レベルの設定に利用され、サイズは８ビットである。全体長は、データグラムの全体の長さの標示に使用される。データグラムの全体長＝ヘッダ長＋データ長であり、サイズは１６ビットである。識別はすべてのセグメントの識別に使用される。サイズは１６ビットである。セグメントマークは、データグラムがセグメント化可能かを確定し、同時にそのセグメントの後にさらにセグメントが続くことを示すために使用される。サイズは３ビットである。セグメントオフセット量は全データグラム内でセグメント位置を検索するために使用される。サイズは１３ビットである。ライフタイムは、データグラムが通過可能なルータの最大数を設定するために使用される。長さは８ビットである。プロトコルはデータフィールドを生成するためのデータの上層プロトコルを示す。サイズは８ビットである。チェックサムは伝送されたデータの完全性をチェックするために使用される。サイズは１６ビットである。送信元アドレスは、送信元のインターネット・プロトコル（ＩＰ）アドレスを示す。フィールド長は３２ビットである。宛先アドレスは、宛先のインターネット・プロトコル（ＩＰ）アドレスを示す。フィールド長は３２ビットである。オプションは必須フィールドではない。そしてフィールド長は具体的には選択されたインターネット・プロトコル（ＩＰ）オプションに依存する。
【表２】
0005877160.tif 000003
【００９０】
下り方向においてインターネット・プロトコル（ＩＰ）ヘッダが除去される場合、インターネット・プロトコル（ＩＰ）ヘッダ内の情報は記録、保持され、例えば、送信元／宛先インターネット・プロトコル（ＩＰ）アドレスが記録される。既存の断片化されたインターネット・プロトコル（ＩＰ）パケット（ＩＰＩＤ情報が除去されている）は、再構成処理が必要である。上り方向では、インターネット・プロトコル（ＩＰ）ヘッダの復元過程において保持されたコンテキストに従って、送信元／宛先インターネット・プロトコル（ＩＰ）アドレスが復元される。そして必要に応じて、インターネット・プロトコル（ＩＰ）パケットに適切な断片化処理が行われる。例えば、大容量のインターネット・プロトコル（ＩＰ）パケットを同時に複数受信したとすると、アクセスネットワークはまずそれぞれのインターネット・プロトコル（ＩＰ）パケットに断片化処理を行ない、その後それを転送する。
【００９１】
表２に示す送信元／宛先インターネット・プロトコル（ＩＰ）アドレス以外の情報に関しては、受信した上りのデータパケットの特定の情報に従って、バージョン、ヘッダ長、サービス種類、全長、識別子、断片化符号、断片化オフセット量、ライフタイム、プロトコル、チェックサム、オプション、パディング、などの対応情報をアクセスネットワークは学習することができる。
【００９２】
表３はユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダの模式的な構造図である。
【表３】
0005877160.tif 000004
【００９３】
下り方向においてユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダが除去される場合、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ内の情報は記録、保持され、例えば、送信元／宛先ポート番号が記録される。上り方向では、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダの復元時に、保持された送信元／宛先ポート番号に従って送信元／宛先インターネット・プロトコル（ＩＰ）アドレスが復元される。そして受信した上りのデータパケットの特定の情報に従って、例えば表３のデータダイアグラム長とチェックサムなどの対応情報が学習される。
【００９４】
特定のアプリケーションに対しては、上りの送信元ポート番号と宛先ポート番号は下りの送信元ポート番号と宛先ポート番号の逆になっている。従って、アクセスネットワークにある、アプリケーションプロキシ／アプリケーション機能を利用して、下りのデータパケットの送信元ポート番号と宛先ポート番号をアプリケーションのコンテキストとして記録することができる。上りのアプリケーションデータパケットが受信されると、アプリケーションデータパケットのサイズに従って長さが計算され、次に  上りの宛先ポート番号＝下りの送信元ポート番号、上りの送信元ポート番号＝下りの宛先ポート番号、とすることによって、対応するユーザ・データグラム・プロトコル（ＵＤＰ）プロトコルヘッダ情報が復元される。
【００９５】
表４は伝送制御プロトコル（ＴＣＰ）ヘッダの模式的な構造図である。
【表４】
0005877160.tif 000005
【００９６】
ＵＲＧは緊急ビット、ＡＣＫは確認応答ビット、ＰＳＨはプッシュビット、ＲＳＴはリセットビット、ＳＹＮは同期ビット、ＦＩＮは終了ビット、をそれぞれ表す。
【００９７】
下り方向で伝送制御プロトコル（ＴＣＰ）ヘッダが除去された場合、下り方向の伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報は記録される。その情報としては、対応する送信元／宛先のポート番号の記録と保持、対応する上りと下りのシーケンス番号と確認応答番号の保持、及びコンテキスト情報の再送信、が含まれる。上り方向においては、伝送制御プロトコル（ＴＣＰ）ヘッダの復元時に、記録された伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報に従って伝送制御プロトコル（ＴＣＰ）ヘッダが復元される。
【００９８】
伝送制御プロトコル（ＴＣＰ）ヘッダの復元時に、ネットワーク側は必要な支援をすることが要求される。例えば、ネットワーク側は送信元／宛先のポート番号及びシーケンス番号の復元を支援する必要がある。表４中の送信元／宛先のポート番号以外の情報、例えば、シーケンス番号、確認応答番号、ヘッダ長、予約ビット、緊急ビット、確認応答ビット、プッシュビット、リセットビット、同期ビット、終了ビット、ウィンドウサイズ、チェックサム、緊急ポインタ、オプション、パディング、などの特定のコンテンツに関しては、受信した上りのデータパケットの特定の情報に従ってアクセスネットワークは学習することができる。
【００９９】
図１０は、コンテキストの保持と伝送制御プロトコル（ＴＣＰ）ヘッダの再送信機構の模式的フロー図であり、具体的には以下のステップが含まれる。
【０１００】
ステップ１：上り方向で、アプリケーション確立処理において対応する伝送制御プロトコル（ＴＣＰ）ヘッダを受信または生成した後、アクセスネットワークは伝送制御プロトコル（ＴＣＰ）ヘッダのコンテキスト情報を保持する。例えば、アクセスネットワークはアプリケーションプロキシ／アプリケーション機能を利用して伝送制御プロトコル（ＴＣＰ）プロトコルヘッダのコンテキスト情報を確立する。
【０１０１】
保持されたコンテキスト情報に従って、アクセスネットワークはデータパケットをカプセル化し、伝送制御プロトコル（ＴＣＰ）ヘッダを復元する。それには以下の方式が含まれてもよい。
【０１０２】
方式１：アプリケーションプロキシ／アプリケーション機能が、関連する伝送制御プロトコル（ＴＣＰ）コンテキストを生成して、伝送制御プロトコル（ＴＣＰ）カプセル化を実現する。
【０１０３】
そのようにして、アプリケーションプロキシ／アプリケーション機能が、送信元／宛先ポート番号、シーケンス番号初期値、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、ウィンドウサイズ、などを伝送制御プロトコル（ＴＣＰ）ヘッダ内に生成する。
【０１０４】
方式２：ユーザ設備（ＵＥ）が関連する伝送制御プロトコル（ＴＣＰ）コンテキストを生成し、伝送制御プロトコル（ＴＣＰ）カプセル化を実現する。
【０１０５】
第１の上り伝送制御プロトコル（ＴＣＰ）データパケットに対して、ユーザ設備（ＵＥ）は完全な伝送制御プロトコル（ＴＣＰ）ヘッダを送信し、アクセスネットワークは伝送制御プロトコル（ＴＣＰ）ヘッダ内に情報を記録する。そしてその情報を後続の伝送制御プロトコル（ＴＣＰ）ヘッダの復元に利用する。
【０１０６】
あるいは、アプリケーション補助層が設定され、ユーザ設備（ＵＥ）がアクセスネットワークへ、伝送制御プロトコル（ＴＣＰ）ヘッダが除去されアプリケーション補助ヘッダを含んだ伝送制御プロトコル（ＴＣＰ）データパケットを送信する。そして、送信元ポート番号、シーケンス番号初期値、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、ウィンドウサイズ等がそのアプリケーション補助ヘッダ内で搬送される。
【０１０７】
ステップ２：下り方向において、コアネットワークから伝送制御プロトコル（ＴＣＰ）データパケットを受信する際に、アクセスネットワークは、現在の送信元ポート番号、シーケンス番号、確認応答番号、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮとウィンドウサイズを記録して更新し、かつ対応する伝送制御プロトコル（ＴＣＰ）プロトコルヘッダを除去する。
【０１０８】
上り方向に関しては、伝送制御プロトコル（ＴＣＰ）ヘッダ中の確認応答番号とシーケンス番号を復元する方法を詳細に説明する。
【０１０９】
ステップ３：アクセスネットワークは、アクセスネットワーク内部チャネルとエアインタフェース上へ対応するアプリケーションデータを直接輸送し、エアインタフェース上でデータを伝送する。アプリケーションプロキシ／アプリケーション機能が伝送制御プロトコル（ＴＣＰ）再伝送とＭＡＣ  ＡＲＱ再伝送の組合せを実現しない場合には、アプリケーションプロキシ／アプリケーション機能は、現在のアプリケーションに対応するシーケンス番号（ＳＮ）を記録し、ステップ４を実行する。アプリケーションプロキシ／アプリケーション機能が伝送制御プロトコル（ＴＣＰ）再伝送とＭＡＣ  ＡＲＱ再伝送の組合せを実現する場合には、アプリケーションプロキシ／アプリケーション機能は、ユーザ設備（ＵＥ）の代わりに、ユーザの伝送制御プロトコル（ＴＣＰ）データパケットの再伝送処理を開始する。
【０１１０】
ステップ４：エアインタフェース上の自動再送要求（ＡＲＱ）ライフタイム（ｌｉｆｅｔｉｍｅ）が予定回数を越えて、関連するデータパケットからフィードバックされるＡＣＫ／ＮＡＣＫ情報により、アクセスネットワークは現在のアプリケーションのデータパケットの送信状態が成功か失敗かを確定する。ステップ４はアクセスネットワークのｅ−ＮｏｄｅＢによって実装することができる。また、ゲートウェイ（ＧＷ）によって実装されてもよい。
【０１１１】
ステップ５：ユーザ設備（ＵＥ）はエアインタフェースベアラ上のアプリケーションデータを直接カプセル化し、データをアクセスネットワークへ送信する。
【０１１２】
ステップ６：対応するＡＲＱ情報（巡回冗長検査（ＣＲＣ））に従って、アクセスネットワークは関連するアプリケーションデータパケットが正しいかどうかをチェックし、関連するＡＲＱ  ＳＮに従って、アプリケーション層データパケット中のアプリケーション層データパケットの位置を判定し、アクセスネットワークによって保持されているアプリケーションコンテキストとの組合せで現在の伝送制御プロトコル（ＴＣＰ）シーケンス番号を確定する。
【０１１３】
アプリケーションプロキシ／アプリケーション機能が伝送制御プロトコル（ＴＣＰ）再伝送とＭＡＣ  ＡＲＱ再伝送の組合せを実現する場合には、現在正しく受信されている下りのデータパケットの伝送制御プロトコル（ＴＣＰ）シーケンス番号が確認応答番号として使用される。そうでない場合には、ステップ４で記録されたアプリケーションデータパケットの伝送情報に従って、最後に正しく伝送成功したデータパケットの伝送制御プロトコル（ＴＣＰ）シーケンス番号＋伝送制御プロトコル（ＴＣＰ）データパケット負荷長／伝送制御プロトコル（ＴＣＰ）データブロック長＋１を確認応答番号に設定する。ここで、式中の伝送制御プロトコル（ＴＣＰ）シーケンス番号、伝送制御プロトコル（ＴＣＰ）データ全長、及び伝送制御プロトコル（ＴＣＰ）データブロック長は、最後に正しく伝送された下りのデータパケットの伝送制御プロトコル（ＴＣＰ）シーケンス番号、伝送制御プロトコル（ＴＣＰ）データパケット負荷長、及び伝送制御プロトコル（ＴＣＰ）データブロック長である。すなわち、確認応答番号は、伝送制御プロトコル（ＴＣＰ）シーケンス番号と、伝送制御プロトコル（ＴＣＰ）データパケット負荷長を伝送制御プロトコル（ＴＣＰ）データブロック長で割った商との合計に１を加えたものである。そうして、ユーザ設備（ＵＥ）の伝送制御プロトコル（ＴＣＰ）コンテキスト情報に従って、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、ウィンドウサイズ等が確定されて伝送制御プロトコル（ＴＣＰ）ヘッダが復元される。
【０１１４】
ステップ７：アクセスネットワークは、伝送制御プロトコル（ＴＣＰ）ヘッダが復元された伝送制御プロトコル（ＴＣＰ）データパケットをコアネットワークへ送信する。
【０１１５】
表５はリアルタイム転送プロトコル（ＲＴＰ）ヘッダの模式的な構造図である。Ｐはパディング、Ｘは拡張（Ｅｘｔｅｎｓｉｏｎ）、ＣＣは寄与セルの数（寄与送信元（ＣＳＲＣ）カウント）を表す。Ｍはマーカ（Ｍａｒｋｅｒ）を表す。同期送信元識別子と寄与送信元識別子は共存してもよいし、同期送信元識別子または寄与送信元識別子のいずれかが存在してもよい。
【表５】
0005877160.tif 000006
【０１１６】
下り方向でリアルタイム転送プロトコル（ＲＴＰ）ヘッダが除去される際、下り方向のリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報は記録され保持される。この情報には、対応する同期送信元識別子、及び／又は寄与送信元識別子が含まれる。上り方向においては、リアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元時に、記録されたリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報に従って、リアルタイム転送プロトコル（ＲＴＰ）ヘッダが復元される。
【０１１７】
リアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元時に、ネットワーク側は必要な支援をすることを要求される。例えば、ネットワーク側はタイムスタンプとシーケンス番号の復元を支援する必要がある。図１１はリアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元とコンテキスト保持の模式図である。具体的には以下のステップが含まれる。
【０１１８】
ステップ１：上り方向で、アプリケーションン確立過程において対応するリアルタイム転送プロトコル（ＲＴＰ）ヘッダを受信または生成した後、アクセスネットワークはリアルタイム転送プロトコル（ＲＴＰ）ヘッダのコンテキスト情報を保持する。例えば、アクセスネットワークはアプリケーションプロキシ／アプリケーション機能を利用してリアルタイム転送プロトコル（ＲＴＰ）プロトコルヘッダのコンテキスト情報を確立する。そして、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ中に同期送信元識別子及び／又は寄与送信元識別子を記録、保持する。
【０１１９】
保持されたコンテキスト情報に従って、アクセスネットワークはデータパケットをカプセル化し、リアルタイム転送プロトコル（ＲＴＰ）ヘッダを復元する。それには以下の方式が含まれてもよい。
【０１２０】
方式１：アプリケーションプロキシ／アプリケーション機能が、関連するリアルタイム転送プロトコル（ＲＴＰ）コンテキストを生成して、リアルタイム転送プロトコル（ＲＴＰ）カプセル化を実現する。
【０１２１】
このようにして、アプリケーションプロキシ／アプリケーション機能は、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ内にタイムスタンプとシーケンス番号などを生成する。
【０１２２】
方式２：ユーザ設備（ＵＥ）が、関連するリアルタイム転送プロトコル（ＲＴＰ）コンテキストを生成して、リアルタイム転送プロトコル（ＲＴＰ）カプセル化を実現する。
【０１２３】
第１の上りリアルタイム転送プロトコル（ＲＴＰ）データパケットに対して、ユーザ設備（ＵＥ）は完全なリアルタイム転送プロトコル（ＲＴＰ）ヘッダを送信し、アクセスネットワークはリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内に情報を記録する。そしてその情報を後続のリアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元に利用する。
【０１２４】
あるいは、アプリケーション補助層が設定され、ユーザ設備（ＵＥ）がアクセスネットワークへ、リアルタイム転送プロトコル（ＲＴＰ）ヘッダが除去されたリアルタイム転送プロトコル（ＲＴＰ）データパケットを送信する。ここでリアルタイム転送プロトコル（ＲＴＰ）データパケットにはアプリケーション補助ヘッダがあり、対応するシーケンス番号とタイムスタンプなどがアプリケーション補助ヘッダ内で搬送される。
【０１２５】
ステップ２：下り方向において、コアネットワークからリアルタイム転送プロトコル（ＲＴＰ）データパケットを受信した後に、アクセスネットワークは、現在のシーケンス番号とタイムスタンプを記録して更新する。
【０１２６】
ステップ３：アクセスネットワークはリアルタイム転送プロトコル（ＲＴＰ）プロトコルヘッダを除去し、リアルタイム転送プロトコル（ＲＴＰ）タイプを解析する。そして、復号するのにリアルタイム転送プロトコル（ＲＴＰ）情報を必要とするデータパケットに対しては、アプリケーション補助ヘッダに付属するシーケンス番号とタイムスタンプなどの情報を利用することができる。
【０１２７】
ステップ４：アクセスネットワークは、アクセスネットワーク内部チャネルとエアインタフェース上へアプリケーションデータパケット（シーケンス番号（ＳＮ）情報とタイムスタンプ情報はアプリケーション補助ヘッダに添付されていることが、任意で選択されてもよい。）を直接輸送し、そのパケットを対応するユーザ設備（ＵＥ）へ送信する。
【０１２８】
アクセスネットワークは、保持された、上り方向のリアルタイム転送プロトコル（ＲＴＰ）ヘッダのコンテキスト情報を利用してリアルタイム転送プロトコル（ＲＴＰ）ヘッダを復元する。このプロセスには以下のステップが含まれる。
【０１２９】
第１のケースでは、ユーザ設備（ＵＥ）の上りバンド幅はアクセスネットワークによる固定的な割り当てにはなっていない。すなわち、ユーザ設備（ＵＥ）が上りデータを送信する必要がある場合、ユーザ設備（ＵＥ）はアクセスネットワークへデータ送信用のバンド幅を申請する必要がある。
【０１３０】
ステップ５：リアルタイム転送プロトコル（ＲＴＰ）データパケットを生成するとき、ユーザ設備（ＵＥ）はバンド幅要求を送信する。
【０１３１】
ステップ６：ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケットを生成する期間と、バンド幅要求時間との間に差がない場合、すなわち、ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケット生成と同時にステップ５によりバンド幅要求を送信する場合には、アクセスネットワークはバンド幅要求時間に従って関連するリアルタイム転送プロトコル（ＲＴＰ）データパケットのタイムスタンプを確定する。そして、ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケットを生成する期間と、バンド幅要求時間との間に一定の差がある場合、すなわち、ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケットを生成し、一定の時間経過後にユーザ設備（ＵＥ）がステップ５によりバンド幅要求を送信する場合には、サービス確立の間にその差がネゴシエートされる。そして、アクセスネットワークはバンド幅要求時間とその差とに従ってリアルタイム転送プロトコル（ＲＴＰ）のタイムスタンプを確定する
【０１３２】
ステップ７：ユーザ設備（ＵＥ）はバンド幅要求により取得したバンド幅を利用して、エアインタフェースベアラ上で、アプリケーションデータをアクセスネットワークへ直接送信する。
【０１３３】
ステップ８：ステップ６で確定されたタイムスタンプに従って、またアプリケーションデータパケットに対応するサイズと量に従って、アクセスネットワークはシーケンス番号を確定し、かつ対応するリアルタイム転送プロトコル（ＲＴＰ）データパケットをカプセル化する。
【０１３４】
第２のケースでは、ユーザ設備（ＵＥ）の上りバンド幅がアクセスネットワークにより固定的に割り当てられている。すなわち、アクセスネットワークは、上りデータ送信のための一定の時間に従って、ユーザ設備（ＵＥ）に上りバンド幅を割り当てる。
【０１３５】
この場合、ユーザ設備（ＵＥ）はエアインタフェースベアラ上に周期的に割り当てられるバンド幅を利用して、アクセスネットワークに向けてアプリケーションデータを直接送信する（図示せず）。
【０１３６】
バンド幅の割当期間とリアルタイム転送プロトコル（ＲＴＰ）の生成期間との間に一定の差異が存在する場合には、サービスの確立時にその差異がネゴシエートされ、アクセスネットワークがバンド幅の割当期間とその差異とに従って、タイムスタンプを確定する。バンド幅の割当期間とリアルタイム転送プロトコル（ＲＴＰ）の生成期間との間に差異が存在しない場合には、アクセスネットワークがバンド幅の割当期間に従って、タイムスタンプを確定する。一方で、アプリケーションデータパケットに対応するサイズと量に従って、アクセスネットワークはシーケンス番号を確定し、かつ対応するリアルタイム転送プロトコル（ＲＴＰ）データパケットをカプセル化する。
【０１３７】
ステップ９：アクセスネットワークは対応するリアルタイム転送プロトコル（ＲＴＰ）データパケットをコアネットワークへ送信する。
【０１３８】
本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、上りのデータパケットの高層プロトコルスタック・ヘッダが復元される。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【０１３９】
本発明の実施形態７において、ネットワーク装置が提供される。図１２に示すように、ネットワーク装置には、端末向けの、高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得するように構成された、下りデータパケット取得ユニット１２１と、エアインタフェースを介して、下りデータパケット取得ユニット１２１により取得された下りデータパケットを端末へ送信するように構成された、送信ユニット１２２とが含まれる。
【０１４０】
さらに、下りデータパケット取得ユニット１２１は、第１の取得モジュール、及び／又は第２の取得モジュールを含む。
【０１４１】
第１の取得モジュールは、端末向けの、高層プロトコルスタック・ヘッダを有する下りのデータパケットを受信し、かつ下りのデータパケットから高層プロトコルスタック・ヘッダを除去して、端末向けの下りのデータパケットを取得するように構成されている。第２の取得モジュールは、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを別の端末から受信し、上りリンクのデータパケットを端末向けの下りリンクのデータパケットとして利用するように構成されている。
【０１４２】
高層プロトコルスタック・ヘッダが除去されるとき、そのヘッダに関係するコンテキスト情報は、要求に従って保持することができる。第１の取得モジュールはプロトコル情報除去ユニットをさらに含む。これは具体的にはインターネット・プロトコル（ＩＰ）ヘッダを除去し、下りの送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含むインターネット・プロトコル（ＩＰ）ヘッダ内の情報を記録、保持し、かつ断片を用いてインターネット・プロトコル（ＩＰ）パケット上で再構成処理を実行するように構成されており、及び／又は、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダを除去し、かつ下り送信元／宛先ポート番号を含むユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ中の情報を記録及び保持し、及び／又は、伝送制御プロトコル（ＴＣＰ）ヘッダを除去し、かつ下りシーケンス番号と下り送信元／宛先ポート番号を含む伝送制御プロトコル（ＴＣＰ）ヘッダ中の情報を記録及び保持し、及び／又は、リアルタイム転送プロトコル（ＲＴＰ）ヘッダを除去し、かつ同期送信元識別子及び／又は寄与送信元識別子を含むリアルタイム転送プロトコル（ＲＴＰ）ヘッダ中の情報を記録及び保持するように構成されている。
【０１４３】
この高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ、または伝送制御プロトコル（ＴＣＰ）ヘッダの内の少なくとも１つまたはその組合せを含む。
【０１４４】
さらに、ネットワーク装置は、下りデータパケットを解析して対応するアプリケーション情報を学習し、既定の規則を利用してアプリケーション分類を確定するように構成された、アプリケーション分類モジュールと、ベアラ確立時にアプリケーション分類モジュールによって確定されたアプリケーション分類に従ってアプリケーションをエアインタフェース接続にマッピングするように構成された、ベアラマッピングモジュールと、をさらに備える。
【０１４５】
ベアラマッピングモジュールは具体的に、エアインタフェース接続識別子内に、エアインタフェース接続を指示するための接続指示識別と、エアインタフェース接続に対応するアプリケーションを指示するためのアプリケーション識別とを設定するか、下りデータパケット内に、アプリケーションとエアインタフェース接続との間の対応関係を指示するアプリケーション補助ヘッダを設定するか、下りデータパケットの無線アクセス制御ヘッダ内に、アプリケーションとエアインタフェース接続との間の対応を指示する、拡張識別を設定するか、または、下りリンクデータパケット上で詳細パケット検出を実行し、下りデータパケットのアプリケーションに対応するエアインタフェース接続を確定するように構成されている。
【０１４６】
エアインタフェース接続は、少なくとも２つのアプリケーションを輸送し、このエアインタフェース接続は媒体アクセス制御（ＭＡＣ）接続であってよい。
【０１４７】
エアインタフェースが１つのアプリケーションのみを輸送する場合、ネットワーク装置のベアラマッピングモジュールは、アプリケーションをエアインタフェース接続にマッピングするために、エアインタフェース接続識別子及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに直接関連付けることができる。
【０１４８】
本発明の装置の実施形態における機能モジュールとユニットの特定の作業方式に関して、本発明の方法の実施形態を参照することができる。本発明の装置の実施形態における機能モジュールとユニットは、別々に実装可能であり、また１つまたは複数のユニットに統合することもできる。ネットワーク装置はｅ−ＮｏｄｅＢとゲートウェイ（ＧＷ）であってよいし、またアクセスネットワーク内のアプリケーションプロキシ／アプリケーション機能であってもよいし、あるいはそれらの組合せであってもよい。
【０１４９】
本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、上りのデータパケットの高層プロトコルスタック・ヘッダが復元される。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【０１５０】
本発明の実施形態８において、端末が提供される。図１３に示すように、端末は、アクセスネットワークへ送信するための、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを生成するように構成された、上りデータパケット生成ユニット１３１と、上りデータパケット生成ユニット１３１により生成された、高層プロトコルスタック・ヘッダの上りデータパケットを、エアインタフェースを介してアクセスネットワークへ送信するように構成された、データ送信ユニット１３２と、を備える。
【０１５１】
具体的には、上りデータパケット生成ユニット１３１はカプセル化モジュールを含み、このカプセル化モジュールは、以下に述べる少なくとも１つの方式またはその組合せで、アクセスネットワークへ送信する上りデータパケットを生成するように構成されている。アプリケーションデータパケットを、媒体アクセス制御（ＭＡＣ）データパケットとして直接カプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットをリアルタイム転送プロトコル（ＲＴＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットをインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットを順々にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットを順々にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットを順々にユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。
【０１５２】
さらに、端末は、既定の規則を利用して上りデータパケットに対応するアプリケーション分類を確定し、ベアラ確立時にアプリケーション分類モジュールにより確定されたアプリケーション分類に従ってアプリケーションを媒体アクセス制御のエアインタフェース接続にマッピングするように構成された、第１のベアラユニットを含む。あるいは、端末は、アクセスネットワークとネゴシエートして、アプリケーションとエアインタフェース接続との間のマッピングを確定し、そうしてアプリケーションは対応するエアインタフェース接続上に上りデータパケットを直接輸送するように構成された第２のベアラユニット、をさらに備えてもよい。この場合、特定のアプリケーションで生成されたデータパケットがすべて特定のエアインタフェース接続上に配置されている限り、アプリケーションとエアインタフェース接続との間のマッピングは、アクセスネットワークと端末の間で実行されるネゴシエーションにより確定される。
【０１５３】
エアインタフェースが１つのアプリケーションのみを輸送する場合、端末のベアラマッピングモジュールは、アプリケーションをエアインタフェース接続にマッピングするために、エアインタフェース接続識別子及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに直接関連付けることができる。
【０１５４】
下り方向に超平坦プロトコルスタック構造が採用されている場合、端末はさらに、アクセスネットワークから下りのデータパケットを受信するように構成されたデータ受信ユニットを含む。ここで、この下りのデータパケットは高層プロトコルスタック・ヘッダを持たない。
【０１５５】
本発明の装置の実施形態における機能モジュールとユニットの特定の作業方式に関して、本発明の方法の実施形態を参照することができる。本発明の装置の実施形態における機能モジュールとユニットは、別々に実装可能であり、また１つまたは複数のユニットに統合することもできる。
【０１５６】
本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送するときに、上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【０１５７】
本発明の実施形態９において、ネットワーク装置がさらに提供される。図１４に示すように、ネットワーク装置には、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信するように構成されたデータ受信ユニット１４１と、データ受信ユニット１４１により受信された、上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化するように構成された、プロトコル情報復元ユニット１４２と、プロトコル情報復元ユニット１４２により、高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送するように構成された、転送ユニット１４３と、が含まれる。
【０１５８】
プロトコル情報復元ユニット１４２は具体的には、下りの送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含む保持されたインターネット・プロトコル（ＩＰ）ヘッダ情報を利用して、上りデータパケット用のインターネット・プロトコル（ＩＰ）ヘッダをカプセル化し、要求に従って受信したインターネット・プロトコル（ＩＰ）パケット上で断片化処理を実行するか、及び／又は、下りの送信元／宛先ポート番号を含む保持されたユーザ・データグラム・プロトコル（ＵＤＰ）情報を利用して、上りデータパケット用のユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダをカプセル化するか、及び／又は、下りのシーケンス番号と下りの送信元／宛先ポート番号とを含む保持された伝送制御プロトコル（ＴＣＰ）ヘッダ情報を利用して、上りデータパケット用の伝送制御プロトコル（ＴＣＰ）ヘッダをカプセル化するか、及び／又は、同期送信元識別子及び／又は寄与送信元識別子を含む保持されたリアルタイム転送プロトコル（ＲＴＰ）ヘッダ情報を利用して上りデータパケット用のリアルタイム転送プロトコル（ＲＴＰ）ヘッダをカプセル化する、ように構成されている。
【０１５９】
本発明の装置の実施形態における機能モジュールとユニットの特定の作業方式に関して、本発明の方法の実施形態を参照することができる。本発明の装置の実施形態における機能モジュールとユニットは、別々に実装可能であり、また１つまたは複数のユニットに統合することもできる。
【０１６０】
本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、アクセスネットワークは保持されたコンテキスト情報を利用して上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【０１６１】
本発明の実施形態７及び９で提供されるネットワーク装置は、１つの装置に統合されて実装されてもよいし、個別に実装されてもよいことは理解されるであろう。ネットワーク装置と端末は、その機能のみを実装する新たに付加された装置または機能により実装されてよい。そして既存の装置または機能に、元々のシステム及びプロトコルスタック構造と互換性のあるように付加されてもよい。
【０１６２】
本発明の一実施形態はさらに通信システムを提供する。このシステムは、端末に送信するための、高層プロトコルスタック・ヘッダを持たない下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信するように構成されているか、または、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信し、その上りリンクデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、高層プロトコルスタック・ヘッダを用いてカプセル化された上りのデータパケットを転送する、ように構成された、ネットワーク装置を含んでいる。
【０１６３】
本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送するときに、アクセスネットワークが上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。
【０１６４】
本発明は、ソフトウェアに必要な汎用ハードウェアプラットフォームを加えたものにより達成されてもよいことは当業者には明らかであろう。そのような理解に基づき、本発明における技術的解決法又は従来技術への寄与を成すその一部は、ソフトウェア製品の形態で実現することができる。ソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク及び光ディスクなどの記憶媒体中に格納されてもよい。そして、ソフトウェア製品はコンピュータ設備（例えば、パーソナルコンピュータ、サーバ、ネットワーク設備）に命令を与えて本発明の実施形態または実施形態のある部分による方法を実行するための複数の命令を含む。
【０１６５】
上記の記述は単に本発明の特定の実施形態に関するものであり、本発明の保護範囲を限定するものではないことを理解されたい。本発明で開示された技術範囲から逸脱することなしに当業者によりなされる変更または置換は、本発明の保護範囲にあり、かつ本発明の保護範囲は添付の特許請求の範囲に従う。
【図１】
0005877160.tif 000007
【図２】
0005877160.tif 000008
【図３】
0005877160.tif 000009
【図４】
0005877160.tif 000010
【図５】
0005877160.tif 000011
【図６】
0005877160.tif 000012
【図７】
0005877160.tif 000013
【図８Ａ】
0005877160.tif 000014
【図８Ｂ】
0005877160.tif 000015
【図８Ｃ】
0005877160.tif 000016
【図９Ａ】
0005877160.tif 000017
【図９Ｂ】
0005877160.tif 000018
【図１０】
0005877160.tif 000019
【図１１】
0005877160.tif 000020
【図１２】
0005877160.tif 000021
【図１３】
0005877160.tif 000022
【図１４】
0005877160.tif 000023