特許 6643542 データパケットの送信方法、受信方法、送信装置及び受信装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6643542

(24)【登録日】2020年1月9日

(45)【発行日】2020年2月12日

(54)【発明の名称】データパケットの送信方法、受信方法、送信装置及び受信装置

(51)【国際特許分類】

   H04L 12/951 20130101AFI20200130BHJP

   H04W 4/70 20180101ALI20200130BHJP

   H04W 76/10 20180101ALI20200130BHJP

【ＦＩ】

   H04L12/951

   H04W4/70

   H04W76/10

【請求項の数】7

【全頁数】25

(21)【出願番号】特願2018-540158(P2018-540158)

(86)(22)【出願日】2016年8月30日

(65)【公表番号】特表2019-506807(P2019-506807A)

(43)【公表日】2019年3月7日

(86)【国際出願番号】CN2016097357

(87)【国際公開番号】WO2017133234

(87)【国際公開日】20170810

【審査請求日】2018年9月12日

(31)【優先権主張番号】201610078138.2

(32)【優先日】2016年2月3日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(74)【代理人】

【識別番号】110001427

【氏名又は名称】特許業務法人前田特許事務所

(72)【発明者】

【氏名】チャン ルー

【審査官】 玉木 宏治

(56)【参考文献】

【文献】 特開昭６３−１９７１４８（ＪＰ，Ａ）

【文献】 特開昭６１−２９６８３８（ＪＰ，Ａ）

【文献】 特開２００２−００９８３２（ＪＰ，Ａ）

【文献】 特開２０１５−１５９４９５（ＪＰ，Ａ）

【文献】 特表２０１５−５２５０１７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００−９５５

Ｈ０４Ｗ ４／７０

Ｈ０４Ｗ ７６／１０

(57)【特許請求の範囲】

【請求項1】

データパケットの送信方法であって、
サーバへの送信待ちの第一のデータパケットを確定することと、
前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約することと、
前記第二のデータパケットを前記サーバに送信することとを含み、
２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約することは、
２つ以上の前記第一のデータパケットのソースインターネットプロトコル（ＩＰ）アドレスをいずれも所定のＩＰアドレスに変換することと、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約し、前記第二のデータパケットのソースアドレスを前記所定のＩＰアドレスと設定することとを含み、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約することは、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填することを含み、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填することは、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける同じ長さの異なるデータフィールドに充填することを含み、ここで、
前記第一のデータパケット内のデータが充填されたデータフィールドに、
前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報が含まれ、又は同時に前記第一のデータパケット内のデータの長さを識別するための第一の識別情報、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報、充填ビットが含まれ、前記充填ビットが、前記第一のデータパケット内のデータの長さが前記データフィールドの長さより小さい場合、前記データフィールドにおける、前記第一のデータパケット内のデータを充填していない部分を充填することに用いられることを特徴とする
データパケットの送信方法。

【請求項2】

データパケットの受信方法であって、
端末からの第二のデータパケットを受信することと、
前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得することとを含み、
前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の前記第一のデータパケットを取得することは、
前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定することと、
確定された前記長さに基づいて各データフィールドに充填される前記第一のデータパケット内のデータを取得することとを含み、
前記第二のデータパケットにおける２つ以上のデータフィールドを解析した後、前記データパケットの受信方法はさらに、
解析された前記データフィールドに含まれる第二の識別情報に基づいて前記第一のデータパケットの変換前のソースＩＰアドレスを確定することを含み、前記第二の識別情報が前記第一のデータパケットの変換前のソースＩＰアドレスを識別することに用いられることを特徴とする
データパケットの受信方法。

【請求項3】

前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定することは、
前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、解析された前記データフィールドに含まれる第一の識別情報に基づいて各データフィールドに充填される第一のデータパケット内のデータの長さを確定することを含み、前記第一の識別情報が前記第一のデータパケット内のデータの長さを識別することに用いられることを特徴とする
請求項２に記載のデータパケットの受信方法。

【請求項4】

データパケットの送信装置であって、
サーバへの送信待ちの第一のデータパケットを確定するように構成される第一の確定モジュールと、
前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約するように構成される集約モジュールと、
前記第二のデータパケットを前記サーバに送信するように構成される第一の送信モジュールとを含み、
前記集約モジュールは、
２つ以上の前記第一のデータパケットのソースインターネットプロトコル（ＩＰ）アドレスをいずれも所定のＩＰアドレスに変換するように構成される変換ユニットと、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約し、前記第二のデータパケットのソースアドレスを前記所定のＩＰアドレスと設定するように構成される集約ユニットとを含み、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約する場合、前記集約ユニットは、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填するように構成される充填サブユニットを含み、
前記充填サブユニットは、
ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける同じ長さの異なるデータフィールドに充填するように構成される充填セカンダリサブユニットを含み、ここで、
前記第一のデータパケット内のデータが充填されたデータフィールドに、
前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報が含まれ、又は同時に前記第一のデータパケット内のデータの長さを識別するための第一の識別情報、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報、充填ビットが含まれ、前記充填ビットが、前記第一のデータパケット内のデータの長さが前記データフィールドの長さより小さい場合、前記データフィールドにおける、前記第一のデータパケット内のデータを充填していない部分を充填することに用いられることを特徴とする
データパケットの送信装置。

【請求項5】

データパケットの受信装置であって、
端末からの第二のデータパケットを受信するように構成される受信モジュールと、
前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得するように構成される取得モジュールとを含み、
前記取得モジュールは、
前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定するように構成される第一の確定ユニットと、
確定された前記長さに基づいて各データフィールドに充填される前記第一のデータパケット内のデータを取得するように構成される取得ユニットとを含み、
前記データパケットの受信装置はさらに、
前記第二のデータパケットにおける２つ以上のデータフィールドを解析した後、解析された前記データフィールドに含まれる第二の識別情報に基づいて前記第一のデータパケットの変換前のソースＩＰアドレスを確定するように構成される第二の確定ユニットを含み、前記第二の識別情報が前記第一のデータパケットの変換前のソースＩＰアドレスを識別することに用いられることを特徴とする
データパケットの受信装置。

【請求項6】

前記第一の確定ユニットは、
前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、解析された前記データフィールドに含まれる第一の識別情報に基づいて各データフィールドに充填される第一のデータパケット内のデータの長さを確定するように構成される確定サブユニットを含み、前記第一の識別情報が前記第一のデータパケット内のデータの長さを識別することに用いられることを特徴とする
請求項５に記載のデータパケットの受信装置。

【請求項7】

コンピュータ可読記憶媒体であって、コンピュータ実行可能命令が記憶され、前記コンピュータ実行可能命令が請求項１に記載のデータパケットの送信方法、及び／又は請求項２又は３に記載のデータパケットの受信方法を実行することに用いられる前記コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施例は通信分野に関するがこれに限定されず、特にデータパケットの送信方法、受信方法、送信装置及び受信装置に関する。

【背景技術】

【0002】

科技の発展に伴い、インターネットが人々の生活の中でますます重要な役割を果たし、現在のネットワーク時代では、ネットワークを用いて複数のタイプのデータを伝送することができる。データ伝送過程では、様々な理由で、トラフィックを制限する必要があり、トラフィックの制限方面において、データ伝送ソフトウェア及び関連するインターネット製品に用いられる基本ポリシーはリーキーバケット及びトークンバケットポリシーを含む。リーキーバケットアルゴリズムは、リーキーバケットアルゴリズムによりネットワークに安定したトラフィックを提供するように、バーストトラフィックが整形されることができるというメカニズムを提供する。リーキーバケットは一定のサービス時間を有する単一サーバキューと見なしてもよく、リーキーバケット（パケットキャッシュ）がオーバーフローした場合、データパケットは破棄される。リーキーバケットアルゴリズムの主な目的は、データがネットワークに流入されるレートを制御し、ネットワーク上のバーストトラフィックを平滑化することである。

【0003】

トークンバケットポリシーの原理は、システムがトークンを一定の速度でバケットに入れ、リクエストが処理される必要がある場合、まずバケットから一つのトークンを取得する必要があり、バケットにトークンがない場合、サービスを拒否する。トークンバケットのもう一つの利点は、速度を容易に変更できることである。レートを上げる必要がある場合、バケットに入れたトークンのレートを必要に応じて上げる。

