JP2015122754A - データ伝送方法、装置及びシステム - Google Patents

Abstract

【課題】無線ネットワーク技術において、エアインタフェース伝送におけるデータ量を大幅に減少させ、伝送効率を顕著に向上させてエアインタフェースのリソースが節約できるデータ伝送の方法、装置及びシステムを提供する。【解決手段】データ伝送方法は、高層プロトコルスタック・ヘッダを持たない、端末向けの下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信する。そして、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信し５１、上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化して５２、転送を実行する５３。【選択図】図５

Description

本発明は無線ネットワーク技術に関し、特に、データ伝送方法、装置及びシステムに関する。

無線サービスに対する継続的な需要増大に伴い、データサービス、オーディオ／ビデオサービス、移動体ブログなどの様々なサービスが出現してきている。そしてこのことが、データ伝送の効率、すなわちデータ伝送の有効性に対するより高い要求をもたらしている。それと同時に、移動通信ネットワークとインターネットとの融合がより大きな注目を集めるようになってきている。

将来の無線インターネット応用においては、端末がサービスの送信元として作用する可能性はますます増大するであろう。そして、上りの伝送リソースへの需要もさらに増していくであろう。しかしながら無線周波数の資源は少なく、運用者がより多くの周波数資源を利用しようとすると、運用コストが増大する。通信データの伝送量を増やすためにより高次の変調方式を採用すると、それだけ高い信号対雑音比が必要となり、その結果として基地局及び端末により高い伝送電力が必要となる。それはエネルギー消費量を増大させることになって環境調和の通信に逆行することになる。現在のところ、エアインタフェース伝送の効率を如何に増すかが、無線サービスの発展規模制約の鍵となっている。

データサービスが無線で行われる場合、データパケット中のプロトコルスタック・ヘッダがリソースのかなりの部分を占める。この部分のリソースは実際にはユーザのアプリケーションに必要な有効データではない。図１は、無線ネットワークで行われるリアルタイム転送プロトコル（ＲＴＰ）ビデオサービスのプロトコルスタック構造を模式的に示す図である。例えば、ＩＰｖ６音声通信グループでは、ユーザが実際に必要とするペイロードは通常、グループ全体の約２２％に過ぎず、残りの大部分はプロトコルヘッダ情報である。エアインタフェース伝送の有効性を向上させるためには、無線エアインタフェースで伝送されるプロトコルデータパケットのヘッダ情報を減少させなければならない。

従来、この無線エアインタフェースで伝送されるプロトコルデータパケットのヘッダ情報を低減するために複数のヘッダ圧縮機構が提供されている。例えば、ロバストヘッダ圧縮（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ， ＲＯＨＣ）機構は、高ビットエラーと長時間遅延を持つリンクに適用可能なヘッダ圧縮機構を提供する。ＲＯＨＣ機構は、フローに基づく圧縮法である。ＲＯＨＣ機構では、特定のフローから参照グループが取り出され、それ以外のグループに対しては、参照グループと異なるヘッダ項目情報のみが送信されて、圧縮の目的を達成する。こうしてグループのヘッダのオーバヘッドを節約し、バンド幅をより効果的に利用する。同時に、ＲＯＨＣは、フィードバックメッセージの頻度と量の制御、非同期論理の検出、及びエラーチェックを通して、ＲＯＨＣ機構が確実に高効率でありかつ合理的なロバストネスを有するようにする。

本発明を実装するに当たり、従来技術には少なくとも以下の問題があることがわかった。

既存のヘッダ圧縮機構は、インターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）を対象として、層分割の概念に基づいて異なる層でのプロトコルヘッダ情報の圧縮を主に行う。そのような圧縮機構は、層間のデータの冗長性、特にアプリケーション層と他の層との間のデータの冗長性に関しては考慮せず、従って圧縮効果は非常に限定的である。また、圧縮機構は有線ネットワークに対して設計されており、無線ネットワークの特徴への配慮が欠けている。この圧縮機構を無線ネットワークに利用してインタフェース伝送の効率を向上させようとすると、期待される効果が得られず、ユーザの要求は充たされない。

従来技術における問題点を解決するために、本発明の実施形態では、エアインタフェースにより伝送されるデータ量を大幅に低減し、エアインタフェース伝送の効率を実質的に向上させ、かつエアインタフェースのリソースを節約することのできる、データ伝送方法、装置及びシステムが提供される。

その目的を達成するために、本発明の実施形態は以下の技術的解法を採用する。

本発明の一実施形態はデータ伝送方法を提供し、その方法は、端末向けの、高層プロトコルスタック・ヘッダを持たない下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信することを含む。

本発明の一実施形態は別のデータ伝送方法を提供する。その方法は、 アクセスネットワークへ送信するための、高層プロトコルスタック・ヘッダを持たない上りデータパケットを生成し、エアインタフェースを介してその上りのデータパケットを前記アクセスネットワークへ送信することを含む。

本発明の一実施形態は別のデータ伝送方法を提供する。その方法は、 端末から上りのデータパケットを受信し、その上りデータパケットは高層プロトコルスタック・ヘッダを持たず、その上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、高層プロトコルスタック・ヘッダを用いてカプセル化されたその上りデータパケットを転送することを含む。

本発明の一実施形態はネットワーク装置を提供する。この装置は、端末に送信される、高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得する下りデータパケット取得ユニットと、下りデータパケット取得ユニットにより取得された下りデータパケットを、エアインタフェースを介して端末へ送信する送信ユニットと、を備える。

本発明の一実施形態は端末を提供する。これは、高層プロトコルスタック・ヘッダを持たない上りのデータパケットをアクセスネットワークへ送信する上りデータパケット生成モジュールと、上りデータパケット生成モジュールにより生成された上りデータパケットを、エアインタフェースを介してアクセスネットワークへ送信するデータ送信ユニットと、を備える。

本発明の一実施形態は別のネットワーク装置を提供する。この装置は、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信するデータ受信ユニットと、データ受信ユニットにより受信された上りデータパケットのための、対応する高層プロトコルスタック・ヘッダをカプセル化するプロトコル情報復元ユニットと、プロトコル情報復元ユニットにより、高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送するように構成された、転送ユニットとを備える。

本発明の一実施形態はさらに通信システムを提供し、このシステムにはアクセスネットワークにあるネットワーク装置が含まれる。

このネットワーク装置は、端末に送信される、高層プロトコルスタック・ヘッダを持たない下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信するか、あるいは、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信し、その上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、その高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送する。

本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを伴う必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、アクセスネットワークが上りのデータパケットの高層プロトコルスタック・ヘッダを復元することができる。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

従来技術の無線ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）ビデオサービスのプロトコルスタック構造を模式的に示す図である。 本発明の一実施形態において提供される超平坦プロトコルスタックのアーキテクチャの模式図である。 本発明の実施形態１で提供されるデータ伝送方法の模式的フロー図である。 本発明の実施形態２で提供されるデータ伝送方法の模式的フロー図である。 本発明の実施形態３で提供されるデータ伝送方法の模式的フロー図である。 本発明の実施形態により提供される、ユーザ設備（ＵＥ）のネットワークアクセスネゴシエーションプロセスのフロー図である。 本発明の一実施形態により提供される分類器の模式図である。 本発明の一実施形態により提供されるアプリケーション補助層の模式図である。 本発明の一実施形態により提供されるアプリケーション補助ヘッダの模式図である。 本発明の一実施形態により提供される媒体アクセス制御（ＭＡＣ）ヘッダの模式図である。 本発明の一実施形態により提供されるアプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ ＣＳ）の模式図である。 本発明の一実施形態により提供される別のアプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ ＣＳ）の模式図である。 本発明の一実施形態で提供される、伝送制御プロトコル（ＴＣＰ）ヘッダのコンテキスト保持と再送信機構の模式的フロー図である。 本発明の一実施形態で提供される、リアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元とコンテキスト保持の模式的フロー図である 本発明の一実施形態により提供されるネットワーク装置の模式的構造図である。 本発明の一実施形態により提供される端末の模式的構造図である。 本発明の一実施形態により提供される別のネットワーク装置の模式的構造図である。

本発明の実施形態による技術的解法あるいは従来技術による解法をより明らかに示すために、実施形態または従来技術に関する添付の図面を以下に簡単に説明する。以下の説明において、添付の図面は本発明のいくつかの実施形態だけに関するものであり、当業者であれば創造的努力なしに添付の図面から別の図面を派生させることが可能であることは、明らかであろう。

本発明の技術的解法を以下に添付の図面を参照して、明快かつ完全に説明する。説明する実施形態は、本発明の実施形態のすべてというより、その一部分に過ぎないことは明らかである。本発明の実施形態に基づき、当業者が創造的努力なしに取得する他のすべての実施形態は、本発明の保護範囲内に含まれる。

無線ネットワークを平坦化する開発動向は、ますます顕著になってきている。例えば、ロングターム・エボリューション・ネットワーク（ＬＴＥ／ＬＴＥ＋）においては、関連する機能エンティティは発展型基地局（ｅ−ＮｏｄｅＢ）へ移行し、機能エンティティ間の接続の強化によりｅ−ＮｏｄｅＢ機能エンティティ／層の境界がぼやけてきて、無線ネットワークは超平坦プロトコルスタックを持つようになる。すなわち無線ネットワークの特性により、すべての不要なプロトコル層構造を除去することが可能となる。

