(57)【要約】通信プロトコルスタックの第１プロトコルレイヤーがパケットの検査に失敗した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送するステップと、前記通信プロトコルスタックの第２プロトコルレイヤーが、前記パケットの第２プロトコルレイヤーの識別ビットを検証するステップと、前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するステップと、を含む、パケット修復方法を提供する。基地局、端末、およびコンピュータ読み取り可能な記憶媒体をさらに提供する。【選択図】図１
2021502025.tif 000002
【特許請求の範囲】
【請求項１】
通信プロトコルスタックの第１プロトコルレイヤーがパケットの検査に失敗した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送するステップと、
前記通信プロトコルスタックの第２プロトコルレイヤーが、前記パケットの第２プロトコルレイヤーの識別ビットを検証するステップと、
前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するステップと、を含む、
パケット修復方法。
【請求項２】
前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送するステップをさらに含む、
請求項１に記載の方法。
【請求項３】
前記通信プロトコルスタックの第１プロトコルレイヤーは物理レイヤーであり、前記通信プロトコルスタックの第２プロトコルレイヤーは、媒体アクセス制御サブレイヤーと、無線リンク制御サブレイヤーと、パケットデータコンバージェンスプロトコルサブレイヤーとを含む、
請求項１または２に記載の方法。
【請求項４】
前記通信プロトコルスタックの第２プロトコルレイヤーが前記パケットの第２プロトコルレイヤーの識別ビットを検証するステップは、
媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに基づき、前記パケットのヘッダデータをビット単位で検証し、前記パケットのヘッダデータのビットのデータが、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致している場合に、前記パケットへの検証をパスしたと確定して、前記パケットを無線リンク制御サブレイヤーに配送し、前記パケットのヘッダデータに、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致しないビットが存在する場合に、前記パケットを破棄することを含む、
請求項３に記載の方法。
【請求項５】
前記無線リンク制御サブレイヤーは、前記パケットの無線リンク制御シーケンス番号の値を、前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値とマッチングし、前記パケットの無線リンク制御シーケンス番号の値が、前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値内である場合に、前記パケットへの検証をパスしたと確定し、前記パケットをパケットデータコンバージェンスプロトコルサブレイヤーに配送し、前記パケットの無線リンク制御シーケンス番号の値が、前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲を超える場合に、前記パケットを破棄する、
請求項４に記載の方法。
【請求項６】
前記パケットデータコンバージェンスプロトコルサブレイヤーは、前記パケットのパケットデータコンバージェンスプロトコルシーケンス番号の値と、前記パケットデータコンバージェンスプロトコルサブレイヤーに予め定められたシーケンス番号の値とを比較し、比較結果を生成し、前記比較結果が予め定められた閾値以下である場合、前記パケットをアプリケーションレイヤーに配送し、前記比較結果が予め定められた閾値より大きい場合に、前記パケットを破棄する、
請求項５に記載の方法。
【請求項７】
前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットを前記通信プロトコルスタックの第３プロトコルレイヤーに配送するステップと、
前記通信プロトコルスタックの第３プロトコルレイヤーが、前記パケットの第３プロトコルレイヤーの識別ビットを検証するステップと、
前記パケットの第３プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄し、前記パケットの第３プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送するステップをさらに含む、
請求項１に記載の方法。
【請求項８】
前記通信プロトコルスタックの第３プロトコルレイヤーは、ネットワーク相互接続プロトコルサブレイヤーと、伝送制御プロトコルサブレイヤーまたはユーザデータプロトコルサブレイヤーと、リアルタイム伝送プロトコルサブレイヤーと、を含む、
請求項７に記載の方法。
【請求項９】
通信プロトコルスタックの第１プロトコルレイヤーでパケットの検査に失敗したと確定した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送するように配置された配送モジュールと、
前記通信プロトコルスタックの第２プロトコルレイヤーにおいて、前記パケットの前記第２プロトコルレイヤーの識別ビットを検証し、前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するように配置された検証モジュールと、を含む
基地局。
【請求項１０】
前記配送モジュールは、前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送するようにさらに配置される、
請求項１に記載の基地局。
【請求項１１】
前記通信プロトコルスタックの第１プロトコルレイヤーは物理レイヤーであり、前記通信プロトコルスタックの第２プロトコルレイヤーが、媒体アクセス制御サブレイヤーと、無線リンク制御サブレイヤーと、パケットデータコンバージェンスプロトコルサブレイヤーとを含む、
請求項９または１０に記載の基地局。
【請求項１２】
前記検証モジュールは、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに基づいて、前記パケットのヘッダデータをビット単位で検証し、前記パケットのヘッダデータ内のビットのデータが、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致する場合に、前記媒体アクセス制御サブレイヤー内の前記パケットへの検証をパスしたと確定し、前記パケットのヘッダデータ内に、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致しないビットが存在する場合に、前記パケットが破棄されるように配置され、
前記配送モジュールは、前記媒体アクセス制御サブレイヤーにおいて前記パケットへの検証をパスしたと確定した場合に、前記パケットを前記無線リンク制御サブレイヤーに配送するように配置される、
請求項１１に記載の基地局。
【請求項１３】
前記検証モジュールは、前記無線リンク制御サブレイヤーにおいて、前記パケットの無線リンク制御シーケンス番号の値を前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値とマッチングし、前記パケットの無線リンク制御シーケンス番号の値が前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値内にある場合に、前記無線リンク制御サブレイヤーにおいて前記パケットへの検証をパスしたと確定し、前記パケットの無線リンク制御シーケンス番号の値が前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値を超えた場合に、前記パケットを破棄するようにさらに配置され、
前記配送モジュールは、前記無線リンク制御サブレイヤーにおいて前記パケットへの検証をパスしたと確定した場合に、前記パケットをパケットデータコンバージェンスプロトコルサブレイヤーに配送するようにさらに配置される、
請求項１２に記載の基地局。
【請求項１４】
前記検証モジュールは、前記パケットデータコンバージェンスプロトコルサブレイヤーにおいて、前記パケットのパケットデータコンバージェンスプロトコルシーケンス番号の値を前記パケットデータコンバージェンスプロトコルのサブレイヤーに予め定められたシーケンス番号の値と比較し、比較結果を生成し、前記比較結果が予め定められた閾値よりも大きい場合に、前記パケットを破棄するようにさらに配置され、
前記配送モジュールは、前記比較結果が予め定められた閾値以下である場合に、前記パケットをアプリケーションレイヤーに配送するように配置される、
請求項１３に記載の基地局。
【請求項１５】
前記配送モジュールは、前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記通信プロトコルスタックの第３プロトコルレイヤーに前記パケットを配送するようにさらに配置され、
前記検証モジュールは、前記通信プロトコルスタックの第３プロトコルレイヤーにおいて、前記パケットの第３プロトコルレイヤーの識別ビットを検証し、前記パケットの第３プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するようにさらに配置され、
前記配送モジュールは、前記パケットの第３プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送するようにさらに配置される、
請求項９に記載の基地局。
【請求項１６】
前記通信プロトコルスタックの第３プロトコルレイヤーは、ネットワーク相互接続プロトコルサブレイヤー、伝送制御プロトコルサブレイヤーまたはユーザデータプロトコルサブレイヤー、およびリアルタイム伝送プロトコルサブレイヤーを含む、
請求項１５に記載の基地局。
【請求項１７】
実行可能な命令を含むプログラムを記憶したメモリと、前記プログラムを実行して、請求項１〜８のいずれか１項に記載の方法を実現するプロセッサとを備える、
端末。
【請求項１８】
コンピュータプログラムを記憶し、前記コンピュータプログラムが実行されるときに請求項１〜８のいずれか一項に記載の方法を実現する、
コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１７年１１月７日に提出された、名称を「パケット修復方法、基地局、端末及びコンピュータ読み取り可能な記憶媒体」とする中国特許出願（ＮＯ．２０１７１１０８７２８６．１）の優先権を主張し、当該中国特許出願の内容すべてを参照によりここに援用する。
【０００２】
本開示は、ワイヤレス通信技術分野に関するものであるがこれに限定されない。
【背景技術】
【０００３】
ロングタームエボリューション（ＬＴＥ、Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）ネットワークにおいて、物理レイヤーは、ハイブリッド自動再送要求（ＨＡＲＱ）メカニズムを使用するが、ＨＡＲＱメカニズムは、多くの再送回数を必要とする。
【０００４】
このほか、ＶｏＬＴＥ（Ｖｏｉｃｅ  ｏｖｅｒ  ＬＴＥ）トラフィックにおいて、音声品質は、タイムラグ、ジッタ、パケットロス率などの要因の影響を受ける。パケットロス率はユーザの体験に大きく影響し、パケットロス率が高すぎると音声に歪み、文字の飲み込み、途切れ、不明瞭などの問題が生じる。また、ＶｏＬＴＥトラフィックはタイムラグへの要求も高く、タイムラグが大きすぎると遅延やエコーなどユーザ体験に影響を与える問題が生じる。第３世代パートナーシッププロジェクト（３ＧＰＰ、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）プロトコルにおいて、音声トラフィックに対する要求は、エンドツーエンド遅延が２００  ｍｓ以内、パケットロス率が１％以内であってこそ、良好な音声トラフィックを提供することができる。無線リンク制御（ＲＬＣ、Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤーは、ＶｏＬＴＥトラフィックのための非認証（ＵＭ、Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）モードを配置してよく、これにより、音声パケットは、物理レイヤーで復調が失敗すると直ちに破棄され、ユーザ体験に影響を与えることになる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本開示の実施例は、通信プロトコルスタックの第１プロトコルレイヤーがパケットの検査に失敗した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送するステップと、前記通信プロトコルスタックの第２プロトコルレイヤーが、前記パケットの第２プロトコルレイヤーの識別ビットを検証するステップと、前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するステップと、を含む、パケット修復方法を提供する。
【０００６】
本開示の実施例は、通信プロトコルスタックの第１プロトコルレイヤーでパケットの検査に失敗したと確定した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送するように配置された配送モジュールと、前記通信プロトコルスタックの第２プロトコルレイヤーが、前記パケットの前記第２プロトコルレイヤーの識別ビットを検証し、前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するように配置された検証モジュールと、を含む基地局をさらに提供する。
【０００７】
本開示の実施例は、実行可能な命令を含むプログラムを記憶したメモリと、前記プログラムを実行して、本開示の実施例のパケット修復方法を実現するプロセッサとを備える端末をさらに提供する。
【０００８】
本開示の実施例は、コンピュータプログラムを記憶し、前記コンピュータプログラムが実行されるときに本開示の実施例のパケット修復方法を実現する、コンピュータ読み取り可能な記憶媒体をさらに提供する。
【図面の簡単な説明】
【０００９】
【図１】図１は本開示の実施例のパケット修復方法のフロー概念図である。
【図２】図２は本開示の実施例のパケット修復方法のフロー概念図である。
【図３】図３は本開示の実施例の基地局の構造概念図である。
【図４ａ】図４ａは本開示の実施例のパケットのＭＡＣサブレイヤーヘッダの構造概念図、及び本開示の実施例のパケットのＭＡＣサブレイヤー検証のフロー概念図である。
【図４ｂ】図４ｂは本開示の実施例のパケットのＭＡＣサブレイヤーヘッダの構造概念図、及び本開示の実施例のパケットのＭＡＣサブレイヤー検証のフロー概念図である。
【図４ｃ】図４ｃは本開示の実施例のパケットのＭＡＣサブレイヤーヘッダの構造概念図、及び本開示の実施例のパケットのＭＡＣサブレイヤー検証のフロー概念図である。
【図４ｄ】図４ｄは本開示の実施例のパケットのＭＡＣサブレイヤーヘッダの構造概念図、及び本開示の実施例のパケットのＭＡＣサブレイヤー検証のフロー概念図である。
【図５】図５は本開示の実施例のパケットのＲＬＣサブレイヤーヘッダの構造概念図である。
【発明を実施するための形態】
【００１０】
以下では図と具体的な実施例を組み合わせて、本開示の技術案をさらに詳細に説明する。
【００１１】
図１は本開示の実施例のパケット修復方法のフロー概念図である。図１に示すように、本開示の実施例のパケット修復方法は、以下のステップ１０１〜１０３を含む。
【００１２】
ステップ１０１、通信プロトコルスタックの第１プロトコルレイヤーがパケットの検査に失敗した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送する。
【００１３】
本実施例において、前記第１プロトコルレイヤーは物理レイヤーであってよい。
【００１４】
実際の応用において、ＬＴＥネットワークにおける基地局の物理レイヤーは、ハイブリッド自動再送要求（ＨＡＲＱ、Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ｒｅＱｕｅｓｔ）と組み合わされる際に、巡回冗長（ＣＲＣ、Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）検査を行う必要があり、ＣＲＣ検査をパスしなかった場合に、対応するパケットに対するＨＡＲＱが失敗したと判断し、そのパケットは次のプロトコルレイヤーに配送されず、ＣＲＣ検査をパスしたパケットは次のプロトコルレイヤーに配送される。しかし、下記の表１に示すように、ＬＴＥネットワークの物理レイヤーパケットのビットロス率をシミュレーションすることにより、パケットのビットロス率（表１の横軸ＢＥＲ）は物理レイヤーにおいて５０％を超えるという状況は生じないということが分かり、すなわち、ＬＴＥネットワークの物理レイヤーでのパケットのビットロス率は５０％以下であり、累積分布関数（ＣＤＦ、Ｃｕｍｕｌａｔｉｖｅ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）（すなわち、表１の縦軸ＣＤＦ）が７８％の確率であっても、パケットのビットロス率は３０％以下であるため、物理レイヤーに対するＣＲＣに失敗したパケットは、アプリケーションレイヤー内でやや大きな確率をもって正確に解析される。
【００１５】
【表１】
2021502025.tif 000003
【００１６】
また、ＬＴＥネットワークではトランスポート方式でデータを配送するが、パケットを解析する際は、一般的に、各プロトコルレイヤーに対応するヘッダメッセージを解析し、パケットが物理レイヤーのＣＲＣ検査に失敗しても、そのパケットのヘッダのビットデータに誤りがなければ、そのパケットがアプリケーションに配送されるまで、次のプロトコルレイヤーに引き続き配送し、アプリケーションレイヤーに関連するプロトコルまたはアプリケーションによってそのパケットの内容を解析することができる。
【００１７】
よって、本実施例では、物理レイヤーがパケットのＣＲＣ検査に失敗した場合でも、次のプロトコルレイヤーに前記パケットを配送する。
【００１８】
ステップ１０２、前記通信プロトコルスタックの第２プロトコルレイヤーが、前記パケットの第２プロトコルレイヤーの識別ビットを検証する。
【００１９】
ステップ１０３、前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄する。
【００２０】
ステップ１０４、前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送する。
【００２１】
本実施例において、前記第２のプロトコルレイヤーは、媒体アクセス制御（ＭＡＣ、Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）サブレイヤー、無線リンク制御（ＲＬＣ、Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）サブレイヤーおよびパケットデータコンバージェンスプロトコル（ＰＤＣＰ、Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）サブレイヤーを含んでよい。
【００２２】
前記通信プロトコルスタックの第２プロトコルレイヤーが前記パケットの第２プロトコルレイヤーの識別ビットを検証するステップは、媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに基づき、前記パケットのヘッダデータをビット単位で検証し、前記パケットのヘッダデータのビットのデータが、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致している場合に、前記パケットへの検証をパスしたと確定して、前記パケットを無線リンク制御サブレイヤーに配送し、前記パケットのヘッダデータに、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致しないビットが存在する場合に、前記パケットを破棄するということと、前記無線リンク制御サブレイヤーは、前記パケットの無線リンク制御シーケンス番号の値を、前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値とマッチングし、前記パケットの無線リンク制御シーケンス番号の値が、前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値内である場合に、前記パケットへの検証をパスしたと確定し、前記パケットをパケットデータコンバージェンスプロトコルサブレイヤーに配送し、前記パケットの無線リンク制御シーケンス番号の値が、前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲を超える場合に、前記パケットを破棄するということと、前記パケットデータコンバージェンスプロトコルサブレイヤーは、前記パケットのパケットデータコンバージェンスプロトコルシーケンス番号の値と、前記パケットデータコンバージェンスプロトコルサブレイヤーに予め定められたシーケンス番号の値とを比較し、比較結果を生成し、前記比較結果が予め定められた閾値以下である場合に、前記パケットをアプリケーションレイヤーに配送し、前記比較結果が予め定められた閾値より大きい場合に、前記パケットを破棄するということを含んでよい。
【００２３】
本実施例において、無線リンク制御（ＲＬＣ、Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）シーケンス番号の値は、非認証モード（ＵＭ、Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）無線リンク制御シーケンス番号（ＳＮ、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）値であってよい。
【００２４】
本実施例において、アプリケーション層にはパケットをデコードする際に、一定の障害許容設定があり、ビットエラーレートが低いという前提において、正しいパケットビットを復元できる確率は非常に高く、特に、ＶｏＬＴＥトラフィックに対して、ＲＬＣサブレイヤーがＵＭモードにあるという前提では、内容は誤っているがヘッダは誤っていないパケットをアプリケーションレイヤーに強制的に配送してデコードし、アプリケーションレイヤーは、前記パケットを一定の確率で解析し、アプリケーションレイヤーの関連復号器は、前記パケットの残存する有効ビットと、前後の音声メッセージに関する情報とによって、前記パケットの位相及び振幅を復元でき、前記パケットが運ぶ元の音声波形を最大限復元でき、これにより音声の損失を最小限にする。したがって、本開示の実施例のパケット復元方法は、パケットロス率を効果的に低減することができる。さらに、再送メカニズムを使用した場合でも、本開示の実施例のパケット復元方法を用いることにより、再送回数を効果的に削減することができる。これに鑑み、本開示の実施例のパケット復元方法は、タイムラグを改善することができ、リアルタイム通信に有利となる。
【００２５】
実際の応用において、本開示の実施例が提供するパケット修復方法は、基地局上りシステムにおいて物理レイヤーでＣＲＣ検査に失敗したパケットをレイヤー毎にマーキングし、パケットが順次配送されるプロトコルレイヤー毎に、パケットヘッダ内容がマッチングするはずの閾値を設定し、全てのプロトコルレイヤー閾値に合致するパケットだけが最終的にアプリケーションレイヤーに配送され、何れのレイヤーの閾値も満たさないパケットは破棄操作処理され、例えば、以下のステップ（１）〜（３）によって実施してよい。
（１）物理レイヤーでＨＡＲＱを経た後、ＣＲＣ検査に失敗したパケットは、マーキングが必要な対象パケットであり、ＣＲＣ検査が正しいパケットは、そのまま次のプロトコルレイヤーに配送される。
（２）マーキングするパケットは、引き続き次のプロトコルレイヤーに配送され、ヘッダのマッチングが行われ、例えば、ＭＡＣサブレイヤーヘッダのマッチングが先に行われ、ＭＡＣサブレイヤーヘッダデータが正しければ、引き続きＲＬＣサブレイヤーに配送され、ＲＬＣサブレイヤーヘッダのマッチングが行われ、ＲＬＣサブレイヤーヘッダデータが正しければ、引き続きＰＤＣＰサブレイヤーに配送され、ＰＤＣＰサブレイヤーヘッダのマッチングが行われ、ＰＤＣＰサブレイヤーヘッダデータが正しければ、Ｓ１インタフェースを介してパケットを送信することができる。
（３）いかなるレイヤーヘッダもマッチングしないパケットは、そのままそのプロトコルレイヤーで破棄操作処理され、つまり、パケット破棄処理が行われる。
【００２６】
一部の実施例では、図２に示すように、本開示の実施例のパケット修復方法におけるステップ１０４はステップ１０４′によって代替され、すなわち、前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットを前記通信プロトコルスタックの第３プロトコルレイヤーに配送し、前記通信プロトコルスタックの第３プロトコルレイヤーは、前記パケットの第３プロトコルレイヤーの識別ビットの検証を行い、前記パケットの第３プロトコルレイヤーの識別ビットへの検証が失敗した場合に、前記パケットを破棄し、前記パケットの第３プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送する。
【００２７】
前記通信プロトコルスタックの第３のプロトコルレイヤーは、ネットワーク相互接続プロトコルサブレイヤー、伝送制御プロトコルサブレイヤーまたはユーザデータプロトコルサブレイヤー、およびリアルタイム伝送プロトコルサブレイヤーを含む。
【００２８】
例えば、上記ステップ（２）において、ＰＤＣＰサブレイヤーヘッダデータが正しければ、ＩＰサブレイヤーヘッダのマッチング、ＴＣＰサブレイヤーヘッダのマッチングまたはＵＤＰサブレイヤーヘッダのマッチング、およびＲＴＰサブレイヤーヘッダのマッチングを継続し、各レイヤーヘッダが正しくすべてマッチングすれば、パケットをＳ１インタフェースを介して送信することができる。
【００２９】
実際の応用において、ＲＴＰサブレイヤーは、例えば、ＶｏＬＴＥトラフィックに特有であるため、ＲＴＰサブレイヤーヘッダのマッチングを行うことも選択できる。
【００３０】
以上のように、本開示の実施例が提供するパケット修復方法を用いて、物理レイヤーのＣＲＣ検査に失敗したパケットをさらに検証することによって、すなわち、ＬＴＥプロトコルスタックでレイヤー毎に検証を行い、特にＶｏＬＴＥトラフィックのパケットについては、各プロトコルレイヤーのヘッダデータが正しく解析できたパケットを、アプリケーションレイヤーに強制的に配送して復元処理を行うことによって、アプリケーションレイヤーは、当該パケットに対して一定の確率でパケットの内容を正しく解析することができる。したがって、本開示の実施例が提供するパケット修復方法は、ＣＲＣ検査に失敗したパケットを物理レイヤーで直接捨てるという方策と比べると、効率的にパケットロス率を低減でき、ユーザの体験を向上させている。一方、再送メカニズムを使用した場合でも、本開示の実施例のパケット復元方法を用いることにより、再送回数を効果的に削減することができる。
【００３１】
図３は本開示の実施例の基地局の構造概念図である。図３に示すように、本開示の実施例の基地局は、配送モジュール２０１と検証モジュール２０２とを含む。
【００３２】
配送モジュール２０１は、通信プロトコルスタックの第１プロトコルレイヤーでパケットの検査に失敗したと確定した場合に、前記通信プロトコルスタックの第２プロトコルレイヤーに前記パケットを配送するように配置される。
【００３３】
検証モジュール２０２は、前記通信プロトコルスタックの第２プロトコルレイヤーが、前記パケットの第２プロトコルレイヤーの識別ビットを検証し、前記パケットの第２プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するように配置される。
【００３４】
一部の実施例において、前記配送モジュールは、前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送するようにさらに配置される。
【００３５】
前記通信プロトコルスタックの第１プロトコルレイヤーは物理レイヤーであり、前記通信プロトコルスタックの第２プロトコルレイヤーは、媒体アクセス制御サブレイヤーと、無線リンク制御サブレイヤーと、パケットデータコンバージェンスプロトコルサブレイヤーと、を含む。
【００３６】
一部の実施例において、前記検証モジュールは、媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに従って、前記パケットのヘッダデータをビット単位で検証し、前記パケットのヘッダデータ内のビットのデータが、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致する場合に、前記媒体アクセス制御サブレイヤー内の前記パケットへの検証をパスしたと確定し、前記パケットのヘッダデータ内に、前記媒体アクセス制御サブレイヤー内に予め定められたパケットヘッダフォーマットに合致しないビットが存在する場合に、パケットが破棄されるように配置され、前記配送モジュールは、前記媒体アクセス制御サブレイヤーにおいて前記パケットの検証をパスしたと確定した場合に、前記パケットを前記無線リンク制御サブレイヤーに配送するように配置される。
【００３７】
一部の実施例において、前記検証モジュールは、前記無線リンク制御サブレイヤーで前記パケットの無線リンク制御シーケンス番号の値を前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値とマッチングし、前記パケットの無線リンク制御シーケンス番号の値が前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値内にある場合に、前記無線リンク制御サブレイヤーにおいて前記パケットへの検証をパスしたと確定し、前記パケットの無線リンク制御シーケンス番号の値が前記無線リンク制御サブレイヤーに予め定められたウィンドウ範囲値を超える場合に、前記パケットを破棄するようにさらに配置され、前記配送モジュールは、前記無線リンク制御サブレイヤーにおいて前記パケットへの検証をパスしたと確定した場合に、前記パケットをパケットデータコンバージェンスサブレイヤーに配送するようにさらに配置される。
【００３８】
一部の実施例において、前記検証モジュールは、前記パケットデータコンバージェンスプロトコルサブレイヤーが、前記パケットのパケットデータコンバージェンスプロトコルシーケンス番号の値を前記パケットデータコンバージェンスプロトコルのサブレイヤーに予め定められたシーケンス番号の値と比較し、比較結果を生成し、前記比較結果が予め定められた閾値よりも大きい場合に、前記パケットを破棄するようにさらに配置され、前記配送モジュールは、前記比較結果が予め定められた閾値以下である場合に、前記パケットをアプリケーションレイヤーに配送するように配置される。
【００３９】
一部の実施例において、前記配送モジュールは、前記パケットの第２プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記通信プロトコルスタックの第３プロトコルレイヤーに前記パケットを配送するようにさらに配置され、前記検証モジュールは、前記通信プロトコルスタックの第３プロトコルレイヤーが前記パケットの第３プロトコルレイヤーの識別ビットを検証し、前記パケットの第３プロトコルレイヤーの識別ビットへの検証に失敗した場合に、前記パケットを破棄するようにさらに配置され、前記配送モジュールは、前記パケットの第３プロトコルレイヤーの識別ビットへの検証をパスした場合に、前記パケットをアプリケーションレイヤーに配送するようにさらに配置される。
【００４０】
前記通信プロトコルスタックの第３のプロトコルレイヤーは、ネットワーク相互接続プロトコルサブレイヤー、伝送制御プロトコルサブレイヤーまたはユーザデータプロトコルサブレイヤー、およびリアルタイム伝送プロトコルサブレイヤーを含んでよい。
【００４１】
実際の応用においては、リアルタイムでプロトコルサブレイヤーを伝送することも選択できる。
【００４２】
本開示の実施例の配送モジュール２０１と検証モジュール２０２は、ソフトウェア、ハードウェア又はそれらの組み合わせによって実現されてもよく、前記ハードウェアは、例えば、中央処理装置（ＣＰＵ、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロプロセッサ（ＭＰＵ、Ｍｉｃｒｏ  Ｐｒｏｃｅｓｓｏｒ  Ｕｎｉｔ）、デジタル信号処理装置（ＤＳＰ、Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）、コンピュータ、又は集積回路などを含んでよく、メモリを含んでもよい。
【００４３】
前記メモリは、任意のタイプの揮発性メモリもしくは不揮発性メモリ、またはそれらの組み合わせであってよい。不揮発性メモリは、読み取り専用メモリ（ＲＯＭ、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、プログラマブル読み取り専用メモリ（ＰＲＯＭ、Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ、Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ、Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気ランダムアクセスメモリ（ＦｅＲＡＭ、Ｆｅｒｒｏｍａｇｎｅｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、フラッシュメモリ（Ｆｌａｓｈ  Ｍｅｍｏｒｙ）、磁気表面メモリ、光ディスク、または読み取り専用ディスク（ＣＤ−ＲＯＭ、Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）であり得る。磁気表面メモリは、磁気ディスクメモリまたは磁気テープメモリであってよい。揮発性メモリは、外部キャッシュとして使用されるランダムアクセスメモリ（ＲＡＭ、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）であってよい。限定ではなく例示として説明すると、多くの形式のＲＡＭを本開示の実施例に用いて実施することができ、例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ、Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、シンクロナススタティックランダムアクセスメモリ（ＳＳＲＡＭ、Ｓｙｎｃｈｒｏｎｏｕｓ  Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ、Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、シンクロナスダイナミックランダムアクセスメモリ（ＳＤＲＡＭ、Ｓｙｎｃｈｒｏｎｏｕｓ  Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ダブルデータレートシンクロナスダイナミックランダムアクセスメモリ（ＤＤＲＳＤＲＡＭ、Ｄｏｕｂｌｅ  Ｄａｔａ  Ｒａｔｅ  Ｓｙｎｃｈｒｏｎｏｕｓ  Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、拡張シンクロナスダイナミックランダムアクセスメモリ（ＥＳＤＲＡＭ、Ｅｎｈａｎｃｅｄ  Ｓｙｎｃｈｒｏｎｏｕｓ  Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、シンクロナス・リンク・ダイナミックランダムアクセスメモリ（ＳＬＤＲＡＭ、ＳｙｎｃＬｉｎｋ  Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、又はダイレクトメモリバス・ランダムアクセスメモリ（ＤＲＲＡＭ、Ｄｉｒｅｃｔ  Ｒａｍｂｕｓ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）などがある。本開示の実施例に記載のメモリは、任意の適切なタイプのメモリを含むがこれらに限定されない。
【００４４】
以下、本開示の実施例におけるパケットの各プロトコルレイヤーヘッダの検証について、例を挙げて詳細に説明する。
【００４５】
例えば、ＬＴＥネットワークでは、物理レイヤーＱＣＩ（ＱｏＳ  Ｃｌａｓｓ  Ｉｄｅｎｔｉｆｉｅｒ）１トラフィックにおいて巡回冗長検査（ＣＲＣ、Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）に失敗したパケットに対してＭＡＣサブレイヤーヘッダ検証処理が行われる。ＱＣＩ１トラフィックに対応するロケールＩＤ（ＬＣＩＤ、Ｌｏｃａｌ  ＩＤ）を５とすることができ、ＬＣＩＤが５の場合に対応するチャネルは論理チャネル（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）であるということ、すなわち、論理チャネル上で制御プレーン情報と符号化され暗号化された音声又はデータが伝送されるということを、下記の表２及び表３により確定することができる。
【００４６】
前記ＭＡＣサブレイヤーヘッダデータは複数のサブヘッダから構成されてよく、図４ａでは、プロトコルデータユニット（ＰＤＵ、Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）のＭＡＣサブレイヤーヘッダデータの構成が示されており、図４ｂと図４ｃでは、ＭＡＣサブレイヤーサブヘッダの内容及び意味が示されており、具体的な内容は、３ＧＰＰ３６．３２１プロトコルにおけるＭＡＣサブレイヤーヘッダフォーマットの詳細な説明を参照でき、ここでは改めて説明しない。
【００４７】
【表２】
2021502025.tif 000004
【００４８】
【表３】
2021502025.tif 000005
【００４９】
図４ｄは本開示の実施例における、ＭＡＣサブレイヤー内に予め定められたパケットヘッダフォーマットに従い、前記パケットのＭＡＣサブレイヤーヘッダデータのビット単位で検証を行うフローチャートである。前記パケットのＭＡＣサブレイヤーヘッダデータ内のビットのデータが、前記ＭＡＣサブレイヤーに予め定められたパケットヘッダフォーマットに合致している場合に、前記パケットのＭＡＣサブレイヤーが検証をパスしたと確定し、前記パケットを次のプロトコルレイヤーに配送し、前記パケットのＭＡＣサブレイヤーのヘッダデータの中に、前記ＭＡＣサブレイヤー内に予め定められたパケットヘッダフォーマットに合致しないビットが存在する場合に、前記パケットを破棄する。図４ｄに示すように、本開示の実施例におけるパケットのＭＡＣサブレイヤーのヘッダデータに対してビット単位で行われる検証のステップは、以下のステップ３０１から３０９を含む。
【００５０】
ステップ３０１、Ｅフィールドが０か否かを判断し、Ｅフィールドの値が０の場合はステップ３０２を実行し、Ｅフィールドの値が０でない場合はステップ３０６を実行する。
【００５１】
ステップ３０２、Ｅフィールドの値が０の場合、サブヘッダはＭＡＣサブレイヤーヘッダの最後のサブヘッダであると確定し、そのサブヘッドの長さは５バイトである。
【００５２】
ステップ３０３、パケットのＬＣＩＤが５であるか否かを判断し、ＬＣＩＤが５である場合にはステップ３０４を実行し、ＬＣＩＤの値が５でない場合にはステップ３１０を実行する。
【００５３】
ステップ３０４、Ｌフィールドの長さが、サービスデータユニット（ＳＤＵ）の長さと合致するか否かを判断し、合致する場合はステップ３０５を実行し、合致しない場合はステップ３１０を実行する。
【００５４】
ステップ３０５、ＭＡＣサブレイヤーヘッダ検証をパスしたと確定し、次のプロトコルレイヤーにパケットを配送する。
【００５５】
ステップ３０６、サブヘッダが最後のサブヘッダではないと確定する。
【００５６】
ステップ３０７、パケットのＬＣＩＤの値が０１０１１〜１１０００の間にあるか否かを判断し、パケットのＬＣＩＤの値が０１０１１〜１１０００の間にある場合はステップ３１０を実行し、パケットのＬＣＩＤの値が０１０１１〜１１０００の間にない場合はステップ３０８を実行する。
【００５７】
ステップ３０８、ＬＣＩＤの値が非ＱＣＩ１の値と等しいか否かを判断し、等しい場合はステップ３０９を実行し、等しくない場合はステップ３０４を実行する。
【００５８】
ステップ３０９、ＬＣＩＤの値、Ｌフィールド、Ｆフィールドを組み合わせて、対応するサブヘッダ長さを確定し、対応するビットをスキップして次のサブヘッダを検証する。
【００５９】
ステップ３１０、対応するパケットを破棄する。
【００６０】
上記のパケットのヘッダについてビット単位で解析とマッチングを行い、プロトコルレイヤーで予め定められたパケットヘッダの各ビットの意味から、サブヘッダの長さを確定し、サブヘッダ単位で確認し、マッチングしない箇所が見つかった場合に、パケットに対してパケット破棄処理を行う。例えば、ＣＲＣ検査に失敗したパケット１０１０１０００１１１０００……は、上位から下位の順にプロトコルレイヤーで予め定められたパケットヘッダフォーマットを照合し、プロトコルレイヤーで予め定められたパケットヘッダフォーマットの第１ビットがＲ、Ｒがデフォルトで０、ＣＲＣ検査に失敗したパケット１０１０１０００１１１０００……の第１ビットが１で、プロトコルレイヤーで予め定められたパケットヘッダフォーマットの第１ビットとマッチングしない場合、このプロトコルレイヤーのヘッダ検証に失敗したと判断し、そのままそのパケットをそのプロトコルレイヤーで破棄することができる。
【００６１】
パケットは、ＭＡＣサブレイヤーのヘッダ検証をパスした後、ＲＬＣサブレイヤーに配送されるため、ＲＬＣサブレイヤーは、ＲＣＬレイヤーの識別ビット形式に従って前記パケットのＲＬＣサブレイヤー識別ビットを検証する。
【００６２】
一部の実施例において、前記パケットのＲＬＣサブレイヤー識別ビットは、非認証モードのＲＬＣサブレイヤーシーケンス番号（ＳＮ）値である。
【００６３】
本開示の実施例において、前記パケットのＲＬＣサブレイヤーＳＮ値を、ＲＬＣサブレイヤーに予め定められたウィンドウ範囲値とマッチングし、前記パケットのＲＬＣサブレイヤーシーケンス番号（ＳＮ）値が前記ＲＬＣサブレイヤーに予め定められたウィンドウ範囲値内にある場合、前記パケットのＲＬＣサブレイヤーヘッダ検証をパスしたと確定し、前記パケットを次のプロトコルレイヤーに配送し、前記パケットのＲＬＣサブレイヤーシーケンス番号（ＳＮ）値が前記ＲＬＣサブレイヤーに予め定められたウィンドウ範囲値を超える場合に、前記パケットを破棄する。
【００６４】
実際の応用において、ＲＬＣサブレイヤーのシーケンス番号（ＳＮ）の長さは５ビット、ＳＮ範囲はＳＮ０〜ＳＮ３１、ＳＮの半分のウィンドウ長さは１６として予め設定してよく、ＲＣＬサブレイヤーの識別ビットフォーマットに従って、前記パケットのＲＬＣサブレイヤー識別ビットを検証することは、前記パケットのＲＬＣサブレイヤーＳＮ値を検証することであり、パケットから解析されたＲＬＣサブレイヤーＳＮ値が、前記ＲＬＣサブレイヤーに予め定められた半分のウィンドウ内にある場合、前記パケットのＲＬＣサブレイヤーのヘッダ検証をパスする。
【００６５】
図５は、ＵＭモードにおけるＲＬＣサブレイヤーＳＮの長さが５ビットであるＳＮヘッダのフォーマットである。実際の応用においては、パケットのＲＬＣサブレイヤーのヘッダを解析する際に、ＳＮの値を確定するだけでよい。ＣＲＣ検査に失敗したが、ＲＬＣサブレイヤーに既に配送されたパケットについては、ＲＬＣサブレイヤーＳＮの長さが５ビットであり、ＲＬＣサブレイヤーのヘッダの長さが１バイトであるため、パケットの最上位１バイトのデータフォーマットを検証すればよく、ＣＲＣ検査に失敗したが、配送されたパケットの最上位１バイトが００１０１１１０であるとすると、図５から、そのパケットのＲＬＣサブレイヤーＳＮ値は０１１１０、つまり、１４であると解析され、目下解析しているＣＲＣ検査に失敗したパケットのＳＮ値は１４であることが分かる。目下のパケットの前に受信したパケットのＲＬＣサブレイヤーＳＮ値が１である場合、目下のパケットの継続エラーであると確定し、目下のパケットを破棄する。目下のパケットの前に受信したパケットのＲＬＣサブレイヤーＳＮ値が１３である場合、目下のパケットのＲＬＣサブレイヤーヘッダ検証にパスしたと確定し、目下のパケットを次のプロトコルレイヤーに配送する。
【００６６】
通常の場合、ＣＲＣ検査をパスしたパケットは、解析されたＲＬＣサブレイヤーＳＮ値に関わらず、そのパケットは破棄されない。
【００６７】
パケットは、ＲＬＣサブレイヤーのヘッダ検証を経た後、ＰＤＣＰサブレイヤーに配送され、ＰＤＣＰサブレイヤーの識別ビットフォーマットに従って、前記パケットのＰＤＣＰ識別ビットを検証する。
【００６８】
一部の実施例において、前記パケットのＰＤＣＰ識別ビットは、ＰＤＣＰサブレイヤーシーケンス番号（ＳＮ）値である。
【００６９】
本開示の実施例において、前記パケットのＰＤＣＰサブレイヤーのシーケンス番号（ＳＮ）値を、ＰＤＣＰサブレイヤーに予め定められたＳＮ値と比較し、比較結果を生成し、前記比較結果が予め定められた閾値以下である場合、前記パケットを、通信プロトコルスタック内の前記ＰＤＣＰサブレイヤーの次のレイヤーに配送し、前記比較結果が予め定められた閾値以上である場合に、前記パケットを破棄する。
【００７０】
実際の応用において、ＰＤＣＰサブレイヤーＳＮの長さは、７ビットとして予め設定することができる。解析されたパケットのＰＤＣＰサブレイヤーＳＮ値が、ＰＤＣＰサブレイヤーの直近で受信したパケットのＰＤＣＰサブレイヤーＳＮ値から遠い場合、前記パケットのＰＤＣＰサブレイヤーのヘッダ検証に失敗したと判断し、前記パケットを破棄処理する。解析されたパケットのＰＤＣＰサブレイヤーＳＮ値が、ＰＤＣＰサブレイヤーの直近で受信したパケットのＰＤＣＰサブレイヤーＳＮ値に近い場合、前記パケットのＰＤＣＰサブレイヤーのヘッダ検証をパスしたと判断し、前記パケットを次のレイヤーに引き続き配送する。例えば、ＰＤＣＰサブレイヤーが既に受信したパケットのＰＤＣＰサブレイヤーＳＮ値が１、２、３、４、５である場合、ＰＤＣＰサブレイヤーが既に受信したパケットのＳＮ値（１、２、３、４、５）を、予め定められた閾値として設けてよく、目下受信したパケットについて解析されたＰＤＣＰサブレイヤーＳＮ値が４０である場合は、前記ＰＤＣＰサブレイヤーが既に受信したパケットのＰＤＣＰサブレイヤーＳＮ値（１、２、３、４、５）に近接せず、つまり、目下受信したパケットのＰＤＣＰサブレイヤーヘッダに誤りがあると確定し、目下受信したパケットをパケット破棄処理し、目下受信したパケットについて解析されたＰＤＣＰサブレイヤーＳＮ値が６または７であり、前記ＰＤＣＰサブレイヤーが既に受信したパケットのＰＤＣＰサブレイヤーＳＮ値（１、２、３、４、５）に近い場合は、目下受信したパケットのＰＤＣＰサブレイヤーヘッダ検証にパスしたと確定し、目下受信したパケットを次のプロトコルレイヤーに引き続き配送する。
【００７１】
パケットのＩＰサブレイヤーヘッダ、ＴＣＰサブレイヤーヘッダ／  ＵＤＰサブレイヤーヘッダ、およびＲＴＰサブレイヤーヘッダの検証方法は、本分野の常規検証方法であり、ここでは改めて説明しない。
【００７２】
本開示の実施例は、実行可能な命令を含むプログラムを記憶したメモリと、前記プログラムを実行して、本開示の実施例のパケット修復方法を実現するプロセッサとを備える端末をさらに提供する。
【００７３】
本開示の実施例は、コンピュータプログラムを記憶し、前記コンピュータプログラムが実行されるときに本開示の実施例のパケット修復方法を実現するコンピュータ読み取り可能な記憶媒体をさらに提供する。
【００７４】
本開示の実施例が提供するパケット修復方法、基地局、端末及びコンピュータ読み取り可能な記憶媒体を用いて、物理レイヤーのＣＲＣ検査に失敗したパケットを引き続き次のプロトコルレイヤーに配送することにより、物理レイヤーのＣＲＣ検査に失敗したパケットをさらに検証し、次のプロトコルレイヤーに予め定められたヘッダフォーマットがこのパケットの対応するヘッダデータにマッチングする場合、アプリケーションレイヤーに配送されるまで、引き続き次のプロトコルレイヤーにパケットを配送し、プロトコルレイヤーに予め定められたヘッダフォーマットとパケットの対応するヘッダデータとがマッチングしない場合に、前記パケットを破棄し、このような方式で、通信ネットワーク構造の変更や悪影響を最小限に抑え、パケットロス率を低減させ、また、再送メカニズムを使用した場合、再送回数を低減させることにより、タイムラグとジッタを低減させることができ、再送によるリソースのオーバーヘッドを低減させ、最終的にユーザ体験が向上する。
【００７５】
ここに記載の実施例及び実施形態は単なる例示であり、本開示の保護範囲を限定するものではなく、当業者は本開示の精神と実質を逸脱しない範囲で、実施例及び実施形態に対して各種の修正と変形をなすことができる。例えば、本開示の実施例及び実施形態における特徴は、任意に組み合わせることができ、本開示の実施例及び実施形態における特徴は、均等置き換えすることができ、実際の応用においては、本開示の実施例及び実施形態の特徴よりもさらに多くの又はさらに少ない特徴を含んでよく、これらの修正及び変形は、すべて本開示の保護範囲内に含まれると見なされるべきである。
【図１】
2021502025.tif 000006
【図２】
2021502025.tif 000007
【図３】
2021502025.tif 000008
【図４ａ】
2021502025.tif 000009
【図４ｂ】
2021502025.tif 000010
【図４ｃ】
2021502025.tif 000011
【図４ｄ】
2021502025.tif 000012
【図５】
2021502025.tif 000013
【国際調査報告】
2021502025.tif 000014
2021502025.tif 000015
2021502025.tif 000016
2021502025.tif 000017