【0004】

リーキーバケットの漏出レートが固定パラメータであるので、ネットワークにリソース衝突が存在しなくても（輻輳が発生しなくても）、リーキーバケットアルゴリズムはある単独のストリームをポートレートにバーストさせることができない。したがって、いくつかの場合で、リーキーバケットアルゴリズムはネットワークリソースを効果的に使用することができない。リーキーバケットアルゴリズムの本質的な目的はレートを滑らかに維持することであり、バースト性があるトラフィックに対して効率が欠けている。

【0005】

トークンバケットアルゴリズムはこれらのようなバースト性があるトラフィックを満たすことができる。しかし、トークンバケットアルゴリズムにも限界性があり、まず、トークンバケットアルゴリズムはリーキーバケットアルゴリズムと同様に、キュー記憶を実現するために、大きなバッファエリアを必要とするため、パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ、ＰＣと略称）ソフトウェア及びインターネットサイトなどのより大きなシステムでの実行により適し、次に、トークンバケットアルゴリズムの主な目的はレートリミットとトラフィックシェーピングであり、バケットにトークンが存在しない場合に対する詳細な説明がされていないため、ネットワークが短時間で高いトラフィックを維持する必要がある場合、パケットロス率は依然として伝送品質に影響する要因の一つであり、帯域幅利用率が高くない。また、リーキーバケットに対して、トークンバケットは、ある短時間でしかバーストトラフィックを許可することができず、その本質が依然としてトラフィック「レートリミットとトラフィックシェーピング」であり、レート機能を上げることになっていない。データチャネル製品に一つの重要な課題、即ち同時送信レートがあり、アップリンク及びダウンリンク伝送を同時に行う場合、そのアップリンク、ダウンリンクのレートは、通常アップリンク、ダウンロードを個別に行う時の単独レートまで達することができないことが多い。上記のリーキーバケットアルゴリズムとトークンバケットアルゴリズムのいずれも、アップリンク及びダウンリンクレートがアップリンク、ダウンロードを個別に行う時の単独レートに達することができないという問題を解決することができない。

【0006】

そして、データパケットをアップリンクで送信する場合、データパケットは複数の層で処理され、モノのインターネット（マシンタイプ通信（Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、ＭＴＣと略称）とも呼ばれる）におけるデータ伝送を例とし、アップリンクで伝送されるデータパケットは、無線プロトコルスタックのパケットデータコンバージェンスプロトコル層（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ、ＰＤＣＰと略称）、無線リンク制御（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ、ＲＬＣと略称）、メディアアクセス制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、ＭＡＣと略称）、物理層などを経由して、層ごとに処理され、小さなパケットに対して、パケット全体の大きさに対するそのデータボリュームの割合がそもそも大きくなく、各データパケットのヘッダーが層ごとに処理されると、無線プロトコルスタックの動作効率が低くなり、データ伝送が遅くなる問題が生じる。

【0007】

関連技術に存在する上記のデータ伝送が遅いという問題に対して、有効な解決策が現在まで提案されていない。

【発明の概要】

【発明が解決しようとする課題】

【0008】

本発明の実施例は、関連する技術に存在するデータ伝送が遅いという問題を少なくとも解決するように、データパケットの送信方法、受信方法、送信装置及び受信装置を提供する。

【課題を解決するための手段】

【0009】

本発明の実施例の一態様によるデータパケットの送信方法は、サーバへの送信待ちの第一のデータパケットを確定することと、前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約することと、前記第二のデータパケットを前記サーバに送信することとを含む。

【0010】

選択可能に、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約することは、２つ以上の前記第一のデータパケットのソースインターネットプロトコル（ＩＰ）アドレスをいずれも所定のＩＰアドレスに変換することと、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約し、前記第二のデータパケットのソースアドレスを前記所定のＩＰアドレスと設定することとを含む。

【0011】

選択可能に、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約することは、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填することを含む。

【0012】

選択可能に、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填することは、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける同じ長さの異なるデータフィールドに充填し、ここで、前記第一のデータパケット内のデータが充填されたデータフィールドに、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報が含まれ、又は同時に前記第一のデータパケット内のデータの長さを識別するための第一の識別情報、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報、充填ビットが含まれ、前記充填ビットが、前記第一のデータパケット内のデータの長さが前記データフィールドの長さより小さい場合、前記データフィールドにおける、前記第一のデータパケット内のデータを充填していない部分を充填することに用いられることを含む。

【0015】

本発明の実施例の別の態様によるデータパケットの受信方法は、端末からの第二のデータパケットを受信することと、前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得することとを含む。

【0016】

選択可能に、前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の前記第一のデータパケットを取得することは、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定することと、確定された前記長さに基づいて各データフィールドに充填される前記第一のデータパケット内のデータを取得することとを含む。

【0017】

選択可能に、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定することは、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、解析された前記データフィールドに含まれる第一の識別情報に基づいて各データフィールドに充填される第一のデータパケット内のデータの長さを確定し、前記第一の識別情報が前記第一のデータパケット内のデータの長さを識別することに用いられることを含む。

【0018】

選択可能に、前記第二のデータパケットにおける２つ以上のデータフィールドを解析した後、前記方法はさらに、解析された前記データフィールドに含まれる第二の識別情報に基づいて前記第一のデータパケットの変換前のソースＩＰアドレスを確定し、前記第二の識別情報が前記第一のデータパケットの変換前のソースＩＰアドレスを識別することに用いられることを含む。

【0019】

本発明の実施例の別の態様によるデータパケットの送信装置は、サーバへの送信待ちの第一のデータパケットを確定するように構成される第一の確定モジュールと、前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約するように構成される集約モジュールと、前記第二のデータパケットを前記サーバに送信するように構成される第一の送信モジュールとを備える。

【0020】

選択可能に、前記集約モジュールは、２つ以上の前記第一のデータパケットのソースインターネットプロトコル（ＩＰ）アドレスをいずれも所定のＩＰアドレスに変換するように構成される変換ユニットと、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約し、前記第二のデータパケットのソースアドレスを前記所定のＩＰアドレスと設定するように構成される集約ユニットとを含む。

【0021】

選択可能に、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約する場合、前記集約ユニットは、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填するように構成される充填サブユニットを含む。

【0022】

選択可能に、前記充填サブユニットは、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける同じ長さの異なるデータフィールドに充填するように構成され、ここで、前記第一のデータパケット内のデータが充填されたデータフィールドに、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報が含まれ、又は同時に前記第一のデータパケット内のデータの長さを識別するための第一の識別情報、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報、充填ビットが含まれ、前記充填ビットが、前記第一のデータパケット内のデータの長さが前記データフィールドの長さより小さい場合、前記データフィールドにおける、前記第一のデータパケット内のデータを充填していない部分を充填することに用いられる充填セカンダリサブユニットを含む。

【0025】

本発明の実施例の別の態様によるデータパケットの受信装置は、端末からの第二のデータパケットを受信するように構成される受信モジュールと、前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得するように構成される取得モジュールとを備える。

【0026】

選択可能に、前記取得モジュールは、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定するように構成される第一の確定ユニットと、確定された前記長さに基づいて各データフィールドに充填される前記第一のデータパケット内のデータを取得するように構成される取得ユニットとを含む。

【0027】

選択可能に、前記第一の確定ユニットは、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、解析される前記データフィールドに含まれる第一の識別情報に基づいて各データフィールドに充填される第一のデータパケット内のデータの長さを確定するように構成され、前記第一の識別情報が前記第一のデータパケット内のデータの長さを識別することに用いられる確定サブユニットを含む。

【0028】

選択可能に、前記装置はさらに、前記第二のデータパケットにおける２つ以上のデータフィールドを解析した後、解析された前記データフィールドに含まれる第二の識別情報に基づいて前記第一のデータパケットの変換前のソースＩＰアドレスを確定するように構成され、前記第二の識別情報が前記第一のデータパケットの変換前のソースＩＰアドレスを識別することに用いられる第二の確定ユニットを備える。

【0029】

本発明の実施例の別の態様によるコンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体にコンピュータ実行可能命令が記憶され、前記コンピュータ実行可能命令が上記いずれかの方法を実行することに用いられる。

【0030】