本発明の実施形態の技術概念は、主として、無線ネットワークのポイント・ツー・ポイントの通信特性とネットワーク側にある端末のために保存されているコンテキストとを利用して、既存のプロトコルスタックに平坦化処理を行なうことである。端末とアクセスノードとの間が単一ホップ特性であることにより、それ以外のルーティング機構が不要である。従って、インタフェース伝送時に、不要なプロトコルヘッド情報ユニットを除去することが可能であり、その結果エアインタフェース伝送時のデータパケットサイズを大幅に低減できる。また、無線ネットワーク側のエンティティが端末のコンテキスト情報を保持しており、例えば、サービス品質（ＱｏＳ）情報／分類器情報は、インターネット・プロトコル（ＩＰ）五要素や対応するプロトコルスタック情報などの多くのプロトコルスタック関連情報を有しているので、対応するプロトコルスタック情報は無線ネットワーク側で復元される。本発明の実施形態における技術的解法によって、エアインタフェース伝送における効率が大幅に強化され、かつエアインタフェースのリソースが節約される。その結果、無線サービスの強化及び発展が促進される。

本発明の一実施形態は、無線ネットワーク側と対応する端末側に超平坦なプロトコルスタックを実現する。そのアーキテクチャの模式図を図２に示す。ここでは、エアインタフェース伝送時に、アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）層データは物理層（ＰＨＹ）と媒体アクセス制御（ＭＡＣ）層との上に直接輸送され、エアインタフェースリソースが節約される。

本発明の一実施形態で提供される通信システムにおいて、下りの伝送に関しては、コアネットワーク（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）から下りのデータパケットを受信した後、アクセスネットワーク（Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）は要求に従って、アクセスネットワークによって保持されているコンテキスト情報を更新し、データパケットのインターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）を除去し、下りのデータパケットのアプリケーションを対応するエアインタフェース接続またはエアインタフェースチャネルへマッピングし、そして、対応するコンテキスト情報を保持する。その後、アクセスネットワークは、アクセスネットワークの内部トンネルと、アクセスネットワークのエアインタフェース接続あるいはインタフェースチャネルにその下りのデータパケットを直接輸送して、その下りのデータパケットをユーザ設備（ＵＥ）へ伝送するか、あるいは、下りのデータパケットに必要な情報を付加した後に、アクセスネットワークの内部トンネルと、アクセスネットワークのエアインタフェース接続あるいはインタフェースチャネルにその下りのデータパケットを輸送し、その下りのデータパケットをユーザ設備（ＵＥ）へ伝送する。下りのデータパケットを受信した後、ユーザ設備（ＵＥ）は物理層（ＰＨＹ）と媒体アクセス制御（ＭＡＣ）ヘッダを除去し、データパケットを対応するアプリケーションへ転送する。

上りの伝送に対しては、ユーザ設備（ＵＥ）は生成された上りのデータパケットを対応するエアインタフェース接続にマッピングする。ここで上りのデータパケットは超平坦プロトコルスタックをサポートするデータパケットである。その後、ユーザ設備（ＵＥ）は、アクセスネットワークのエアインタフェースと（チャネルがある場合には）アクセスネットワークの内部チャネル上にその上りデータパケットを直接輸送して、上りデータパケットをアクセスネットワークへ伝送するか、あるいは必要な情報を付加した後に、ユーザ設備（ＵＥ）は、アクセスネットワークのエアインタフェースと（チャネルがある場合には）アクセスネットワークの内部チャネル上にその上りデータパケットを輸送して、上りデータパケットをアクセスネットワークへ伝送する。上りデータパケットを取得した後、ユーザ設備（ＵＥ）に対応するアプリケーションのコンテキスト情報に従って、アクセスネットワークは対応するプロトコルスタックデータパケットのヘッダ情報を復元または再生し、その対応情報をインターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）データパケット内にカプセル化し、データパケットを有線リンク上に輸送し、そうしてデータパケットをコアネットワークへ送信する。

エアインタフェース伝送において、ユーザ設備（ＵＥ）と基地局（ＢＳ）との間にポイント・ツー・ポイントのエアインタフェース接続が存在し、基地局（ＢＳ）とゲートウェイ（ＧａｔｅＷａｙ， ＧＷ）との間にポイント・ツー・ポイントのトンネルが存在するので、インターネット・プロトコル（ＩＰ）にルート情報を提供しなくてもよい。関連するユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）情報はアクセスネットワークによって保持されている分類器情報内に存在し、関連するデータパケットのポート情報またはそれに類するものをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）に提供しなくてもよい。端末がサービス元として作用する場合、リアルタイム転送プロトコル（ＲＴＰ）に関しては、無線スケジューリングが連続性を有しており、シーケンス番号（ＳＮ）やタイムスタンプ（ｔｉｍｅｓｔａｍｐ）などの関連情報は、予測可能である。このようにして、本発明の実施形態において、インターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ）プロトコルヘッダをエアインタフェース伝送において除去することが可能であり、結果として超平坦プロトコルスタック構造が実現される。

本発明の実施形態１にデータ伝送方法が提供され、図３に示すようにこの方法は以下のステップを含む。

ステップ３１：端末向けの下りのデータパケットを取得する。ここで、この下りのデータパケットは高層プロトコルスタック・ヘッダを持たない。

ステップ３２：エアインタフェースを介してその下りのデータパケットを端末へ送信する。

本発明の実施形態において、ステップ３１とステップ３２は、例えば、アクセスネットワーク内のｅ−ＮｏｄｅＢ、ゲートウェイ、アプリケーションプロキシ／アプリケーション機能、などのような関連するネットワーク要素や機能エンティティによって実装されてもよい。本発明の実施形態において、アクセスネットワークと端末はいずれも、下り方向のデータ伝送において超平坦プロトコルスタックをサポートすることが必要である。

ステップ３１において、アクセスネットワークは、高層プロトコルスタック・ヘッダを持ち、コアネットワークから送信された下りデータパケットを受信し、その下りデータパケットから高層プロトコルスタック・ヘッダを除去し、そしてその下りデータパケットを端末へ送信することができる。及び／又は、ローカル伝送がサポートされている場合、同一のアクセスネットワークへアクセスする２つの端末に対して、一方の端末が高層プロトコルスタック・ヘッダを持たないデータパケットをアクセスネットワークに送信し、アクセスネットワークは、データパケットを受信した後に下りデータパケットとしてもう一方の端末にそのデータパケットを送信する。

高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、伝送制御プロトコル（ＴＣＰ）ヘッダ、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダのうちの少なくとも１つまたはその組合せを含む。高層プロトコルスタック・ヘッダを除去する場合、アクセスネットワークは、要請により、インターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべてを除去するか、インターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべてを除去するか、あるいはまた、インターネット・プロトコル（ＩＰ）ヘッダだけを除去するか、またはインターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダだけを除去するか、またはインターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダだけを除去するか、などが可能である。

本発明の実施形態においては、高層プロトコルスタック・ヘッダを除去する場合、アクセスネットワークはさらに、データパケットのタイプと関連する規則に従って、高層プロトコルスタック・ヘッダに関連するコンテキスト情報を保持することができる。保持されるコンテキスト情報は主として、超平坦プロトコルをサポートする上りデータパケットの高層プロトコルスタック・ヘッダを復元するために利用される。ヘッダが異なれば対応するコンテキスト情報も異なる。

本発明の実施形態において提供される技術的解法では、無線ネットワークにおける伝送のポイント・ツ―・ポイント特性を利用して、既存のプロトコルスタックに平坦化処理を実行し、エアインタフェースを介してアクセスネットワークと端末との間で伝送されるデータパケットは、不要な高層プロトコルスタック・ヘッダを搬送する必要がない。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明の実施形態２にデータ伝送方法が提供され、図４に示すようにこの方法は以下のステップを含む。

ステップ４１：アクセスネットワーク向けの上りデータパケットを生成する。ここで、この上りデータパケットは高層プロトコルスタック・ヘッダを持たない。

ステップ４２：エアインタフェースを介してその上りのデータパケットを前記アクセスネットワークへ送信する。

本発明の実施形態２において、ステップ４１とステップ４２は、ユーザ設備（ＵＥ）などの端末によって実装することができる。本発明の実施形態において、アクセスネットワークと端末はいずれも、上り方向のデータ伝送において超平坦プロトコルスタックをサポートすることが必要である。

高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、伝送制御プロトコル（ＴＣＰ）ヘッダ、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダのうちの少なくとも１つまたはその組合せを含む。データパケットを生成する場合、端末は要求に従って、インターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべて、あるいはインターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダとリアルタイム転送プロトコル（ＲＴＰ）ヘッダのすべてを生成しなくてもよく、インターネット・プロトコル（ＩＰ）ヘッダだけを生成するか、またはインターネット・プロトコル（ＩＰ）ヘッダとユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダだけを生成するか、またはインターネット・プロトコル（ＩＰ）ヘッダと伝送制御プロトコル（ＴＣＰ）ヘッダだけを生成してもよい。

具体的には、以下に述べる少なくとも１つまたはその組合せに従って、端末は、アクセスネットワーク向けの上りのデータパケットを生成することができる。アプリケーションデータパケットを、媒体アクセス制御（ＭＡＣ）データパケットとして直接カプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットをリアルタイム転送プロトコル（ＲＴＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。ここで、「／」は「あるいは」ということを表し、アプリケーションデータパケットはまずユーザ・データグラム・プロトコル（ＵＤＰ）データパケットとしてカプセル化され、次に媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化されるか、あるいは、アプリケーションデータパケットはまず伝送制御プロトコル（ＴＣＰ）データパケットとしてカプセル化され、次に媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化される、ということである。そして、または、先ずアプリケーションデータパケットをインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。または、先ずアプリケーションデータパケットを順番にユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成する。

本発明の実施形態において提供される技術的解法では、無線ネットワークにおける伝送のポイント・ツ―・ポイント特性を利用して、既存のプロトコルスタックに平坦化処理を実行し、エアインタフェースを介してアクセスネットワークと端末との間で伝送されるデータパケットは、不要な高層プロトコルスタック・ヘッダを搬送する必要がない。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明の実施形態３においてデータ伝送方法が提供され、図５に示すようにこの方法は以下のステップを含む。

ステップ５１：端末から上りのデータパケットを受信する。ここでこの上りデータパケットは高層プロトコルスタック・ヘッダを持たない。

ステップ５２：上りデータパケット用の対応する高層プロトコルスタック・ヘッダをカプセル化する。

ステップ５３：その高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送する。

本発明の実施形態において、ステップ５１〜ステップ５３は、例えば、アクセスネットワーク内のｅ−ＮｏｄｅＢ、ゲートウェイ、アプリケーションプロキシ／アプリケーション機能、などのような関連するネットワーク要素や機能エンティティによって実装されてもよい。本発明の実施形態において、アクセスネットワークと端末はいずれも、下り方向のデータ伝送において超平坦プロトコルスタックをサポートすることが必要である。

アクセスネットワークは、例えば下りのデータパケットの伝送時に記録された、高層プロトコルスタック・ヘッダのコンテキスト情報、並びにネットワークに保持されている関連するアプリケーションのコンテキスト情報などの、高層プロトコルスタック・ヘッダのそれぞれに保持されているコンテキスト情報を利用して、高層プロトコルスタック・ヘッダを復元する。あるいは、特定のアプリケーションに対して、アクセスネットワークが対応する高層プロトコルスタック・ヘッダの情報を個別に復元することに失敗した場合、そして、端末が関連するプロトコルスタックの第１のデータパケット、例えば伝送制御プロトコル（ＴＣＰ）データパケット、を送信する場合、端末は完全な高層プロトコルスタック・ヘッダを持っているデータパケットを送信して、アクセスネットワークが高層プロトコルスタック・ヘッダの情報を学習し、後続の関連する上りのデータパケットのヘッダの復元にその情報を利用する。

本発明の実施形態において提供される技術的解法では、無線ネットワークにおける伝送のポイント・ツ―・ポイント特性を利用して、既存のプロトコルスタックに平坦化処理を実行し、エアインタフェースを介してアクセスネットワークと端末との間を伝送する際に、データパケットの不要な高層プロトコルスタック・ヘッダが除去される。データをコアネットワークへ転送する場合、アクセスネットワークが上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量を大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

要求に従って、本発明の実施形態において提供される超平坦プロトコルスタック構造が上り方向にだけ実装されるか、または本発明の実施形態において提供される超平坦プロトコルスタック構造が下り方向にだけ実装されるか、あるいは本発明の実施形態において提供される超平坦プロトコルスタック構造が上りと下りの両方向に同時に実装される可能性があることは理解されるであろう。

本発明の実施形態４において提供されるデータ伝送方法を以下に詳細に説明する。

超平坦プロトコルスタックアーキテクチャにおける正常なデータ伝送を保証するために、まず、無線アクセスネットワークは、ユーザ設備（ＵＥ）が超平坦プロトコルスタックをサポート可能であることを学習する必要があり、ユーザ設備（ＵＥ）は無線アクセスネットワークが超平坦プロトコルスタックをサポート可能であることを学習する必要がある。ここで、超平坦プロトコルスタックの能力とは、アクセスネットワークまたは端末が、不必要な高層プロトコルスタック・ヘッダ及び／又は高層プロトコルスタック・ヘッダ特定の情報の欠落を実装する仕方、をサポートする能力のことである。

本発明の実施形態において、ネットワークのアクセスプロセス中に、ユーザ設備（ＵＥ）は無線側と、ユーザ設備（ＵＥ）によりサポートされている超平坦プロトコルスタック、あるいはその超平坦プロトコルスタックに対応するプロファイル（Ｐｒｏｆｉｌｅ）に関してネゴシエートして、ユーザ設備（ＵＥ）がサポートしている超平坦プロトコルスタックの能力について無線アクセスネットワークに情報提供しなければならない。超平坦プロトコルスタックの定義が異なれば、異なるプロファイルが対応する。プロファイルは、データパケットが必ずしも保持していない高層プロトコルスタック・ヘッダと、プロファイルの適用に必要なそのほかの情報とを示す。表１にある種のプロファイルセットの例が示されている。

アクセスネットワークは、システムのブロードキャスト・メッセージを介して、サポートする超平坦プロトコルスタックをサポート可能であることをユーザ設備（ＵＥ）に通知する。例えば、ｅ−ＮｏｄｅＢは、ｅ−ＮｏｄｅＢがサポートする超平坦プロトコルスタックの能力を、システムの周期的なブロードキャスト・メッセージによってユーザ設備（ＵＥ）へ一斉同報する。また、ｅ−ＮｏｄｅＢは、ｅ−ＮｏｄｅＢがサポートする超平坦プロトコルスタックの能力を、システムメッセージ中に超平坦プロトコルスタックのサポートされるプロファイルを送ることによってユーザ設備（ＵＥ）へ一斉同報することも選択可能である。ユーザ設備（ＵＥ）はシステムのブロードキャスト・メッセージを通して、無線アクセスネットワークがサポートしていることを学習する。

図６には、ユーザ設備（ＵＥ）と無線アクセスネットワークの間のネットワークアクセスのネゴシエーション過程が詳細に示されている。ここで、説明の例としてインターネット・プロトコル／ユーザ・データグラム・プロトコル／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ／ＲＴＰ）高層プロトコルスタックを例として説明する。ただし、本発明はこのプロトコルスタック構造に限るものではない。

ステップＴ１：ｅ−ＮｏｄｅＢがシステムブロードキャスト・メッセージをユーザ設備（ＵＥ）に送信し、アクセスネットワークがサポートする超平坦プロトコルスタックの能力をユーザ設備（ＵＥ）に通知する。

ステップＴ２：ネットワークアクセス過程において、ユーザ設備（ＵＥ）は能力のネゴシエーション時に、能力ネゴシエーションメッセージを介してユーザ設備（ＵＥ）の超平坦プロトコルスタックの能力をアクセスネットワークへ通知する。ユーザ設備（ＵＥ）の能力、ユーザの加入者情報、及びその能力に従って、アクセスネットワークはユーザ設備（ＵＥ）が使用できるプロファイルセットを決定する。ここでこのプロファイルセットは１つまたは複数のプロファイルを含んでよい。

ステップ１とステップ２を通して、ユーザ設備（ＵＥ）とアクセスネットワークはお互いの超平坦プロトコルスタックの能力を学習することができる。これを基にしてユーザ設備（ＵＥ）とアクセスネットワークとの間でデータ伝送が実装される。

ステップＴ３：ネットワークアクセスの基本過程が完了すると、ユーザ設備（ＵＥ）は対応するサービスフローまたはベアラバインディング（Ｂｅａｒｅｒ Ｂｉｎｄｉｎｇ）を確立し、対応するインターネット・プロトコル（ＩＰ）アドレスを取得する。

ステップＴ４：ゲートウェイなどのアクセスネットワークは、ユーザ設備（ＵＥ）の関連するコンテキスト情報、及び、例えばユーザ設備（ＵＥ）のインターネット・プロトコル（ＩＰ）アドレスとバージョン数情報などの、特にインターネット・プロトコル（ＩＰ）プロトコル関連情報を確立する。

ステップＴ５：ユーザ設備（ＵＥ）が特定のアプリケーションの使用を必要とする場合、ユーザ設備（ＵＥ）はアプリケーション層信号を介して、コアネットワーク（または別のユーザ設備（ＵＥ））とのアプリケーションネゴシエーション確立過程を終了する。

ステップＴ６：アプリケーション確立過程において、アクセスネットワークがこのアプリケーションに関するプロトコルスタックのコンテキスト情報をまだ持ってないか、元のプロトコルスタックのコンテキスト情報が変更される場合には、アクセスネットワークは、ユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）情報などの関連するプロトコルスタック情報と、ユーザ・データグラム・プロトコル（ＵＤＰ）ポート番号や伝送制御プロトコル（ＴＣＰ）ポート番号やシーケンス番号などのユーザ設備（ＵＥ）コンテキストへのリアルタイム転送プロトコル（ＲＴＰ）情報とアプリケーション情報と、リアルタイム転送プロトコル（ＲＴＰ）タイムスタンプとシーケンス番号とを付加あるいは更新する。

ステップＴ７：アクセスネットワークは、ユーザ設備（ＵＥ）に対するアプリケーションの関連するベアラを確立し、新規作成または既存の特定のベアラにアプリケーションをバインドする。

ステップＴ８：データ伝送を実行する。ここには主に以下の過程が含まれる。

１つのコアネットワークからデータを受信する場合、アクセスネットワークは、対応する高層プロトコルスタック・ヘッダ、例えばＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰヘッダを除去し、アプリケーション層データをアクセスネットワーク内部のエアインタフェース上に直接輸送し、そしてエアインタフェースを介してそのデータをユーザ設備（ＵＥ）へ送信する。アクセスネットワークへデータを送信する場合、ユーザ設備（ＵＥ）はエアインタフェース上のアプリケーション層データを直接送信し、このアプリケーション層データはアクセスネットワーク内部を直接送信されて、ユーザ設備（ＵＥ）のコンテキスト情報とアプリケーションデータパケット情報（アプリケーションデータヘッダ情報またはアプリケーションデータ情報のいずれか）とに従って、アクセスネットワークが対応するＩＰ／ＵＤＰ（ＴＣＰ）／ＲＴＰ ヘッダを復元し、そのヘッダを対応するコアネットワークへ伝送する。

本発明の実施形態５で提供されるデータ伝送方法において、超平坦プロトコルスタック構造が採用され、アプリケーションのデータパケットはエアインタフェース接続（例えば媒体アクセス制御（ＭＡＣ）接続）上に直接輸送される。そして１つの媒体アクセス制御（ＭＡＣ）接続上には１つまたは複数のアプリケーションを輸送することができる。データの正常な伝送を保証するために、アプリケーションを対応する媒体アクセス制御（ＭＡＣ）接続上に輸送するための、アプリケーションデータの分類と統合方法が本発明の実施形態３で提供される。