本発明の実施例によって提供される技術的解決手段によれば、サーバへの送信待ちの第一のデータパケットを確定し、前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約し、前記第二のデータパケットを前記サーバに送信する。これにより、関連技術に存在するデータ伝送が遅いという問題を解決し、さらにデータ伝送速度を向上させる効果を達成する。

【0031】

本発明の実施例の他の特徴と利点は以下の明細書に説明され、且つ、一部は明細書から明らかになり、又は本発明を実施することで理解される。本発明の目的及び他の利点は、明細書、特許請求の範囲及び図面において特に示された構造によって実現及び取得されてもよい。

【0032】

図面と詳細な説明を読んで理解することによってその他の点も明らかになる。

【図面の簡単な説明】

【0033】

【図1】本発明の実施例による第一のデータパケットの送信方法のフローチャートである。

【図2】本発明の実施例による第二のデータパケットの送信方法のフローチャートである。

【図3】本発明の実施例によるデータパケットの受信方法のフローチャートである。

【図4】本発明の実施例による第一のデータパケットの送信装置の構成ブロック図である。

【図5】本発明の実施例による第一のデータパケットの送信装置における集約モジュール４４の構成ブロック図である。

【図6】本発明の実施例による第一のデータパケットの送信装置における集約ユニット５４の構成ブロック図である。

【図7】本発明の実施例による第一のデータパケットの送信装置における充填サブユニット６２の構成ブロック図である。

【図8】本発明の実施例による第二のデータパケットの送信装置の構成ブロック図である。

【図9】本発明の実施例による第二のデータパケットの送信装置における第二の送信モジュール８４の構成ブロック図である。

【図10】本発明の実施例によるデータパケットの受信装置の構成ブロック図である。

【図11】本発明の実施例によるデータパケットの受信装置における取得モジュール１０４の構成ブロック図である。

【図12】本発明の実施例によるデータパケットの受信装置における第一の確定ユニット１１２の構成ブロック図である。

【図13】本発明の実施例によるデータパケットの受信装置における取得モジュール１０４の好ましい構成ブロック図である。

【図14】本発明の実施例によるパケット集約方法のフローチャートである。

【図15】本発明の実施例によるパケット集約解除のフローチャートである。

【図16】本発明の実施例によるＡＣＫをシグナリングにより伝送する方法のフローチャートである。

【図17】本発明の実施例によるトラフィック調整モジュールの具体的な動作のフローチャートである。

【発明を実施するための形態】

【0034】

ここで説明された図面は本発明のさらなる理解を提供することに用いられ、本出願の一部を構成し、本発明の例示的な実施例及びその説明は、本発明を解釈することに用いられるが、本発明を限定するものではない。図面は上記のとおりである。

【0035】

以下に図面を参照し且つ実施例と組み合わせて本発明を詳細に説明する。説明すべきものとして、矛盾しない場合で、本出願における実施例及び実施例における特徴は相互に組み合わせられてもよい。

【0036】

説明すべきものとして、本発明の明細書及び特許請求の範囲並び上記図面における用語「第一」、「第二」などは、類似の対象を区別することに用いられ、必ずしも特定の順序又は順番を記述することに用いられるものではない。

【0037】

本実施例においてデータパケットの送信方法が提供され、図１は本発明の実施例による第一のデータパケットの送信方法のフローチャートであり、図１に示すように、該プロセスは、
サーバへの送信待ちの第一のデータパケットを確定するステップＳ１０２と、
第一のデータパケットの数が２つ以上である場合、２つ以上の第一のデータパケットを一つの第二のデータパケットに集約するステップＳ１０４と、
得られた第二のデータパケットをサーバに送信するステップＳ１０６とを含む。

【0038】

上記ステップで２つ以上の第一のデータパケットを一つの第二のデータパケットに集約することにより、各第一のデータパケットのヘッダーが層ごとに処理されることに起因したデータ伝送が遅くなる問題を避ける。関連技術に存在するデータ伝送が遅いという問題を解決し、さらにデータ伝送レートを向上させる効果を達成する。

【0039】

一つの選択可能な実施例では、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約することは、２つ以上の前記第一のデータパケットのソースインターネットプロトコル（ＩＰ）アドレスをいずれも所定のＩＰアドレスに変換することと、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約し、前記第二のデータパケットのソースアドレスを所定のＩＰアドレスと設定することとを含む。ここで、前記ソースＩＰアドレスが予め割り当てられたローカルエリアネットワークＩＰアドレスであってもよく、前記所定のＩＰアドレスがゲートウェイデバイスのパブリックＩＰアドレスであってもよく、該実施例では、各第一のデータパケットの宛先ＩＰアドレスが同じであり、即ち全ては前記サーバのＩＰアドレスであり、したがって、第二のデータパケットの元のアドレスを前記所定のＩＰアドレスと設定した場合、第二のデータパケットの宛先アドレスを前記サーバのＩＰアドレスと設定することができる。

【0040】

一つの選択可能な実施例では、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約することは、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ該第二のデータパケットにおける異なるデータフィールドに充填することを含む。該実施例では、第二のデータパケットに複数のデータフィールドが設定され、各データフィールドの長さが同じであってもよいし、異なってもよく、且つデータフィールドの長さが柔軟に設定されてもよく、例えば各データフィールドの長さが１００バイトに設定されてもよい。

【0041】

一つの選択可能な実施例では、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける異なるデータフィールドに充填することは、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける同じ長さの異なるデータフィールドに充填し、ここで、前記第一のデータパケット内のデータが充填されたデータフィールドに、前記第一のデータパケット内のデータの長さを識別するための第一の識別情報、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報、充填ビットのうちの少なくとも一つが含まれ、該充填ビットが、前記第一のデータパケット内のデータの長さが前記データフィールドの長さより小さい場合、前記データフィールドにおける、前記第一のデータパケット内のデータを充填していない部分を充填することに用いられることを含む。

【0042】

前記データフィールドに充填ビットのみが含まれる場合、このフィールドに実際に有効情報が存在しないことを意味し、即ち第一のデータパケット内のデータが充填されないことを示し、受信側はこのフィールドに対して解析する必要がない。この状況は下記の場合のみで見られ、即ち、集約ユニットが第一のデータパケットを集約する時に、指定された第二のデータパケットが大きく、分割されたフィールドが多く、それに対して、第一のデータパケットの数が少なく、構成されたフィールドの数が第二のデータパケットによって提供されるフィールドの数より少ない場合であり、この時に第二のデータパケットの末尾の充填されない全てのフィールドに充填ビットとして充填される。

【0043】

当然、上記の第一の識別情報、第二の識別情報、充填ビットは組合わせられてもよく、組み合わせ方式は多様であってもよい。例えば、
各データフィールドの大きさが必ずしも同じに設定されなくてもよく、このようにしてデータフィールドに充填ビットが含まれなくてもよく、各フィールドのデータがいずれも第一の識別情報、第二の識別情報及び第一のデータパケットのデータ情報であり、又は、
第一のデータパケットの長さを示すための第一の識別情報が存在しない場合、第一のデータパケット内のデータをそのまま放置し、
以上の二つのケースも実現されてもよく、その利点がデータフィールドのスペースを十分に利用できることであり、
又は、第一のデータパケットの変換前のソースアドレスを示すための第二の識別情報が存在せず、このような場合は、受信側が第一のデータフィールドの変換前のソースアドレスを知る必要がない状況で有り得、例えばクライアント／サーバモードで、サーバ、即ち受信側は、第一のデータパケットの変換前のソースＩＰアドレスを理解する必要がことなく、第一のデータパケットにおけるＴＣＰヘッダーのポート番号によって異なるＭＴＣ端末からの異なる第一のデータパケットを区分することもできる。

【0044】

以下に一つの組み合わせを例として説明する。第二のデータパケットにおける各データフィールドの長さが１００バイトであることを例とし、第二のデータパケットにおける一つのデータフィールドに充填される第一のデータパケット内のデータの大きさが１００バイト未満である場合、該データフィールドに一つの標識ビットを設定してもよく、該標識ビットが本データフィールドに充填されるデータパケットの具体的な大きさを示すことに用いられ、該標識ビットは本データフィールドの先頭のバイト位置に設定されてもよく、これにより受信側は該第二のデータパケットを受信した後、データフィールドにおける有効データの長さを正確に把握し、さらに元のデータパケットを解析することができる。説明すべきものとして、一つのデータフィールドに充填される第一のデータパケット内のデータの長さが一般的に該データフィールドのより小さく、データフィールドにおける充填されない部分に対して充填ビット（ｐａｄｄｉｎｇ）で充填することができる。一つの送信待ちの第一のデータパケット内のデータの大きさが第二のデータパケット内のデータフィールドの長さより大きい場合、該送信待ちの第一のデータパケット内のデータを第二のデータパケットに充填せず、従来技術における送信方式で該送信待ちの第一のデータパケットを受信側に送信しても良い。