アプリケーション−エアインタフェース統合サブレーヤ、例えば、アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ Ｃｏｎｖｅｒｇｅｎｃｅ Ｓｕｂｌａｙｅｒ， ＡＰＰ−ＭＡＣ ＣＳ）が、端末とアクセスネットワークでサポートされるプロトコルスタック構造中に設定されてもよい。アクセスネットワークは、この新規に設定されたアプリケーション−エアインタフェース統合サブレーヤを利用して関連するアプリケーション上で分類と統合を実行する。あるいは、この機能がアクセスネットワーク内の他の装置によって実装されてもよい。

アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ ＣＳ）が一連の分類器（Ｃｌａｓｓｉｆｉｅｒｓ）を規定する。分類器は、下りデータパケット内のアプリケーションデータパケットを解析し、対応するアプリケーション情報を学習し（上りのデータパケットに対しては、端末は対応するアプリケーション情報を直接学習できる）、既定の規則を利用してアプリケーション分類を確定して、ベアラを確立する際に、アプリケーション分類に従ってアプリケーションをエアインタフェース接続上にマッピングする。本発明の実施形態において、説明のために、媒体アクセス制御（ＭＡＣ）接続をエアインタフェース接続の一例とする。しかし、本発明はこれに限定されるものではなく、特定のネットワーク構造及びアプリケーションの状況によって、エアインタフェース接続がもう１つの好適な無線接続であってもよい。以下の関連する内容に関しても同じ説明が当てはまる。

既定の規則は、アプリケーションの種類に従って、各アプリケーションを異なる媒体アクセス制御（ＭＡＣ）接続上にマッピングするか、あるいは、そのアプリケーションのサイズと実行時間に従って、各アプリケーションを異なる媒体アクセス制御（ＭＡＣ）接続上にマッピングするか、あるいはまたいくつかの因子を結合することによって各アプリケーションを異なる媒体アクセス制御（ＭＡＣ）接続上にマッピングしてもよい。例えば、既定の規則は、インターネット・プロトコル（ＩＰ）五要素であってもよいし、あるいは、詳細なパケット検出技術を直接利用して分類と統合の機能を実現してもよい。

例えば図７を参照すると、映像（Ｖｉｄｅｏ）、音声（Ａｕｄｉｏ）、ストリーミング媒体、ハイパーテキスト転送（ＨＴＴＰ）サービス、ファイル転送（ＦＴＰ）サービスなどのアプリケーション種類、並びにアプリケーションに要求されるサービス品質（ＱｏＳ）仕様などのアプリケーション特性とアプリケーション識別とに従って、分類器はアプリケーションを分類し、対応する媒体アクセス制御（ＭＡＣ）接続上にアプリケーションを輸送する。媒体アクセス制御（ＭＡＣ）接続上に輸送されたアプリケーションの量に従って、アプリケーションを媒体アクセス制御（ＭＡＣ）接続上にマッピングする方法の説明に２つのケースを使用する。

第１のケースでは、１つの媒体アクセス制御（ＭＡＣ）接続が１つのアプリケーションにマッピングされる。

このケースでは、１つのアプリケーションのみが媒体アクセス制御（ＭＡＣ）接続上に輸送され、アプリケーション分類に従って、媒体アクセス制御（ＭＡＣ）接続に対応するエアインタフェース接続識別子がそのアプリケーションに直接関連付けられるか、エアインタフェース接続識別子とアクセスネットワーク内部チャネル識別子（内部チャネルがある場合）の両方がアプリケーションに関連付けられる。

下り方向において、アプリケーション分類に従って、アクセスネットワークがエアインタフェース接続識別子、及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに関連付け、アプリケーションデータパケットを対応するアクセスネットワーク内部チャネル識別子及び／又は媒体アクセス制御（ＭＡＣ）接続上で伝送する。上り方向においては、アプリケーション分類に従って、ユーザ設備（ＵＥ）がエアインタフェース接続識別子、及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに関連付け、対応する媒体アクセス制御（ＭＡＣ）接続、及び／又はアクセスネットワーク内部チャネル内のアプリケーションデータパケットを伝送する。

第２のケースでは、１つの媒体アクセス制御（ＭＡＣ）接続が複数のアプリケーションにマッピングされる。

このケースでは、複数のアプリケーションが媒体アクセス制御（ＭＡＣ）接続上に輸送され、媒体アクセス制御（ＭＡＣ）接続上の複数のアプリケーションの識別は、少なくとも以下の４つの方式で実装することができる。

「第１の方式」

ユーザ設備（ＵＥ）またはアクセスネットワークは接続標示識別子とアプリケーション識別子をエアインタフェース接続識別子の中に設定する。例えば、エアインタフェース接続識別子中の数ビットを接続標示識別子としてグループ化し、残りのビットをアプリケーション識別子としてグループ化する。ここで、接続標示識別子は媒体アクセス制御（ＭＡＣ）接続を輸送するために特定のインタフェースが使用されていることを示し、またアプリケーション識別子は媒体アクセス制御（ＭＡＣ）接続上に輸送された特定のアプリケーションをマッピングするために使用される。

「第２の方式」

図８Ａを参照すると、アプリケーション補助層（Ａｐｐｌｉｃａｔｉｏｎ Ａｓｓｉｓｔａｎｔ Ｌａｙｅｒ）がアプリケーション層と媒体アクセス制御（ＭＡＣ）層の間に追加されて、超平坦プロトコルスタックの実装を補助する。すなわち、図８Ｂに示すように、媒体アクセス制御（ＭＡＣ）ヘッダと、アプリケーションデータ及びヘッダ（Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ ＆ Ｈｅａｄｅｒ）の間にアプリケーション補助ヘッダ（Ａｐｐｌｉｃａｔｉｏｎ Ａｓｓｉｓｔａｎｔ Ｈｅａｄｅｒ）が追加される。アプリケーション補助ヘッダは、対応するコンテキスト情報、及びアプリケーションと媒体アクセス制御（ＭＡＣ）接続との間の対応を示すために使用される。

「第３の方式」
図８Ｃを参照すると、無線アクセス制御ヘッダ、例えば媒体アクセス制御（ＭＡＣ）ヘッダまたは無線回線制御（ＲＬＣ）ヘッダは、拡張されて超平坦プロトコルスタックの実装を補助する。例えば、媒体アクセス制御（ＭＡＣ）ヘッダまたはＲＬＣヘッダ中の数ビットを利用して拡張識別を設定し、この拡張識別は、対応するコンテキスト情報と、アプリケーションと媒体アクセス制御（ＭＡＣ）接続の間の対応とを標示するのに利用される。

「第４の方式」
アクセスネットワークは、下りデータパケット上で詳細パケット検出を実行し、下りデータパケットのアプリケーションに対応する媒体アクセス制御（ＭＡＣ）接続を確定する。

アプリケーションンプロキシ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｘｙ）／アプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）が、アクセスネットワーク内に設定され、アプリケーションンプロキシ／アプリケーション機能は、アプリケーションデータパケット上での詳細なパケット検出の実行に利用される。アプリケーションデータパケットの解析を通してアプリケーションデータパケットの特定のデータコンテンツが検出され、アクセスネットワーク中に保持されているユーザ設備（ＵＥ）のアプリケーションコンテキスト情報と組合せることにより、このアプリケーションの媒体アクセス制御（ＭＡＣ）接続が確定される。

図９Ａと図９Ｂを参照することにより、本発明の実施形態において、プロトコルスタック構造中でのＡＰＰ−ＭＡＰ ＣＳの２つの可能な位置が与えられる。図９Ａと図９Ｂにおいて、プロトコルスタック中のＡＰＰ−ＭＡＰ ＣＳの構造の表示に、第２の方式が例として取られている。第２の方式が採用されない場合には、図９Ａと図９Ｂのアプリケーション補助層が除去されうることを理解されたい。

図９Ａにおいて、アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ ＣＳ）はアプリケーション補助層の上に位置している。すなわち、アプリケーションデータパケットに対して、プロトコルスタックはまずアプリケーションデータを分類し、アプリケーションンデータを特定の媒体アクセス制御（ＭＡＣ）接続にマッピングし、そうして、そのアプリケーションに関係するリアルタイム転送プロトコル／ユーザ・データグラム・プロトコル（／伝送制御プロトコル）／インターネット・プロトコル（ＲＴＰ／ＵＤＰ（／ＴＣＰ）／ＩＰ）層のエアインタフェース伝送に必要なコンテキスト情報を読み出す。

図９Ｂにおいては、アプリケーション−媒体アクセス制御統合サブレーヤ（ＡＰＰ−ＭＡＣ ＣＳ）はアプリケーション補助層の下に位置している。すなわち、アプリケーションに関係するリアルタイム転送プロトコル／ユーザ・データグラム・プロトコル（／伝送制御プロトコル）／インターネット・プロトコル（ＲＴＰ／ＵＤＰ（／ＴＣＰ）／ＩＰ）層のエアインタフェース伝送に必要なコンテキスト情報がまず読み出され、その後にアプリケーションデータが分類されて、特定の媒体アクセス制御（ＭＡＣ）接続にマッピングされる。

本発明の実施形態６において、本発明の実施形態で提供されるデータ伝送方法を説明するための一例としてインターネット・プロトコル／ユーザ・データグラム・プロトコル（／伝送制御プロトコル）／リアルタイム転送プロトコル（ＩＰ／ＵＤＰ（／ＴＣＰ）／ＲＴＰ）ヘッダの除去及び復元を主として取り上げる。