【0045】

上記の実施例では主にどのように複数の小さなデータパケット（上記の第一のデータパケットに対応する）を一つの大きなデータパケット（上記の第二のデータパケットに対応する）に集約するかの動作について説明し、上記の実施例はモノのインターネットに応用されてもよく、以下にモノのインターネットを参照して上記の実施例を例を挙げて説明する。

【0046】

まず、端末に対するモノのインターネットシステムの要求、及びデータ伝送方面でのモノのインターネットの特殊性を説明する。モノのインターネット端末は通常以下の特徴を有する。

【0047】

正常に動作する時に、デバイス電力消費とネットワーク負荷などを含む消費電力が低く（ｌｏｗ−ｃｏｓｔ）にする必要がある。

【0048】

しばしば移動状態又は信号カバレッジが悪い状態で動作する可能性があり、この場合でもデータを低消費電力で伝送する必要がある。

【0049】

しばしば小さなデータでの伝送があるという特徴を持つ。例えば、複数のセンサーは収集された小さなデータパケットをＭＴＣサーバに離散的に送信する。このような頻繁、又は離散の小さなパケット伝送シーンにより、通常３ＧＰＰシステムリソースの利用率が非常に低い。

【0050】

上記のＭＴＣマシンタイプ通信における小さなデータパケット伝送の特徴に対して、「パケット集約」の方式により小さなデータ量伝送の最適化を行うことにより、小さなデータ伝送の効率が向上させ、電力消費量が低減する。このパケット集約の主な利点は、データパケットをアップリンクで送信する場合、データパケットが無線プロトコルスタックのＰＤＣＰ、ＲＬＣ、ＭＡＣ、物理層などで層ごとに処理され、小さなパケットがパッケージ全体のサイズに対するそのデータボリュームの割合がそもそも大きくなく、各データパケットのヘッダーが層ごとに処理されると、無線プロトコルスタックの動作効率が低くなることに間違いない。小さなパケットが集約された後、複数の小さなパケットが一つの大きなパケットを生成し、パケットヘッダーが一つだけであるので、プロトコルスタック処理の効率が大幅に向上させる。

【0051】

本実施例ではデータパケットの送信方法も提供され、図２は本発明の実施例による第二のデータパケットの送信方法のフローチャートであり、図２に示すように、該プロセスは、
サーバへの送信待ちの第一のデータパケットを確定するステップＳ２０２と、
第一のデータパケットが確認ＡＣＫデータパケットである場合、非アクセス層−プロトコルデータユニット（ＮＡＳ−ＰＤＵ）を用いて上記ＡＣＫデータパケットを送信するステップＳ２０４とを含む。

【0052】

上記ステップにより、ＮＡＳ−ＰＤＵを用いてＡＣＫを送信することにより、制御プレーンを用いてＡＣＫを送信するという目的を達成でき、ダウンリンクＴＣＰデータの伝送レートへの影響を避け、関連技術に存在するデータ伝送が遅いという問題を解決し、さらにデータ伝送レートを向上させる効果を達成する。

【0053】

一つの選択可能な実施例では、非アクセス層−プロトコルデータユニット（Ｎｏｎ Ａｃｃｅｓｓ ｓｔｒａｔｕｍ− Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ、ＮＡＳ−ＰＤＵと略称）を用いて前記ＡＣＫデータパケットを送信することは、該ＡＣＫデータパケットをＮＡＳ−ＰＤＵに含ませることと、前記ＡＣＫデータパケットを含むＮＡＳ−ＰＤＵを送信することとを含む。ここで、前記ＡＣＫデータパケットはダウンリンクデータ（例えば伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＴＣＰと略称）データ）に対してフィードバックされた応答メッセージである。以下で同様にモノのインターネットを例として本実施例を説明する。一つの期間内で並行性のデータ伝送（アップリンク及びダウンリンク伝送を同時に行う）がバーストする。従来のデータ端末と比較し、ユーザの主なサービスは基本的にダウンリンクサービス、例えばビデオ再生、ファイルダウンロードなどであり、ダウンリンクのピークレートもユーザに最も注目される指標である。アップリンクデータ伝送量が小さく、並行ピークレートに対する要求が低い。それに対してモノのインターネットは異なり、多くの場合でアップリンク及びダウンリンク伝送が同時に発生し、且つアップリンク及びダウンリンクのピークレートがいずれもニーズを満たす必要がある現象が現れる。本実施例においてこのようなピークレートに対する最適化が提案され、且つ該最適化が送信電力を増加させないという前提に基づくものである。本実施例ではアップリンクＡＣＫパケット（即ち上記のＡＣＫデータパケット）メッセージをシグナリングによりネットワークに伝送することが提案される。端末が動作する時に、システム環境、例えば温度、セル信号キーパフォーマンスインジケータ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒｓ、ＫＰＩと略称）（信号強度、信号対雑音比など）を検出することができ、アップリンクＡＣＫ伝送の速度を制御することで、ダウンリンクＴＣＰデータのレートを制御し、データ送信のための電力消費を高温及び弱い信号の状況で低減させ、同一の原理に基づき、必要以上に送信電力を増加させない、即ち送信電力を増加させないという前提で、アップリンク及びダウンリンクの同時送信レートを大幅に向上させる。

【0054】

本実施例ではデータパケットの受信方法が提供され、図３は本発明の実施例におけるデータパケットの受信方法のフローチャートであり、図３に示すように、該プロセスは、
端末からの第二のデータパケットを受信するステップＳ３０２と、
前記第二のデータパケットを解析し、該第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得するステップＳ３０４とを含む。

【0055】

上記ステップにより、２つ以上の第一のデータパケットが集約されている第二のデータパケットを受信することができ、ここで、２つ以上の第一のデータパケットを一つの第二のデータパケットに集約して伝送する方式により、各第一のデータパケットのヘッダーが層ごとに処理されることに起因するデータ伝送が遅くなる問題を避けることができ、受信側は複数の第一のデータパケットをより速く受信することができる。関連技術に存在するデータ伝送が遅いという問題を解決し、さらにデータ伝送レートを向上させる効果を達成する。

【0056】

一つの選択可能な実施例では、前記第二のデータパケットを解析し、第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得することは、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定することと、確定された前記長さに基づいて各データフィールドに充填される前記第一のデータパケット内のデータを取得することとを含む。該実施例では、第二のデータパケットに複数の第一のデータパケット（即ち上記の２つ以上の第一のデータパケット）が充填されてもよく、且つ一つの第一のデータパケットが第二のデータパケットにおける一つのデータフィールドに対応してもよく、データフィールド毎にデータパケットの長さを示すための標識ビット（上記の第一の識別情報）があり、それによって第二のデータパケット内のデータフィールドを解析する場合、データフィールドにおける有効データの長さを正確に把握し、さらに元の第一のデータパケットを解析することができる。

【0057】

一つの選択可能な実施例では、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定することは、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、解析された前記データフィールドに含まれる第一の識別情報に基づいて各データフィールドに充填される第一のデータパケット内のデータの長さを確定し、該第一の識別情報が第一のデータパケット内のデータの長さを識別することに用いられることを含む。該実施例では、第二のデータパケットにおける各データフィールドに有効データの長さを識別するための第一の識別情報が含まれてもよい。

【0058】

一つの選択可能な実施例では、前記第二のデータパケットにおける２つ以上のデータフィールドを解析した後、前記方法はさらに、解析された前記データフィールドに含まれる第二の識別情報に基づいて第一のデータパケットの変換前のソースＩＰアドレスを確定し、該第二の識別情報が前記第一のデータパケットの変換前のソースＩＰアドレスを識別することに用いられることを含む。

【0059】