下り方向において、アクセスネットワークはあるプロトコルスタック・ヘッダに対して、データパケット内の対応するヘッダを除去し、そのヘッダに対応するコンテキスト情報を保持する。例えば、アプリケーションプロキシ／アプリケーション機能を利用して、インターネット・プロトコル（ＩＰ）ヘッダ内の情報、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ内の情報、伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報、及びリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報を含むコンテキスト情報を保持する。上り方向においては、保持されたコンテキスト情報に従って、アクセスネットワークはデータパケットのヘッダを復元する、あるいはアクセスネットワークは対応するヘッダを直接生成して復元を行う。特定のアプリケーションに対しては、ネットワークアクセス過程でユーザ設備（ＵＥ）により送信された、または上り方向にユーザ設備（ＵＥ）によって送信された、第１のデータパケットのヘッダ（完全なプロトコルスタック情報を伴うヘッダ）に従って、アクセスネットワークは、高層プロトコルスタック・ヘッダを復元するために、インターネット・プロトコル／ユーザ・データグラム・プロトコル（伝送制御プロトコル）（ＩＰ／ＵＤＰ（ＴＣＰ））に関連するコンテキスト情報を取得することも可能である。

各ヘッダを処理する方法を以下に説明する。

表２はインターネット・プロトコル（ＩＰ）ヘッダの模式的な構造図である。バージョンはデータ伝送のためのインターネット・プロトコル（ＩＰ）バージョンを示し、サイズは４ビットである。ヘッダ長はヘッダの長さの特定に利用される。サービスの種類は、データ伝送の優先順位または優先レベルの設定に利用され、サイズは８ビットである。全体長は、データグラムの全体の長さの標示に使用される。データグラムの全体長＝ヘッダ長＋データ長であり、サイズは１６ビットである。識別はすべてのセグメントの識別に使用される。サイズは１６ビットである。セグメントマークは、データグラムがセグメント化可能かを確定し、同時にそのセグメントの後にさらにセグメントが続くことを示すために使用される。サイズは３ビットである。セグメントオフセット量は全データグラム内でセグメント位置を検索するために使用される。サイズは１３ビットである。ライフタイムは、データグラムが通過可能なルータの最大数を設定するために使用される。長さは８ビットである。プロトコルはデータフィールドを生成するためのデータの上層プロトコルを示す。サイズは８ビットである。チェックサムは伝送されたデータの完全性をチェックするために使用される。サイズは１６ビットである。送信元アドレスは、送信元のインターネット・プロトコル（ＩＰ）アドレスを示す。フィールド長は３２ビットである。宛先アドレスは、宛先のインターネット・プロトコル（ＩＰ）アドレスを示す。フィールド長は３２ビットである。オプションは必須フィールドではない。そしてフィールド長は具体的には選択されたインターネット・プロトコル（ＩＰ）オプションに依存する。

下り方向においてインターネット・プロトコル（ＩＰ）ヘッダが除去される場合、インターネット・プロトコル（ＩＰ）ヘッダ内の情報は記録、保持され、例えば、送信元／宛先インターネット・プロトコル（ＩＰ）アドレスが記録される。既存の断片化されたインターネット・プロトコル（ＩＰ）パケット（ＩＰＩＤ情報が除去されている）は、再構成処理が必要である。上り方向では、インターネット・プロトコル（ＩＰ）ヘッダの復元過程において保持されたコンテキストに従って、送信元／宛先インターネット・プロトコル（ＩＰ）アドレスが復元される。そして必要に応じて、インターネット・プロトコル（ＩＰ）パケットに適切な断片化処理が行われる。例えば、大容量のインターネット・プロトコル（ＩＰ）パケットを同時に複数受信したとすると、アクセスネットワークはまずそれぞれのインターネット・プロトコル（ＩＰ）パケットに断片化処理を行ない、その後それを転送する。

表２に示す送信元／宛先インターネット・プロトコル（ＩＰ）アドレス以外の情報に関しては、受信した上りのデータパケットの特定の情報に従って、バージョン、ヘッダ長、サービス種類、全長、識別子、断片化符号、断片化オフセット量、ライフタイム、プロトコル、チェックサム、オプション、パディング、などの対応情報をアクセスネットワークは学習することができる。

表３はユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダの模式的な構造図である。

下り方向においてユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダが除去される場合、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ内の情報は記録、保持され、例えば、送信元／宛先ポート番号が記録される。上り方向では、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダの復元時に、保持された送信元／宛先ポート番号に従って送信元／宛先インターネット・プロトコル（ＩＰ）アドレスが復元される。そして受信した上りのデータパケットの特定の情報に従って、例えば表３のデータダイアグラム長とチェックサムなどの対応情報が学習される。

特定のアプリケーションに対しては、上りの送信元ポート番号と宛先ポート番号は下りの送信元ポート番号と宛先ポート番号の逆になっている。従って、アクセスネットワークにある、アプリケーションプロキシ／アプリケーション機能を利用して、下りのデータパケットの送信元ポート番号と宛先ポート番号をアプリケーションのコンテキストとして記録することができる。上りのアプリケーションデータパケットが受信されると、アプリケーションデータパケットのサイズに従って長さが計算され、次に 上りの宛先ポート番号＝下りの送信元ポート番号、上りの送信元ポート番号＝下りの宛先ポート番号、とすることによって、対応するユーザ・データグラム・プロトコル（ＵＤＰ）プロトコルヘッダ情報が復元される。

表４は伝送制御プロトコル（ＴＣＰ）ヘッダの模式的な構造図である。

ＵＲＧは緊急ビット、ＡＣＫは確認応答ビット、ＰＳＨはプッシュビット、ＲＳＴはリセットビット、ＳＹＮは同期ビット、ＦＩＮは終了ビット、をそれぞれ表す。

下り方向で伝送制御プロトコル（ＴＣＰ）ヘッダが除去された場合、下り方向の伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報は記録される。その情報としては、対応する送信元／宛先のポート番号の記録と保持、対応する上りと下りのシーケンス番号と確認応答番号の保持、及びコンテキスト情報の再送信、が含まれる。上り方向においては、伝送制御プロトコル（ＴＣＰ）ヘッダの復元時に、記録された伝送制御プロトコル（ＴＣＰ）ヘッダ内の情報に従って伝送制御プロトコル（ＴＣＰ）ヘッダが復元される。

伝送制御プロトコル（ＴＣＰ）ヘッダの復元時に、ネットワーク側は必要な支援をすることが要求される。例えば、ネットワーク側は送信元／宛先のポート番号及びシーケンス番号の復元を支援する必要がある。表４中の送信元／宛先のポート番号以外の情報、例えば、シーケンス番号、確認応答番号、ヘッダ長、予約ビット、緊急ビット、確認応答ビット、プッシュビット、リセットビット、同期ビット、終了ビット、ウィンドウサイズ、チェックサム、緊急ポインタ、オプション、パディング、などの特定のコンテンツに関しては、受信した上りのデータパケットの特定の情報に従ってアクセスネットワークは学習することができる。

図１０は、コンテキストの保持と伝送制御プロトコル（ＴＣＰ）ヘッダの再送信機構の模式的フロー図であり、具体的には以下のステップが含まれる。

ステップ１：上り方向で、アプリケーション確立処理において対応する伝送制御プロトコル（ＴＣＰ）ヘッダを受信または生成した後、アクセスネットワークは伝送制御プロトコル（ＴＣＰ）ヘッダのコンテキスト情報を保持する。例えば、アクセスネットワークはアプリケーションプロキシ／アプリケーション機能を利用して伝送制御プロトコル（ＴＣＰ）プロトコルヘッダのコンテキスト情報を確立する。

保持されたコンテキスト情報に従って、アクセスネットワークはデータパケットをカプセル化し、伝送制御プロトコル（ＴＣＰ）ヘッダを復元する。それには以下の方式が含まれてもよい。

方式１：アプリケーションプロキシ／アプリケーション機能が、関連する伝送制御プロトコル（ＴＣＰ）コンテキストを生成して、伝送制御プロトコル（ＴＣＰ）カプセル化を実現する。

そのようにして、アプリケーションプロキシ／アプリケーション機能が、送信元／宛先ポート番号、シーケンス番号初期値、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、ウィンドウサイズ、などを伝送制御プロトコル（ＴＣＰ）ヘッダ内に生成する。

方式２：ユーザ設備（ＵＥ）が関連する伝送制御プロトコル（ＴＣＰ）コンテキストを生成し、伝送制御プロトコル（ＴＣＰ）カプセル化を実現する。

第１の上り伝送制御プロトコル（ＴＣＰ）データパケットに対して、ユーザ設備（ＵＥ）は完全な伝送制御プロトコル（ＴＣＰ）ヘッダを送信し、アクセスネットワークは伝送制御プロトコル（ＴＣＰ）ヘッダ内に情報を記録する。そしてその情報を後続の伝送制御プロトコル（ＴＣＰ）ヘッダの復元に利用する。

あるいは、アプリケーション補助層が設定され、ユーザ設備（ＵＥ）がアクセスネットワークへ、伝送制御プロトコル（ＴＣＰ）ヘッダが除去されアプリケーション補助ヘッダを含んだ伝送制御プロトコル（ＴＣＰ）データパケットを送信する。そして、送信元ポート番号、シーケンス番号初期値、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、ウィンドウサイズ等がそのアプリケーション補助ヘッダ内で搬送される。

ステップ２：下り方向において、コアネットワークから伝送制御プロトコル（ＴＣＰ）データパケットを受信する際に、アクセスネットワークは、現在の送信元ポート番号、シーケンス番号、確認応答番号、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮとウィンドウサイズを記録して更新し、かつ対応する伝送制御プロトコル（ＴＣＰ）プロトコルヘッダを除去する。

上り方向に関しては、伝送制御プロトコル（ＴＣＰ）ヘッダ中の確認応答番号とシーケンス番号を復元する方法を詳細に説明する。