ここで、アップリンクデータパケットを送信する場合、弱い信号でデータパケットを送信する時に、データパケットを一時的にキャッシュし、信号品質が良くなってから送信することができる。該解決策は、弱い信号状況でデータパケットを送信するシグナリング負荷をある程度解決することができる。

【0060】

以上の実施形態の説明により、当業者は上記実施例による方法がソフトウェアと必要な汎用ハードウェアプラットフォームを組み合わせることにより実施されてもよく、当然ハードウェアによって実施されてもよいが、多くの場合、前者がより良い実施形態であることを明確に理解できる。このような理解に基づき、本発明の実施例における技術的解決策は、本質的にソフトウェア製品の形態で実現されてもよく、又は関連技術に貢献する部分がソフトウェア製品の形態で実現されてもよく、該コンピュータソフトウェア製品は、一つの端末装置（携帯電話、コンピュータ、サーバ、又はネットワーク装置などあってもよい）に本発明の各実施例に記載の方法を実行させるためのいくつかのコマンドを含む記憶媒体（例えばＲＯＭ／ＲＡＭ、磁気ディスク、光ディスク）に記憶される。

【0061】

本実施例ではデータパケットの送信装置が提供され、該装置は上記実施例及び好ましい実施形態を実現することに用いられ、既に説明され、そのため繰り返し説明を省略する。以下に用いられる用語「モジュール」は所定の機能のソフトウェア及び/又はハードウェアの組み合わせを実現することができる。以下の実施例に説明される装置は好ましくソフトウェアで実現されるが、ハードウェア、又はソフトウェアとハードウェアの組み合わせで実現されてもよい。

【0062】

図４は本発明の実施例による第一のデータパケットの送信装置の構成ブロック図であり、図４に示すように、該装置は第一の確定モジュール４２、集約モジュール４４と第一の送信モジュール４６を備え、以下に該装置について説明する。

【0063】

第一の確定モジュール４２はサーバへの送信待ちの第一のデータパケットを確定するように構成され、集約モジュール４４は前記第一の確定モジュール４２に接続され、前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約するように構成され、第一の送信モジュール４６は前記集約モジュール４４に接続され、前記第二のデータパケットをサーバに送信するように構成される。

【0064】

図５は本発明の実施例による第一のデータパケットの送信装置における集約モジュール４４の構成ブロック図であり、図５に示すように、該集約モジュール４４は変換ユニット５２と集約ユニット５４を含み、以下に該集約モジュール４４を説明する。

【0065】

変換ユニット５２は２つ以上の前記第一のデータパケットのソースインターネットプロトコル（ＩＰ）アドレスをいずれも所定のＩＰアドレスに変換するように構成され、集約ユニット５４は前記変換ユニット５２に接続され、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを前記第二のデータパケットに集約し、前記第二のデータパケットのソースアドレスを所定のＩＰアドレスと設定するように構成される。

【0066】

図６は本発明の実施例による第一のデータパケットの送信装置における集約ユニット５４の構成ブロック図であり、図６に示すように、該集約ユニット５４は充填サブユニット６２を含み、以下に該充填サブユニット６２について説明する。

【0067】

充填サブユニット６２は、ソースＩＰアドレスが変換された２つ以上の第一のデータパケットを大きなデータパケットに集約する場合、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ該第二のデータパケットにおける異なるデータフィールドに充填させるように構成される。

【0068】

図７は本発明の実施例による第一のデータパケットの送信装置における充填サブユニット６２の構成ブロック図であり、図７に示すように、該充填サブユニット６２は充填セカンダリサブユニット７２を含み、以下に該充填セカンダリサブユニット７２について説明する。

【0069】

充填セカンダリサブユニット７２は、ソースＩＰアドレスが変換された２つ以上の第一のデータパケット内のデータをそれぞれ前記第二のデータパケットにおける同じ長さの異なるデータフィールドに充填するように構成され、ここで、前記第一のデータパケット内のデータが充填されたデータフィールドに、第一のデータパケット内のデータの長さを識別するための第一の識別情報、前記第一のデータパケットの変換前のソースＩＰアドレスを識別するための第二の識別情報、充填ビットのうちの少なくとも一つが含まれ、前記充填ビットが、前記第一のデータパケット内のデータの長さが前記データフィールドの長さより小さい場合、前記データフィールドにおける、第一のデータパケット内のデータを充填していない部分を充填することに用いられる。

【0070】

図８は本発明の実施例による第二のデータパケットの送信装置の構成ブロック図であり、図８に示すように、該装置は第二の確定モジュール８２と第二の送信モジュール８４を備え、以下に該装置について説明する。

【0071】

第二の確定モジュール８２は、サーバへの送信待ちの第一のデータパケットを確定するように構成され、第二の送信モジュール８４は、前記第二の確定モジュール８２に接続され、前記第一のデータパケットが確認ＡＣＫデータパケットである場合、非アクセス層−プロトコルデータユニット（ＮＡＳ−ＰＤＵ）を用いて前記ＡＣＫデータパケットを送信するように構成される。

【0072】

図９は本発明の実施例による第二のデータパケットの送信装置における第二の送信モジュール８４の構成ブロック図であり、図９に示すように、該第二の送信モジュール８４はベアラユニット９２と送信ユニット９４を含み、以下に該第二の送信モジュール８４について説明する。

【0073】

ベアラユニット９２は、ＡＣＫデータパケットをＮＡＳ−ＰＤＵに含ませるように構成され、送信ユニット９４は、前記ベアラユニット９２に接続され、前記ＡＣＫデータパケットを含むＮＡＳ−ＰＤＵを送信するように構成される。

【0074】

図１０は本発明の実施例によるデータパケットの受信装置の構成ブロック図であり、図１０に示すように、該装置は受信モジュール１０２と取得モジュール１０４を備え、以下に該装置について説明する。

【0075】

受信モジュール１０２は、端末からの第二のデータパケットを受信するように構成され、取得モジュール１０４は、前記受信モジュール１０２に接続され、前記第二のデータパケットを解析し、前記第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得するように構成される。

【0076】

図１１は本発明の実施例によるデータパケットの受信装置における取得モジュール１０４の構成ブロック図であり、図１１に示すように、該取得モジュール１０４は第一の確定ユニット１１２と取得ユニット１１４を含み、以下に該取得モジュール１０４について説明する。

【0077】

第一の確定ユニット１１２は、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、各データフィールドに充填される第一のデータパケット内のデータの長さを確定するように構成され、取得ユニット１１４は、前記第一の確定ユニット１１２に接続され、確定された前記長さに基づいて各データフィールドに充填される前記第一のデータパケット内のデータを取得するように構成される。

【0078】

図１２は本発明の実施例によるデータパケットの受信装置における第一の確定ユニット１１２の構成ブロック図であり、図１２に示すように、該第一の確定ユニット１１２は確定サブユニット１２２を含み、以下に該確定サブユニット１２２について説明する。

【0079】

確定サブユニット１２２は、前記第二のデータパケットにおける２つ以上のデータフィールドを解析し、解析された前記データフィールドに含まれる第一の識別情報に基づいて各データフィールドに充填される第一のデータパケット内のデータの長さを確定するように構成され、該第一の識別情報が前記第一のデータパケット内のデータの長さを識別することに用いられる。

【0080】

図１３は本発明の実施例によるデータパケットの受信装置における取得モジュール１０４の好ましい構成ブロック図であり、図１３に示すように、該取得装置１０４は図１１に示す全てのモジュールに加えて、第二の確定ユニット１３２を備え、以下に該取得モジュール１０４について説明する。

【0081】

第二の確定ユニット１３２は、前記第一の確定ユニット１１２に接続され、前記第二のデータパケットにおける２つ以上のデータフィールドを解析した後、解析されたデータフィールドに含まれる第二の識別情報に基づいて前記第一のデータパケットの変換前のソースＩＰアドレスを確定するように構成され、該第二の識別情報が第一のデータパケットの変換前のソースＩＰアドレスを識別することに用いられる。

【0082】

以下にモノのインターネットと組み合わせて本発明の実施例における前記装置の実施例を例を挙げて説明する。

【0083】

本実施例に係るモノのインターネットにおけるモジュールは、主に以下のモジュールを含む。

【0084】

データパケット集約モジュール（Ｐａｃｋｅｔ Ａｇｇｒｅｇａｔｉｏｎ Ｍｏｄｕｌｅ、ＰＡＭと略称）（前記集約ユニット５４に対応する）であって、該モジュールはネットワークアドレス変換（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ、ＮＡＴと略称）モジュールとエアインタフェースの間に位置し、複数の端末（プライベートネットワークＩＰアドレスを有しているセンサーである可能性がある）からの、同じモノのインターネットアプリケーションサーバ（ＭＴＣ Ｓｅｒｖｅｒ）に送信された複数の小さなデータパケット（前記第一のデータパケットに対応する）を集約し、複数の小さなデータパケットをデータブロックに集約し、新規な大きなＩＰパケット（前記第二のデータパケットに対応する）に格納してネットワークに伝送するように構成される。この考え方に基づき、具体的な集約方式は複数である可能性がある。本実施例では比較的簡単且つ効率が高い方式が提案される。即ち新規の大きなＩＰパケットにおけるデータ部分を論理的にいくつかの同じバイトサイズ（本例では１００バイトを例とする）のフィールドに分割し、集約する際に、各小さなＩＰパケットのコンテンツを充填し、このフィールドを小さなパケットで埋め切れない場合、充填ビット（ｐａｄｄｉｎｇ）で満杯まで充填する。説明すべきものとして、本実施例のシーンでは、複数の端末に同一のネットワークセグメントのローカルエリアネットワークＩＰアドレスが割り当てられ、且つＩＰパケットを同一のサーバに送信し、複数のサーバがある場合、同一サーバに送信されるパケットは一つのインプットとして集約処理を行される。集約プロセスがＮＡＴの後に実行され、ＮＡＴ処理が実行された後、複数の小さなＩＰパケットのソースＩＰアドレスが、コアネットワークによって端末に割り当てられたパブリックネットワークＩＰアドレスになり、複数の端末のこのパブリックネットワークＩＰアドレスが同じであり、且つ宛先アドレス、即ちＭＴＣサーバも同じであり、そのため、新規の大きなＩＰパケットのソース、宛先ＩＰアドレスは、小さなパケットのソース、宛先ＩＰアドレスのコピーを使用することができる。

【0085】

データパケット解析モジュール（Ｐａｃｋｅｔ Ｆｒａｇｍｅｎｔａｔｉｏｎ Ｍｏｄｕｌｅ、ＰＦＭと略称）（前記取得モジュール１０４に対応する）であって、該モジュールは論理的にキャリアコアネットワークとモノのインターネットアプリケーションサーバの間に位置する。それはキャリアネットワークで実現されてもよいし、ＭＴＣ Ｓｅｒｖｅｒで実現されてもよい。それの作用としては、ＵＥから送信された、集約されるＩＰパケットに対して集約解除を行い、元の小さなパケットを生成し、ＭＴＣアプリケーションの元のプロセスのＴＣＰ／ＩＰプロトコルスタックに提供することである。集約解除プロセスは集約プロセスと逆である。大きなＩＰパケットにおけるデータ部分のコンテンツをフィールドで解析すればよい。

【0086】

トラフィック調整スイッチであって、本機能の有効化を制御できる。目的は本システムのネットワーク互換性を向上させることであり、ＵＥが第３世代移動通信パートナープログラム（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ、３ＧＰＰと略称）モノのインターネット環境（Ｇａｔ１、Ｇａｔ０又はロングタームエボリューションマシンツーマシン（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ−Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ 、ＬＴＥ−Ｍと略称）から切り替えられた場合でも、元の動作プロセスに影響を与えない。

【0087】

トラフィック調整処理モジュール（Ｔｒａｆｆｉｃ Ｒｅｇｕｌａｔｏｒ Ｐｒｏｓｅｓｓ）（前記第二の送信モジュール８４に対応する）であって、該モジュールは、動作環境状況を検出する機能と、３ＧＰＰモノのインターネットにおける「小さなデータをシグナリングで伝送する」機能という２つの機能を有し、アップリンクで送信された、ダウンリンクＴＣＰデータパケットに対する確認（ＴＣＰ ＡＣＫ）メッセージをＮＡＳシグナリングのメッセージボディに入れてネットワークに送信する。

【0088】

以下にそれぞれ異なる実施例と組み合わせて本発明について説明する。

【0089】

パケット集約方法の実施例は下記の通りである。

【0090】

本実施例ではアップリンクデータパケット集約方法が提供され、図１４を参照すると、図１４は本発明の実施例によるパケット集約方法のフローチャートであり、図１４に示すように、該プロセスはステップＳ１４０１〜Ｓ１４０６を含む。

【0091】

ステップＳ１４０１において、モノのインターネット装置（ＭＴＣ Ｄｅｖｉｃｅ）が存在し、通常、ＭＴＣシステムには複数の装置が存在し、ローカルエリアネットワークＩＰアドレスが割り当てられることが可能であり、本例において割り当てられたＩＰアドレスを１９２．１６８．０.ｘセクションとする。

【0092】

ステップＳ１４０２において、モノのインターネット装置からネットワークに送信されたアップリンクデータパケットであり、図１４に３つのデータパケットが示され、ここでＩＰ−１が最も大きく、ＩＰ−３が最も小さい。３つの装置はデータパケットを７４．１２５.１２８．１０６アドレスのＭＴＣ Ｓｅｒｖｅｒに送信する。

【0093】

ステップＳ１４０３において、ＮＡＴであり、即ちネットワークアドレス変換モジュールであって、該モジュールは最終的に３つのパケットのソースアドレスを３ＧＰＰシステムによってゲートウェイ装置に割り当てられたパブリックＩＰアドレスに変換し、本例において該パブリックＩＰアドレスが１．１.３６．１０８である。

【0094】

ステップＳ１４０４において、ＮＡＴ変換されたＩＰパケットがエアインタフェース側に送信される。

【0095】

ステップＳ１４０５において、パケット集約モジュール（ＰＡＭ）であって、該モジュールは本願のコアなモジュールの一つであり、複数の小さなデータパケットを集約し、次のステップに記載される大きなパケットを形成し、３ＧＰＰネットワークに送信する。注意すべきものとして、ここで一つのパッケージコード、例えば１００が存在し、即ち長さが１００バイト以下であるパケットが集約に関与し、１００バイト未満のパケットが充填ビット（ｐａｄｄｉｎｇ）で充填され、１００バイトずつが一つのフィールドとして大きなパケットのデータフィールドに充填される。各フィールドの先頭バイトＬが該バイトの有効なＩＰパケットコンテンツの長さであり、先頭バイトは、集約を解除する際に、元の小さなＩＰパケットとその後の充填ビット（ｐａｄｄｉｎｇ）とを効果的に分離させるために設定される。このパケット集約メカニズムの目的は、集約解除モジュールがバイトアドレッシングを行い、大きなＩＰパケットにおけるデータを元のＩＰパケットに分解することに利便性を与えることである。ここで一つだけの集約方式が示され、他の集約方式及び他の集約解除方式が可能であるが、プログラミングレベルの詳細な問題に属するため、本実施例では一つずつ説明しない。

【0096】

ステップＳ１４０６において、ＰＡＭモジュールによって集約される大きなパケットであって、ここで、複数の小さなデータパケットがＩＰパケットのデータ部分に位置する。その後エアインタフェース（Ｕｍポート）を介してネットワーク側に送信される。

【0097】

パケット集約解除方法の実施例が下記の通りである。

【0098】

集約されるデータパケットはネットワーク側に到達すると、解体して元の散らばった小さなデータパケットに復元されるために集約解除が必要となる。本実施例ではデータパケット集約解除方法が提供され、図１５に示すとおりである。図１５は本発明の実施例によるパケット集約解除のフローチャートである。それは図１４に対応して関連付けられ、図１５に示すプロセスはステップＳ１５０１〜Ｓ１５０３を含む。

【0099】

ステップＳ１５０１において、大きなデータパケットは３ＧＰＰネットワークを経過する。

【0100】

ステップＳ１５０２において、パケット集約解除モジュール（ＰＦＭ）であって、それは集約される大きなデータパケットを元の小さなデータパケットに分散させることに用いられる。そのプロセスはパケット集約（ＰＡＭ）モジュールと逆である。

【0101】