ステップ３：アクセスネットワークは、アクセスネットワーク内部チャネルとエアインタフェース上へ対応するアプリケーションデータを直接輸送し、エアインタフェース上でデータを伝送する。アプリケーションプロキシ／アプリケーション機能が伝送制御プロトコル（ＴＣＰ）再伝送とＭＡＣ ＡＲＱ再伝送の組合せを実現しない場合には、アプリケーションプロキシ／アプリケーション機能は、現在のアプリケーションに対応するシーケンス番号（ＳＮ）を記録し、ステップ４を実行する。アプリケーションプロキシ／アプリケーション機能が伝送制御プロトコル（ＴＣＰ）再伝送とＭＡＣ ＡＲＱ再伝送の組合せを実現する場合には、アプリケーションプロキシ／アプリケーション機能は、ユーザ設備（ＵＥ）の代わりに、ユーザの伝送制御プロトコル（ＴＣＰ）データパケットの再伝送処理を開始する。

ステップ４：エアインタフェース上の自動再送要求（ＡＲＱ）ライフタイム（ｌｉｆｅｔｉｍｅ）が予定回数を越えて、関連するデータパケットからフィードバックされるＡＣＫ／ＮＡＣＫ情報により、アクセスネットワークは現在のアプリケーションのデータパケットの送信状態が成功か失敗かを確定する。ステップ４はアクセスネットワークのｅ−ＮｏｄｅＢによって実装することができる。また、ゲートウェイ（ＧＷ）によって実装されてもよい。

ステップ５：ユーザ設備（ＵＥ）はエアインタフェースベアラ上のアプリケーションデータを直接カプセル化し、データをアクセスネットワークへ送信する。

ステップ６：対応するＡＲＱ情報（巡回冗長検査（ＣＲＣ））に従って、アクセスネットワークは関連するアプリケーションデータパケットが正しいかどうかをチェックし、関連するＡＲＱ ＳＮに従って、アプリケーション層データパケット中のアプリケーション層データパケットの位置を判定し、アクセスネットワークによって保持されているアプリケーションコンテキストとの組合せで現在の伝送制御プロトコル（ＴＣＰ）シーケンス番号を確定する。

アプリケーションプロキシ／アプリケーション機能が伝送制御プロトコル（ＴＣＰ）再伝送とＭＡＣ ＡＲＱ再伝送の組合せを実現する場合には、現在正しく受信されている下りのデータパケットの伝送制御プロトコル（ＴＣＰ）シーケンス番号が確認応答番号として使用される。そうでない場合には、ステップ４で記録されたアプリケーションデータパケットの伝送情報に従って、最後に正しく伝送成功したデータパケットの伝送制御プロトコル（ＴＣＰ）シーケンス番号＋伝送制御プロトコル（ＴＣＰ）データパケット負荷長／伝送制御プロトコル（ＴＣＰ）データブロック長＋１を確認応答番号に設定する。ここで、式中の伝送制御プロトコル（ＴＣＰ）シーケンス番号、伝送制御プロトコル（ＴＣＰ）データ全長、及び伝送制御プロトコル（ＴＣＰ）データブロック長は、最後に正しく伝送された下りのデータパケットの伝送制御プロトコル（ＴＣＰ）シーケンス番号、伝送制御プロトコル（ＴＣＰ）データパケット負荷長、及び伝送制御プロトコル（ＴＣＰ）データブロック長である。すなわち、確認応答番号は、伝送制御プロトコル（ＴＣＰ）シーケンス番号と、伝送制御プロトコル（ＴＣＰ）データパケット負荷長を伝送制御プロトコル（ＴＣＰ）データブロック長で割った商との合計に１を加えたものである。そうして、ユーザ設備（ＵＥ）の伝送制御プロトコル（ＴＣＰ）コンテキスト情報に従って、ヘッダ長、ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ、ウィンドウサイズ等が確定されて伝送制御プロトコル（ＴＣＰ）ヘッダが復元される。

ステップ７：アクセスネットワークは、伝送制御プロトコル（ＴＣＰ）ヘッダが復元された伝送制御プロトコル（ＴＣＰ）データパケットをコアネットワークへ送信する。

表５はリアルタイム転送プロトコル（ＲＴＰ）ヘッダの模式的な構造図である。Ｐはパディング、Ｘは拡張（Ｅｘｔｅｎｓｉｏｎ）、ＣＣは寄与セルの数（寄与送信元（ＣＳＲＣ）カウント）を表す。Ｍはマーカ（Ｍａｒｋｅｒ）を表す。同期送信元識別子と寄与送信元識別子は共存してもよいし、同期送信元識別子または寄与送信元識別子のいずれかが存在してもよい。

下り方向でリアルタイム転送プロトコル（ＲＴＰ）ヘッダが除去される際、下り方向のリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報は記録され保持される。この情報には、対応する同期送信元識別子、及び／又は寄与送信元識別子が含まれる。上り方向においては、リアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元時に、記録されたリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内の情報に従って、リアルタイム転送プロトコル（ＲＴＰ）ヘッダが復元される。

リアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元時に、ネットワーク側は必要な支援をすることを要求される。例えば、ネットワーク側はタイムスタンプとシーケンス番号の復元を支援する必要がある。図１１はリアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元とコンテキスト保持の模式図である。具体的には以下のステップが含まれる。

ステップ１：上り方向で、アプリケーションン確立過程において対応するリアルタイム転送プロトコル（ＲＴＰ）ヘッダを受信または生成した後、アクセスネットワークはリアルタイム転送プロトコル（ＲＴＰ）ヘッダのコンテキスト情報を保持する。例えば、アクセスネットワークはアプリケーションプロキシ／アプリケーション機能を利用してリアルタイム転送プロトコル（ＲＴＰ）プロトコルヘッダのコンテキスト情報を確立する。そして、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ中に同期送信元識別子及び／又は寄与送信元識別子を記録、保持する。

保持されたコンテキスト情報に従って、アクセスネットワークはデータパケットをカプセル化し、リアルタイム転送プロトコル（ＲＴＰ）ヘッダを復元する。それには以下の方式が含まれてもよい。

方式１：アプリケーションプロキシ／アプリケーション機能が、関連するリアルタイム転送プロトコル（ＲＴＰ）コンテキストを生成して、リアルタイム転送プロトコル（ＲＴＰ）カプセル化を実現する。

このようにして、アプリケーションプロキシ／アプリケーション機能は、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ内にタイムスタンプとシーケンス番号などを生成する。

方式２：ユーザ設備（ＵＥ）が、関連するリアルタイム転送プロトコル（ＲＴＰ）コンテキストを生成して、リアルタイム転送プロトコル（ＲＴＰ）カプセル化を実現する。

第１の上りリアルタイム転送プロトコル（ＲＴＰ）データパケットに対して、ユーザ設備（ＵＥ）は完全なリアルタイム転送プロトコル（ＲＴＰ）ヘッダを送信し、アクセスネットワークはリアルタイム転送プロトコル（ＲＴＰ）ヘッダ内に情報を記録する。そしてその情報を後続のリアルタイム転送プロトコル（ＲＴＰ）ヘッダの復元に利用する。

あるいは、アプリケーション補助層が設定され、ユーザ設備（ＵＥ）がアクセスネットワークへ、リアルタイム転送プロトコル（ＲＴＰ）ヘッダが除去されたリアルタイム転送プロトコル（ＲＴＰ）データパケットを送信する。ここでリアルタイム転送プロトコル（ＲＴＰ）データパケットにはアプリケーション補助ヘッダがあり、対応するシーケンス番号とタイムスタンプなどがアプリケーション補助ヘッダ内で搬送される。

ステップ２：下り方向において、コアネットワークからリアルタイム転送プロトコル（ＲＴＰ）データパケットを受信した後に、アクセスネットワークは、現在のシーケンス番号とタイムスタンプを記録して更新する。

ステップ３：アクセスネットワークはリアルタイム転送プロトコル（ＲＴＰ）プロトコルヘッダを除去し、リアルタイム転送プロトコル（ＲＴＰ）タイプを解析する。そして、復号するのにリアルタイム転送プロトコル（ＲＴＰ）情報を必要とするデータパケットに対しては、アプリケーション補助ヘッダに付属するシーケンス番号とタイムスタンプなどの情報を利用することができる。

ステップ４：アクセスネットワークは、アクセスネットワーク内部チャネルとエアインタフェース上へアプリケーションデータパケット（シーケンス番号（ＳＮ）情報とタイムスタンプ情報はアプリケーション補助ヘッダに添付されていることが、任意で選択されてもよい。）を直接輸送し、そのパケットを対応するユーザ設備（ＵＥ）へ送信する。

アクセスネットワークは、保持された、上り方向のリアルタイム転送プロトコル（ＲＴＰ）ヘッダのコンテキスト情報を利用してリアルタイム転送プロトコル（ＲＴＰ）ヘッダを復元する。このプロセスには以下のステップが含まれる。

第１のケースでは、ユーザ設備（ＵＥ）の上りバンド幅はアクセスネットワークによる固定的な割り当てにはなっていない。すなわち、ユーザ設備（ＵＥ）が上りデータを送信する必要がある場合、ユーザ設備（ＵＥ）はアクセスネットワークへデータ送信用のバンド幅を申請する必要がある。

ステップ５：リアルタイム転送プロトコル（ＲＴＰ）データパケットを生成するとき、ユーザ設備（ＵＥ）はバンド幅要求を送信する。

ステップ６：ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケットを生成する期間と、バンド幅要求時間との間に差がない場合、すなわち、ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケット生成と同時にステップ５によりバンド幅要求を送信する場合には、アクセスネットワークはバンド幅要求時間に従って関連するリアルタイム転送プロトコル（ＲＴＰ）データパケットのタイムスタンプを確定する。そして、ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケットを生成する期間と、バンド幅要求時間との間に一定の差がある場合、すなわち、ユーザ設備（ＵＥ）がリアルタイム転送プロトコル（ＲＴＰ）データパケットを生成し、一定の時間経過後にユーザ設備（ＵＥ）がステップ５によりバンド幅要求を送信する場合には、サービス確立の間にその差がネゴシエートされる。そして、アクセスネットワークはバンド幅要求時間とその差とに従ってリアルタイム転送プロトコル（ＲＴＰ）のタイムスタンプを確定する

ステップ７：ユーザ設備（ＵＥ）はバンド幅要求により取得したバンド幅を利用して、エアインタフェースベアラ上で、アプリケーションデータをアクセスネットワークへ直接送信する。

ステップ８：ステップ６で確定されたタイムスタンプに従って、またアプリケーションデータパケットに対応するサイズと量に従って、アクセスネットワークはシーケンス番号を確定し、かつ対応するリアルタイム転送プロトコル（ＲＴＰ）データパケットをカプセル化する。

第２のケースでは、ユーザ設備（ＵＥ）の上りバンド幅がアクセスネットワークにより固定的に割り当てられている。すなわち、アクセスネットワークは、上りデータ送信のための一定の時間に従って、ユーザ設備（ＵＥ）に上りバンド幅を割り当てる。

この場合、ユーザ設備（ＵＥ）はエアインタフェースベアラ上に周期的に割り当てられるバンド幅を利用して、アクセスネットワークに向けてアプリケーションデータを直接送信する（図示せず）。

バンド幅の割当期間とリアルタイム転送プロトコル（ＲＴＰ）の生成期間との間に一定の差異が存在する場合には、サービスの確立時にその差異がネゴシエートされ、アクセスネットワークがバンド幅の割当期間とその差異とに従って、タイムスタンプを確定する。バンド幅の割当期間とリアルタイム転送プロトコル（ＲＴＰ）の生成期間との間に差異が存在しない場合には、アクセスネットワークがバンド幅の割当期間に従って、タイムスタンプを確定する。一方で、アプリケーションデータパケットに対応するサイズと量に従って、アクセスネットワークはシーケンス番号を確定し、かつ対応するリアルタイム転送プロトコル（ＲＴＰ）データパケットをカプセル化する。

ステップ９：アクセスネットワークは対応するリアルタイム転送プロトコル（ＲＴＰ）データパケットをコアネットワークへ送信する。

本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、上りのデータパケットの高層プロトコルスタック・ヘッダが復元される。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明の実施形態７において、ネットワーク装置が提供される。図１２に示すように、ネットワーク装置には、端末向けの、高層プロトコルスタック・ヘッダを持たない下りデータパケットを取得するように構成された、下りデータパケット取得ユニット１２１と、エアインタフェースを介して、下りデータパケット取得ユニット１２１により取得された下りデータパケットを端末へ送信するように構成された、送信ユニット１２２とが含まれる。

さらに、下りデータパケット取得ユニット１２１は、第１の取得モジュール、及び／又は第２の取得モジュールを含む。

第１の取得モジュールは、端末向けの、高層プロトコルスタック・ヘッダを有する下りのデータパケットを受信し、かつ下りのデータパケットから高層プロトコルスタック・ヘッダを除去して、端末向けの下りのデータパケットを取得するように構成されている。第２の取得モジュールは、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを別の端末から受信し、上りリンクのデータパケットを端末向けの下りリンクのデータパケットとして利用するように構成されている。

高層プロトコルスタック・ヘッダが除去されるとき、そのヘッダに関係するコンテキスト情報は、要求に従って保持することができる。第１の取得モジュールはプロトコル情報除去ユニットをさらに含む。これは具体的にはインターネット・プロトコル（ＩＰ）ヘッダを除去し、下りの送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含むインターネット・プロトコル（ＩＰ）ヘッダ内の情報を記録、保持し、かつ断片を用いてインターネット・プロトコル（ＩＰ）パケット上で再構成処理を実行するように構成されており、及び／又は、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダを除去し、かつ下り送信元／宛先ポート番号を含むユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ中の情報を記録及び保持し、及び／又は、伝送制御プロトコル（ＴＣＰ）ヘッダを除去し、かつ下りシーケンス番号と下り送信元／宛先ポート番号を含む伝送制御プロトコル（ＴＣＰ）ヘッダ中の情報を記録及び保持し、及び／又は、リアルタイム転送プロトコル（ＲＴＰ）ヘッダを除去し、かつ同期送信元識別子及び／又は寄与送信元識別子を含むリアルタイム転送プロトコル（ＲＴＰ）ヘッダ中の情報を記録及び保持するように構成されている。

この高層プロトコルスタック・ヘッダは、インターネット・プロトコル（ＩＰ）ヘッダ、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダ、リアルタイム転送プロトコル（ＲＴＰ）ヘッダ、または伝送制御プロトコル（ＴＣＰ）ヘッダの内の少なくとも１つまたはその組合せを含む。

さらに、ネットワーク装置は、下りデータパケットを解析して対応するアプリケーション情報を学習し、既定の規則を利用してアプリケーション分類を確定するように構成された、アプリケーション分類モジュールと、ベアラ確立時にアプリケーション分類モジュールによって確定されたアプリケーション分類に従ってアプリケーションをエアインタフェース接続にマッピングするように構成された、ベアラマッピングモジュールと、をさらに備える。

ベアラマッピングモジュールは具体的に、エアインタフェース接続識別子内に、エアインタフェース接続を指示するための接続指示識別と、エアインタフェース接続に対応するアプリケーションを指示するためのアプリケーション識別とを設定するか、下りデータパケット内に、アプリケーションとエアインタフェース接続との間の対応関係を指示するアプリケーション補助ヘッダを設定するか、下りデータパケットの無線アクセス制御ヘッダ内に、アプリケーションとエアインタフェース接続との間の対応を指示する、拡張識別を設定するか、または、下りリンクデータパケット上で詳細パケット検出を実行し、下りデータパケットのアプリケーションに対応するエアインタフェース接続を確定するように構成されている。

エアインタフェース接続は、少なくとも２つのアプリケーションを輸送し、このエアインタフェース接続は媒体アクセス制御（ＭＡＣ）接続であってよい。

エアインタフェースが１つのアプリケーションのみを輸送する場合、ネットワーク装置のベアラマッピングモジュールは、アプリケーションをエアインタフェース接続にマッピングするために、エアインタフェース接続識別子及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに直接関連付けることができる。

本発明の装置の実施形態における機能モジュールとユニットの特定の作業方式に関して、本発明の方法の実施形態を参照することができる。本発明の装置の実施形態における機能モジュールとユニットは、別々に実装可能であり、また１つまたは複数のユニットに統合することもできる。ネットワーク装置はｅ−ＮｏｄｅＢとゲートウェイ（ＧＷ）であってよいし、またアクセスネットワーク内のアプリケーションプロキシ／アプリケーション機能であってもよいし、あるいはそれらの組合せであってもよい。

本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、上りのデータパケットの高層プロトコルスタック・ヘッダが復元される。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明の実施形態８において、端末が提供される。図１３に示すように、端末は、アクセスネットワークへ送信するための、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを生成するように構成された、上りデータパケット生成ユニット１３１と、上りデータパケット生成ユニット１３１により生成された、高層プロトコルスタック・ヘッダの上りデータパケットを、エアインタフェースを介してアクセスネットワークへ送信するように構成された、データ送信ユニット１３２と、を備える。

具体的には、上りデータパケット生成ユニット１３１はカプセル化モジュールを含み、このカプセル化モジュールは、以下に述べる少なくとも１つの方式またはその組合せで、アクセスネットワークへ送信する上りデータパケットを生成するように構成されている。アプリケーションデータパケットを、媒体アクセス制御（ＭＡＣ）データパケットとして直接カプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットをリアルタイム転送プロトコル（ＲＴＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットをインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットを順々にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットを順々にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。または、先ずアプリケーションデータパケットを順々にユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次にそれを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りリンクデータパケットを生成する。

さらに、端末は、既定の規則を利用して上りデータパケットに対応するアプリケーション分類を確定し、ベアラ確立時にアプリケーション分類モジュールにより確定されたアプリケーション分類に従ってアプリケーションを媒体アクセス制御のエアインタフェース接続にマッピングするように構成された、第１のベアラユニットを含む。あるいは、端末は、アクセスネットワークとネゴシエートして、アプリケーションとエアインタフェース接続との間のマッピングを確定し、そうしてアプリケーションは対応するエアインタフェース接続上に上りデータパケットを直接輸送するように構成された第２のベアラユニット、をさらに備えてもよい。この場合、特定のアプリケーションで生成されたデータパケットがすべて特定のエアインタフェース接続上に配置されている限り、アプリケーションとエアインタフェース接続との間のマッピングは、アクセスネットワークと端末の間で実行されるネゴシエーションにより確定される。

エアインタフェースが１つのアプリケーションのみを輸送する場合、端末のベアラマッピングモジュールは、アプリケーションをエアインタフェース接続にマッピングするために、エアインタフェース接続識別子及び／又はアクセスネットワーク内部チャネル識別子をアプリケーションに直接関連付けることができる。

下り方向に超平坦プロトコルスタック構造が採用されている場合、端末はさらに、アクセスネットワークから下りのデータパケットを受信するように構成されたデータ受信ユニットを含む。ここで、この下りのデータパケットは高層プロトコルスタック・ヘッダを持たない。

本発明の装置の実施形態における機能モジュールとユニットの特定の作業方式に関して、本発明の方法の実施形態を参照することができる。本発明の装置の実施形態における機能モジュールとユニットは、別々に実装可能であり、また１つまたは複数のユニットに統合することもできる。

本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送するときに、上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明の実施形態９において、ネットワーク装置がさらに提供される。図１４に示すように、ネットワーク装置には、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信するように構成されたデータ受信ユニット１４１と、データ受信ユニット１４１により受信された、上りデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化するように構成された、プロトコル情報復元ユニット１４２と、プロトコル情報復元ユニット１４２により、高層プロトコルスタック・ヘッダを用いてカプセル化された上りデータパケットを転送するように構成された、転送ユニット１４３と、が含まれる。