ステップＳ１５０３において、集約が解除されたＩＰパケットは復元された後にＭＴＣ Ｓｅｒｖｅｒに関連するアプリケーションに伝達され、又はＴＣＰ／ＩＰプロトコルスタックに直接配信される。この時に元のＩＰパケットになり、ＭＴＣ Ｓｅｒｖｅｒにおけるアプリケーションプログラムは元のプロセスに従って処理されてもよい。

【0102】

説明すべきものとして、前記パケット集約、集約解除の動作シーン、及びこの最適化方式の目的は以下のとおりである。

【0103】

（１）上述したように、多くのモノのインターネットアプリケーションは、複数のスマートカメラがＭＴＣサーバへデータをアップロードするなどの小さなデータパケットを送信する特性を有している。多くの小さなデータパケットがエアインタフェースプロトコルスタックに伝達されると、エアインタフェースプロトコルスタックの階層化メカニズム（ＲＬＣ、ＭＡＣ、ＰＤＣＰなど）があり、層ごとにパッケージングメカニズムがあり、キャリアネットワークにおける各ネットワーク要素も、階層化処理メカニズムを有するため、多くの小さなデータパケットへの階層的なヘッダー追加処理などにより、システムリソースの利用が非常に十分ではない。本特許技術の集約方法は、このシーンにおける３ＧＰＰシステムリソースの利用率を効果的に向上させ、即ち低電力消費を実現することができる。

【0104】

（２）モノのインターネット端末は常に信号カバレッジが悪い位置例えばビル地下室などに位置し、データサービスの前に確立される無線ベアラでは、ネットワーク状態ＫＰＩの領域に無線ベアラを確立するために消費されるシグナリングが一般的により多く（シグナリング送信失敗、拒否などの理由によって引き起こされる再送信がある）、且つ信号が悪い時点に発信電力がより大きくなり、小さなデータを頻繁に送信すると端末の電力消費がより高くなる。本解決策は、ネットワーク状態が悪い領域に、まず送信される小さなデータパケットを集約し、ネットワーク状態が良くなる時に送信することにより、該問題を解決することができる。

【0105】

ＰＡＭとＰＥＭモジュールの集約、集約解除方式について、本例ではそのうちの一つのみを示す。プログラミングスキルと実現の複雑さから考え、具体的な集約方式は複数である可能性があるが、基本的な考えが同じである。

【0106】

ＡＣＫをシグナリングにより伝送するための最適化ポリシーの実施例が下記の通りである。

【0107】

ＴＣＰ即ち伝送制御プロトコルが確認に基づく伝送層プロトコルであり、即ちデータパケットが相手側に到達すると、相手側がＡＣＫパケットを送信して該パケットが受信されたことを確認する必要があり、該ＡＣＫパケットの送信がＴＣＰデータストリームの伝送レートに影響を与える。この原理に基づき、本実施例ではアップリンクのＴＣＰ ＡＣＫの送信を制御することで、ダウンリンクレートを調整することができる方法とモジュール（即ち上記トラフィック調整スイッチとトラフィック調整処理モジュール）が提供され、該実施例におけるモジュールは３つの主な機能を有している。（１）現在の環境におけるネットワーク状態、例えば信号強度、信号品質、信号対雑音比などを検出できる機能である。（２）ネットワーク状態が良く、装置の電気量が十分である状況で本モジュールが送信電力を増加させない前提で、同時送信レートを効果的に上げ、高性能伝送を実現することができる機能である。（３）装置の電気量が低いことなどを検出した場合、必要以上にバッファ（ｂｕｆｆｅｒ）スペースを増やしない前提で、ダウンリンクレートに対してトラフィックを制限し、電力消費を低減させることができる機能である。説明すべきものとして、アップリンクレートは通常ダウンリンクレートより低く、且つアップリンクレートがＵＥに対して制御可能であり、そのため本特許技術はダウンリンクに対するトラフィック制限を重点として説明する。

【0108】

図１６を参照すると、図１６は本発明の実施例によるＡＣＫをシグナリングにより伝送する方法のフローチャートであり、該プロセスはステップＳ１６０１〜ステップＳ１６０７を含む。

【0109】

ステップＳ１６０１において、ＴＣＰデータパケット付きのダウンリンクＩＰパケットがＵＥ側に到達する。

【0110】

ステップＳ１６０２において、トラフィック調整スイッチがオン状態にあると、ステップＳ１２０４に進み、以下のプロセスを継続でき、そうでない場合はステップＳ１２０３に進み、このスイッチの目的はユーザプログラムに機能のオプション機能を提供することである。

【0111】

ステップＳ１６０３において、従来のアップリンクデータパケット伝送プロセスは、即ちＴＣＰをパッケージングしたＩＰパケットをＵＥのエアインタフェース側に直接配信し、層ごとにパッケージングしてエアインタフェースを介してネットワークに送信する。

【0112】

ステップＳ１６０４において、トラフィック調整処理モジュールは、ネットワーク基準信号ＫＰＩの検出を実現し、同時送信レートを上げることができ、トラフィック制限及び電力消費低減を実現することができる。

【0113】

ステップＳ１６０５において、アップリンクのＴＣＰ ＡＣＫメッセージ、即ちダウンリンクのＴＣＰデータパケットに対する確認メッセージを、制御プレーンにおいてＮＡＳ−ＰＤＵの一部にパッケージングする。

【0114】

ステップＳ１６０６において、キャリアネットワークにおいて該ＮＡＳメッセージを送信し、メッセージボディーにＴＣＰ ＡＣＫコンテンツが含まれる。

【0115】

ステップＳ１６０７において、ネットワーク側はメッセージを最終的にモノのインターネットサーバ（ＭＴＣ Ｓｅｒｖｅｒ）に配信する。

【0116】

上記の実施例では、無線データ端末の同時送信レートは常にダウンリンクレートが標準を満たない状況があるが、ユーザプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、ＵＤＰと略称）は一般的に該問題がなく、主にＴＣＰが存在する。しかし、アプリケーションプログラムではより多くのＴＣＰが用いられる。その理由は主にアップリンクのＴＣＰデータストリームが大部分のリソースを占有するため、アップリンクの小さなＴＣＰ ＡＣＫパケットのアップロードが少し遅延されることである。この遅延は一般的なＴＣＰデータ負荷パケットの遅延と異なり、ダウンリンクの大きなデータパケットが適時に確認されないと、ダウンリンクピークレートに深刻な影響を与える。現在、この問題を解決するためのいくつかの回避及び最適化解決策があり、主にＵＥにキャッシュを増加し、次にアップリンクのデータパケットを判定して大きさの小さいデータパケットを優先的に送信し、大きなデータパケットを一時的にキャッシュする。この解決策は、アップリンクレートに一定の影響を与えることと、ＵＥのキャッシュスペースを占有し、モノのインターネット端末、多くの場合はリソースが限られたローエンドデバイスに適用しないこととの２つの欠点がある。本技術的解決策はこの２つの欠点を伴わず、直接ＴＣＰ ＡＣＫを小さなデータとして無線ＮＡＳシグナリングにベアラしてネットワークにアップロードし、「補助チャネル」に相当し、ユーザプレーンデータを占有せず、且つ送信電力を増加する必要がない。この方式により、同時に送信する時のダウンリンクレートを大幅に上げることができる。同様に、ＴＣＰ ＡＣＫをパッケージングして無線プロトコルスタックＮＡＳパッケージングモジュールに配信するレートにより、ダウンリンクレート制限及び電力消費量低減の効果を達成することもできる。その具体的な動作メカニズムについてさらに図１７を参照できる。

【0117】

トラフィック調整モジュールの具体的な処理の実施例は下記の通りである。

【0118】

図１７は本発明の実施例によるトラフィック調整モジュールの具体的な動作フローチャートであり、図１７に示すように、該プロセスはステップＳ１７０１〜Ｓ１７０５を含む。

【0119】

ステップＳ１７０１において、図１６におけるトラフィック調整を完成させる具体的な処理モジュールである。

【0120】

ステップＳ１７０２において、ＩＰシーケンスであって、ここでにアップＴＣＰ ＡＣＫパケットが含まれる。

【0121】