プロトコル情報復元ユニット１４２は具体的には、下りの送信元／宛先インターネット・プロトコル（ＩＰ）アドレスを含む保持されたインターネット・プロトコル（ＩＰ）ヘッダ情報を利用して、上りデータパケット用のインターネット・プロトコル（ＩＰ）ヘッダをカプセル化し、要求に従って受信したインターネット・プロトコル（ＩＰ）パケット上で断片化処理を実行するか、及び／又は、下りの送信元／宛先ポート番号を含む保持されたユーザ・データグラム・プロトコル（ＵＤＰ）情報を利用して、上りデータパケット用のユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダをカプセル化するか、及び／又は、下りのシーケンス番号と下りの送信元／宛先ポート番号とを含む保持された伝送制御プロトコル（ＴＣＰ）ヘッダ情報を利用して、上りデータパケット用の伝送制御プロトコル（ＴＣＰ）ヘッダをカプセル化するか、及び／又は、同期送信元識別子及び／又は寄与送信元識別子を含む保持されたリアルタイム転送プロトコル（ＲＴＰ）ヘッダ情報を利用して上りデータパケット用のリアルタイム転送プロトコル（ＲＴＰ）ヘッダをカプセル化する、ように構成されている。

本発明の装置の実施形態における機能モジュールとユニットの特定の作業方式に関して、本発明の方法の実施形態を参照することができる。本発明の装置の実施形態における機能モジュールとユニットは、別々に実装可能であり、また１つまたは複数のユニットに統合することもできる。

本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送する場合、アクセスネットワークは保持されたコンテキスト情報を利用して上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明の実施形態７及び９で提供されるネットワーク装置は、１つの装置に統合されて実装されてもよいし、個別に実装されてもよいことは理解されるであろう。ネットワーク装置と端末は、その機能のみを実装する新たに付加された装置または機能により実装されてよい。そして既存の装置または機能に、元々のシステム及びプロトコルスタック構造と互換性のあるように付加されてもよい。

本発明の一実施形態はさらに通信システムを提供する。このシステムは、端末に送信するための、高層プロトコルスタック・ヘッダを持たない下りのデータパケットを取得し、エアインタフェースを介してその下りのデータパケットを端末へ送信するように構成されているか、または、高層プロトコルスタック・ヘッダを持たない上りのデータパケットを端末から受信し、その上りリンクデータパケットのための対応する高層プロトコルスタック・ヘッダをカプセル化し、高層プロトコルスタック・ヘッダを用いてカプセル化された上りのデータパケットを転送する、ように構成された、ネットワーク装置を含んでいる。

本発明の実施形態で提供される技術的解法においては、無線ネットワークにおけるポイント・ツー・ポイントの伝送特性を利用して、既存のプロトコルスタックの平坦化プロセスが実行される。従って、エアインタフェースを介してアクセスネットワークと端末との間を伝送されるデータパケットは、不必要な高層プロトコルスタック・ヘッダを搬送する必要がない。そしてアクセスネットワークがコアネットワークへデータを移送するときに、アクセスネットワークが上りのデータパケットの高層プロトコルスタック・ヘッダを復元する。本発明の実施形態における技術的解法を通して、エアインタフェース伝送におけるデータ量は大幅に減少し、エアインタフェース伝送の効率が顕著に向上してエアインタフェースのリソースが節約される。それにより、無線サービスの強化及び発展が促進され、ユーザの需要が充たされる。

本発明は、ソフトウェアに必要な汎用ハードウェアプラットフォームを加えたものにより達成されてもよいことは当業者には明らかであろう。そのような理解に基づき、本発明における技術的解決法又は従来技術への寄与を成すその一部は、ソフトウェア製品の形態で実現することができる。ソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク及び光ディスクなどの記憶媒体中に格納されてもよい。そして、ソフトウェア製品はコンピュータ設備（例えば、パーソナルコンピュータ、サーバ、ネットワーク設備）に命令を与えて本発明の実施形態または実施形態のある部分による方法を実行するための複数の命令を含む。

上記の記述は単に本発明の特定の実施形態に関するものであり、本発明の保護範囲を限定するものではないことを理解されたい。本発明で開示された技術範囲から逸脱することなしに当業者によりなされる変更または置換は、本発明の保護範囲にあり、かつ本発明の保護範囲は添付の特許請求の範囲に従う。

本願は、２００９年１１月９日に中国特許庁へ出願された、「データ伝送方法、装置及びシステム」という名称の中国特許出願第２００９１０１８０１５７．６号を基礎とした優先権を主張するものである。参照によりその内容全体がここに組み込まれる。

Claims (5)

1. コアネットワークへのアクセスを提供するアクセスネットワークに接続する端末におけるデータ伝送方法であって、
   前記アクセスネットワークへ送信するための、高層プロトコルスタック・ヘッダを持たない上りデータパケットを生成し、
   前記上りデータパケットに対応するアプリケーションを、エアインタフェース接続にマッピングし、
   マッピングされた前記エアインタフェース接続を介して前記上りデータパケットを前記アクセスネットワークへ送信する、
   ことを含み、
   前記アプリケーションをエアインタフェース接続にマッピングすることが、
   アプリケーション−エアインタフェース統合サブレーヤを設定し、前記アプリケーション−エアインタフェース統合サブレーヤを利用して、既定の規則に従って前記上りデータパケットに対応するアプリケーション分類を確定し、かつ、ベアラ確立時に、前記アプリケーション分類に従ってアプリケーションをエアインタフェース接続にマッピングするか、または、
   既定の規則を利用して前記上りデータパケットに対応するアプリケーション分類を確定し、ベアラ確立時に、前記アプリケーション分類に従ってアプリケーションをエアインタフェース接続にマッピングするか、または、
   前記アクセスネットワークとネゴシエートして、前記上りデータパケットを対応するエアインタフェース接続上に直接輸送するアプリケーションとエアインタフェース接続との間のマッピングを確定すること
   を含む、データ伝送方法。
2. 前記アクセスネットワークへ送信される前記上りデータパケットを生成することが、
   アプリケーションデータパケットを、媒体アクセス制御（ＭＡＣ）データパケットとして直接カプセル化して上りデータパケットを生成するか、または
   先ずアプリケーションデータパケットをリアルタイム転送プロトコル（ＲＴＰ）データパケットとしてカプセル化して、次に該リアルタイム転送プロトコル（ＲＴＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次に該ユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットをインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次に該インターネット・プロトコル（ＩＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次に該リアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次に該リアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットを順番にユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次に該ユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、
   の少なくとも１つまたはその組合せで行う、
   請求項１に記載のデータ伝送方法。
3. 前記エアインタフェースを介して前記上りデータパケットを前記アクセスネットワークへ送信する前に、
   前記アクセスネットワークに、端末によってサポートされる超平坦プロトコルスタック能力を標示する、能力ネゴシエーションメッセージを送信する、
   ことを更に含み、
   前記超平坦プロトコルスタック能力とは、前記アクセスネットワークが不必要な高層プロトコルスタック・ヘッダをサポートする能力、及び／又は前記高層プロトコルスタック・ヘッダの特定情報の欠落を実装する方式である、
   請求項１または請求項２に記載のデータ伝送方法。
4. コアネットワークへのアクセスを提供するアクセスネットワークに接続する端末であって、
   前記アクセスネットワークへ送信するための、高層プロトコルスタック・ヘッダを持たない上りデータパケットを生成する、上りデータパケット生成ユニットと、
   前記上りデータパケットに対応するアプリケーションを、エアインタフェース接続にマッピングする、ベアラユニットと、
   前記上りデータパケット生成ユニットにより生成された前記上りデータパケットを、マッピングされた前記エアインタフェース接続を介して前記アクセスネットワークへ送信する、データ送信ユニットと、
   を備え、
   前記エアインタフェース接続にマッピングすることが、
   アプリケーション−エアインタフェース統合サブレーヤを設定し、前記アプリケーション−エアインタフェース統合サブレーヤを利用して、既定の規則に従って前記上りデータパケットに対応するアプリケーション分類を確定し、かつ、ベアラ確立時に、前記アプリケーション分類に従ってアプリケーションをエアインタフェース接続にマッピングするか、または、
   既定の規則を利用して前記上りデータパケットに対応するアプリケーション分類を確定し、ベアラ確立時に、前記アプリケーション分類に従ってアプリケーションをエアインタフェース接続にマッピングするか、または、
   前記アクセスネットワークとネゴシエートして、前記上りデータパケットを対応するエアインタフェース接続上に直接輸送するアプリケーションとエアインタフェース接続との間のマッピングを確定すること
   を含む、端末。
5. 前記上りデータパケット生成ユニットはカプセル化モジュールを備え、
   前記カプセル化モジュールは、
   アプリケーションデータパケットを、媒体アクセス制御（ＭＡＣ）データパケットとして直接カプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットをリアルタイム転送プロトコル（ＲＴＰ）データパケットとしてカプセル化して、次に該リアルタイム転送プロトコル（ＲＴＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットをユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次に該ユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットをインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次に該インターネット・プロトコル（ＩＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットとしてカプセル化して、次に該リアルタイム転送プロトコル（ＲＴＰ）データパケット及びユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットを順番にリアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次に該リアルタイム転送プロトコル（ＲＴＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、または、
   先ずアプリケーションデータパケットを順番にユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットとしてカプセル化して、次に該ユーザ・データグラム・プロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）データパケット及びインターネット・プロトコル（ＩＰ）データパケットを媒体アクセス制御（ＭＡＣ）データパケットとしてカプセル化して上りデータパケットを生成するか、
   の少なくとも１つの方式またはその組合せで、前記アクセスネットワークへ送信する前記上りデータパケットを生成する、
   請求項４に記載の端末。