ステップＳ１７０３において、ディスパッチャー（Ｄｉｓｐａｔｃｈｅｒ）であって、データストリームをエアインタフェース無線プロトコルスタックに割り当て、ＮＡＳ層に配信してデータをパッケージングすることができ、又は、通常のプロセスに従い、データストリームをＲＬＣ ＰＤＵにパッケージングし、さらに層ごとにパッケージングしてエアインタフェースプレーンを介して伝送することもできる。前者は本特許技術によって提案される解決策である。ディスパッチャーは互換性及びユーザ選択性を向上させるように設計される。

【0122】

ステップＳ１７０４において、エアインタフェースのプロトコルスタックであって、ここで特に非無線アクセス層即ちＮＡＳ層では、小さなデータパケットをパッケージングしてシグナリングによって伝送する。

【0123】

ステップＳ１７０５において、通常のユーザプレーンプロトコルスタックであって、データパケットは、無線二層プロトコルスタックによって順次処理され、最終的に無線フレームに形成されて３ＧＰＰシステムのネットワークに送信される。

【0124】

以下に具体的な応用シーンと組み合わせて説明する。

【0125】

本技術的解決策を応用した２つのモノのインターネット応用シーンを考える。まず、複数のＩＰカメラが装着するブリッジの場合、車両がブリッジを通過すると、カメラはそれを撮影し、圧縮し、ＬＴＥ−Ｍネットワークを介してアプリケーションサーバにアップロードする。朝と夕方のピーク期間では、車両が頻繁に通過し、このとき、小さなデータのアップロードが頻繁に同時に発生する。本特許技術では多くの小さなデータパケットを集約してアップロードすることにより、複数の散乱パケットによるシステム負荷を効果的に低減させることができ、車両が少ない場合、一定間隔毎に1台だけの車両が通過し、この時にパケット集約メカニズムにより、データパケット毎に一回伝送されることを効果的に回避し、後者では、複数のＭＴＣ Ｄｅｖｉｃｅの状態がアイドルＩＤＬＥと接続ＣＯＮＮＥＣＴの間に頻繁に切り替えられ、システムのシグナリング負荷が大きくなる。

【0126】

また、車載端末の場合、車載端末により、車内のユーザはアクセスしてアップロード及びダウンロード動作を行うことができ、又は、無線ダウンロードにより端末のディスプレイに再生される広告、ビデオなどのサービスを更新することができ、このようにして本発明の上記実施例の技術を適用し、弱信号の範囲への移動による伝送エネルギーの消費を回避し、及びリソースを節約する場合で、大きなサービスを伝送する際のピークレートを上げ、ユーザ体験を向上させることができる。

【0127】

説明すべきものとして、上記各モジュールはソフトウェア又はハードウェアで実現されてもよく、後者として、上記モジュールがいずれも同じプロセッサ内に配置され、又は上記モジュールがそれぞれ複数のプロセッサに配置されることによって実現されてもよいが、これに限定されない。

【0128】

本発明の実施例では記憶媒体が提供される。選択可能に、本実施例では、上記記憶媒体はＳ１１〜Ｓ１３を実行するためのプログラムコードを記憶するように構成されてもよい。

【0129】

Ｓ１１において、サーバへの送信待ちの第一のデータパケットを確定する。

【0130】

Ｓ１２において、前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集尺させる。

【0131】

Ｓ１３において、該第二のデータパケットをサーバに送信する。

【0132】

選択可能に、記憶媒体はさらにＳ２１〜Ｓ２２を実行するためのプログラムコードを記憶するように構成される。

【0133】

Ｓ２１において、サーバへの送信待ちの第一のデータパケットを確定する。

【0134】

Ｓ２２において、前記第一のデータパケットが確認ＡＣＫデータパケットである場合、非アクセス層−プロトコルデータユニット（ＮＡＳ−ＰＤＵ）を用いて前記ＡＣＫデータパケットを送信する。

【0135】

選択可能に、記憶媒体はさらにＳ３１〜Ｓ３２を実行するためのプログラムコードを記憶するように構成される。

【0136】

Ｓ３１において、端末からの第二のデータパケットを受信する。

【0137】

Ｓ３２において、前記第二のデータパケットを解析し、該第二のデータパケットに集約されている２つ以上の第一のデータパケットを取得する。

【0138】

選択可能に、本実施例では、前記記憶媒体は、Ｕディスク、読み出し専用メモリ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭと略称）、ランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ、Ｍｅｍｏｒｙ、ＲＡＭと略称）、モバイルハードディスク、磁気ディスク又は光ディスクなどのプログラムコードを記憶できる様々な媒体を含むことができるがこれらに限定されない。

【0139】

選択可能に、本実施例では、プロセッサは記憶媒体に記憶されたプログラムコードに従って上記各方法の実施例におけるステップを実行する。

【0140】

選択可能に、本実施例における具体的な例は上記実施例及び選択可能な実施形態に記載される例を参照できるので、ここで本実施例の説明を省略する。

【0141】

上記の実施例により、システムの動作効率を向上させ、且つシステム消費量（ＵＥの電力消費及び３ＧＰＰシステムのシグナリング負荷損失を含む）を低減させることができる。

【0142】

アップリンクデータパケットを送信する時の「パケット集約メカニズム」に対して、該技術には２つの利点があり、一つは多くの小さなパケットが各層のプロトコルスタックによって処理されて引き起こされた低効率を減少させる。パケットを集約した場合、無線プロトコルスタックはこの大きなパケットを処理するだけでよく、各元の小さなパケットを一回処理する必要がない。もう一つは集約モジュールが存在するので、小さなパケットのアップロードタイミングが制御可能であり、信号が強い時に送信し、信号が弱い時に一時的にキャッシュし、パケット集約メカニズムは実際にキャッシュの効果を奏することができる。弱い信号でデータを送信すると、無線リンクの確立が失敗することなどの問題が常に生じ、これによりシグナリング再送信が頻繁に発生し、システム負荷が増加する。信号が良くなった後に送信すると、この問題の発生の頻度を下げ、システムシグナリング消費を低減させ、ＵＥ端末の電力消費を減少させる。

【0143】

アップリンクのＡＣＫを制御することで、同時に送信する際のダウンリンクレートを制御し、上げる。それが基づく原理は、ＴＣＰ伝送プロトコルの確認メカニズムである。本技術的解決策ではＡＣＫパケットを特殊なパケットとしてＮＡＳシグナリングに入れて伝送することにより、それがデータチャネルを占有しないことができ、アップリンクのＡＣＫが速くフィードバックされ、ダウンリンクのデータレートも大幅に向上させる。送信電力を増加しない前提で、同時送信レートが向上させる。同様に、ＡＣＫをＮＡＳにパッケージングするレートを制御すると、ダウンリンクレートを制御できる。

【0144】

明らかに、当業者は、上述した本発明の各モジュール又は各ステップが汎用コンピューティングデバイスで実施されてもよく、それらが単一のコンピューティングデバイスに集中されてもよく、又は複数のコンピューティングデバイスで構成されたネットワークに分布されてもよく、選択可能に、それらがコンピューティングデバイスで実行可能なプログラムコードで実現されてよいので、それらを記憶装置に記憶してコンピューティングデバイスで実行し、且ついくつかの場合で、本明細書とは異なる順序で、図示又は記載されたステップを実行することができ、又はそれらをそれぞれ各集積回路モジュールに作り、又はそれらのうちの複数のモジュール又はステップを単一の集積回路に作って実現することを理解すべきである。これにより、本発明はいかなる特定のハードウェアとソフトウェアの組み合わせに限定されない。

【0145】

以上は、本発明の最適的な実施例に過ぎなく、本発明を制限せず、本分野の当業者に対して、本発明が各種類の変更と変化がある。本発明の主旨精神と原則以内に、いかなる改修、同等入れ替わり、改良等が、本発明の保護範囲以内に含まれるべきである。

【産業上の利用可能性】

【0146】

本発明の実施例によって提供されるデータパケットの送信方法、受信方法、送信装置及び受信装置では、該データパケットの送信方法は、サーバへの送信待ちの第一のデータパケットを確定することと、前記第一のデータパケットの数が２つ以上である場合、２つ以上の前記第一のデータパケットを一つの第二のデータパケットに集約することと、該第二のデータパケットをサーバに送信することとを含む。本発明の実施例により、関連技術に存在するデータ伝送が遅い問題を解決し、さらにデータ伝送レートを向上させる効果を達成する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】