特表2024-543197 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特表2024-543197データパケット処理方法、通信装置、及び通信システム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3a
3b
4a
4b
5
6
7

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-19

(54)【発明の名称】データパケット処理方法、通信装置、及び通信システム

(51)【国際特許分類】

H04L 49/55 20220101AFI20241112BHJP

H04L 1/00 20060101ALI20241112BHJP

【ＦＩ】

H04L49/55

H04L1/00 A

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024532311

(86)(22)【出願日】2022-11-09

(85)【翻訳文提出日】2024-07-05

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

(87)【国際公開番号】W WO2023098430

(87)【国際公開日】2023-06-08

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

(32)【優先日】2021-11-30

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩＴＥＣＨＮＯＬＯＧＩＥＳＣＯ．，ＬＴＤ．

【住所又は居所原語表記】ＨｕａｗｅｉＡｄｍｉｎｉｓｔｒａｔｉｏｎＢｕｉｌｄｉｎｇ，Ｂａｎｔｉａｎ，ＬｏｎｇｇａｎｇＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８１２９，Ｐ．Ｒ．Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村進

(72)【発明者】

【氏名】程浩

【テーマコード（参考）】

5K014

5K030

【Ｆターム（参考）】

5K014BA06

5K030GA12

5K030HA08

5K030HB12

5K030MB01

(57)【要約】

この出願の実施形態は、データパケット処理方法、通信装置、及び通信システムを提供する。方法は、第1のデバイスからデータパケットを受信するステップと、データパケット内の第1のCRCに基づいてデータパケットをチェックするステップと、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックするステップと、データパケットのチェックが失敗し、パケットヘッダのチェックが失敗する場合に、データパケットを廃棄するステップ、又はデータパケットのチェックが失敗するがパケットヘッダのチェックが成功する場合に、データパケットのタイプに基づいてデータパケットを処理するステップとを含む。この解決策において、データパケットは、データパケットをチェックするために使用される第1のCRCと、データパケットのパケットヘッダをチェックするために使用される第2のCRCとを搬送する。データパケットのチェックが失敗するがパケットヘッダのチェックが成功する場合、それは、パケットヘッダが正しく送信されるが、データが誤って送信されることを示す。この場合、第2のデバイスは、データパケットを直接廃棄する代わりに、データパケットのタイプに基づいてデータパケットを処理することができる。このようにして、パケット損失の量を低減することができ、それにより、データ送信効率が向上され、システム容量が増大する。

【特許請求の範囲】

【請求項1】

第1のデバイスからデータパケットを受信するステップと、
前記データパケット内の第1の巡回冗長検査CRCに基づいて前記データパケットをチェックするステップと、
前記データパケット内の第2のCRCに基づいて前記データパケットのパケットヘッダをチェックするステップと、
前記データパケットのチェックが失敗し、前記パケットヘッダのチェックが失敗する場合に、前記データパケットを廃棄するステップ、又は
前記データパケットのチェックが失敗するが前記パケットヘッダのチェックが成功する場合に、前記データパケットのタイプに基づいて前記データパケットを処理するステップと、
を含むデータパケット処理方法。

【請求項2】

前記データパケット内の第2のCRCに基づいて前記データパケットのパケットヘッダをチェックする前記ステップは、
前記データパケットのチェックが失敗する場合に、前記データパケット内の前記第2のCRCに基づいて前記データパケットの前記パケットヘッダをチェックするステップ、
を含む、請求項1に記載の方法。

【請求項3】

前記データパケットのチェックが失敗する場合に、前記データパケットをマークするステップ
を更に含む、請求項1又は2に記載の方法。

【請求項4】

前記データパケットのタイプに基づいて前記データパケットを処理する前記ステップは、
前記データパケットのタイプがユーザプレーンデータである場合に、前記データパケットを廃棄することをスキップするステップ、又は
前記データパケットのタイプが制御プレーンデータである場合に、前記データパケットを廃棄するステップ、
を含む、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記パケットヘッダに基づいて前記データパケットのタイプを決定するステップ、
を更に含む、請求項4に記載の方法。

【請求項6】

前記データパケットから前記第2のCRCを削除するステップ、
を更に含む、請求項1から5のいずれか一項に記載の方法。

【請求項7】

前記第1のCRCが前記データパケットの末尾に位置され、前記第2のCRCが前記データパケットの前記パケットヘッダの後に位置される、請求項1から6のいずれか一項に記載の方法。

【請求項8】

前記第1のCRCは、前記データパケットの前記パケットヘッダ、前記データパケット内のデータ、及び前記第2のCRCに基づいて生成される、請求項1から7のいずれか一項に記載の方法。

【請求項9】

前記第2のCRCは、前記データパケットの前記パケットヘッダに基づいて生成される、請求項1から8のいずれか一項に記載の方法。

【請求項10】

前記第2のCRCは、前記データパケットの前記パケットヘッダ及び前記データパケット内の前記データの一部に基づいて生成される、請求項9に記載の方法。

【請求項11】

前記データパケットが拡張共通公衆無線インタフェースeCPRIデータパケットであり、前記データパケット内の前記データがeCPRIデータを含む、請求項1から10のいずれか一項に記載の方法。

【請求項12】

データパケットを生成するステップであって、前記データパケットが、パケットヘッダと、データと、第1の巡回冗長検査CRCと、第2のCRCとを含み、前記第1のCRCが、前記データパケットをチェックするために用いられ、前記第2のCRCが、前記パケットヘッダをチェックするために用いられる、ステップと、
前記データパケットを第2のデバイスに送信するステップと、
を含むデータパケット処理方法。

【請求項13】

前記パケットヘッダに基づいて前記第2のCRCを生成するステップ
を更に含む、請求項12に記載の方法。

【請求項14】

前記パケットヘッダに基づいて前記第2のCRCを生成する前記ステップは、
前記パケットヘッダと前記データの一部とに基づいて前記第2のCRCを生成するステップ、
を含む、請求項13に記載の方法。

【請求項15】

前記パケットヘッダ、前記データ、及び前記第2のCRCに基づいて前記第1のCRCを生成するステップ、
を更に含む、請求項12から14のいずれか一項に記載の方法。

【請求項16】

前記第1のCRCが前記データパケットの末尾に位置され、前記第2のCRCが前記パケットヘッダの後に位置される、
請求項12から15のいずれか一項に記載の方法。

【請求項17】

前記データパケットが拡張共通公衆無線インタフェースeCPRIデータパケットであり、前記データパケット内の前記データがeCPRIデータを含む、請求項12から16のいずれか一項に記載の方法。

【請求項18】

前記パケットヘッダが前記データパケットのタイプを示し、前記データパケットの前記タイプがユーザプレーンデータ又は制御プレーンデータである、請求項12から17のいずれか一項に記載の方法。

【請求項19】

請求項1から11のいずれか一項に記載の方法を実行するように構成されるモジュール、又は請求項12から18のいずれか一項に記載の方法を実行するように構成されるモジュールを備える、通信装置。

【請求項20】

少なくとも1つのプロセッサを備え、前記少なくとも1つのプロセッサは、請求項1から11のいずれか一項に記載の方法又は請求項12から18のいずれか一項に記載の方法を実施するために、メモリに結合されるとともに、前記メモリ内の命令を読み出して実行するように構成される、通信装置。

【請求項21】

コンピュータプログラムを含み、前記コンピュータプログラムが通信装置によって実行されるときに請求項1から18のいずれか一項に記載の方法が実施される、コンピュータプログラム製品。

【請求項22】

コンピュータプログラム又は命令を記憶し、前記コンピュータプログラム又は前記命令が通信装置によって実行されるときに請求項1から18のいずれか一項に記載の方法が実施される、コンピュータ可読記憶媒体。

【請求項23】

請求項1から11のいずれか一項に記載の方法を実行するように構成される第2のデバイスと、請求項12から18のいずれか一項に記載の方法を実行するように構成される第1のデバイスとを備える、通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
この出願は、参照によりその全体が本明細書に組み入れられる、2021年11月30日付で中国国家知識産権局に出願された、「データパケット処理方法、通信装置、及び通信システム」という名称の中国特許出願第202111450373．5号の優先権を主張する。

【0002】

この出願は、通信技術の分野に関し、特に、データパケット処理方法、通信装置、及び通信システムに関する。

【背景技術】

【0003】

デバイスが互いに通信するとき、データはデバイス間で受信及び送信される必要がある。例えば、第1のデバイスが第2のデバイスにデータを送信する、又は第2のデバイスが第1のデバイスにデータを送信する。

【0004】

データ送信速度を高めるために、1つのサービスパケットが一般に送信のために複数のデータパケットに分割され、その後、受信機は、受信され複数のデータパケットをアセンブルして完全なサービスパケットを取得する。図1は、サービスパケットの図の一例である。1つのサービスパケットは、n個のデータパケットに分割され、順次送信され、nは1よりも大きい整数である。

【0005】

データ受信の精度を確保するために、受信機は、データパケットを受信した後に各データパケットをチェックする必要がある。1つのデータパケットのチェックが失敗する場合、それは、データパケットの送信プロセスでエラーが発生することを示す。一般に、チェックが失敗するデータパケットは直接廃棄される。

【発明の概要】

【0006】

この出願の実施形態は、データ送信効率を向上させてシステム容量を増大させるためのデータパケット処理方法、通信装置、及び通信システムを提供する。

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

【0007】

第1の態様によれば、この出願の一実施形態はデータパケット処理方法を提供する。方法は、第2のデバイス、又は、第2のデバイスにおいて使用されるモジュール（例えば、チップ）によって実行され得る。方法は、第1のデバイスからデータパケットを受信するステップであって、データパケットが、パケットヘッダと、データと、第1の巡回冗長検査（Cyclic Redundancy Check，CRC）と、第2のCRCとを含む、ステップと、データパケット内の第1のCRCに基づいてデータパケットをチェックするステップと、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックするステップと、データパケットのチェック結果及び／又はパケットヘッダのチェック結果に基づいてデータパケットを処理するステップとを含む。

【0008】

想定し得る実施態様において、データパケットのチェック結果及び／又はパケットヘッダのチェック結果に基づいてデータパケットを処理するステップは、データパケットのチェックが成功する場合に、又はデータパケットのチェックが成功してパケットヘッダのチェックが成功する場合に、データパケットを廃棄することをスキップするステップ、データパケットのチェックが失敗してパケットヘッダのチェックが失敗する場合に、データパケットを廃棄するステップ、又は、データパケットのチェックが失敗するがパケットヘッダのチェックが成功する場合に、データパケットのタイプに基づいてデータパケットを処理するステップ、を含む。

【0009】

この解決策において、データパケットは、データパケットをチェックするために使用される第1のCRCと、データパケットのパケットヘッダをチェックするために使用される第2のCRCとを搬送する。データパケットのチェックが失敗するが、パケットヘッダのチェックが成功する場合、それは、パケットヘッダが正しく送信されるが、データが誤って送信されることを示す。この場合、第2のデバイスは、データパケットを直接廃棄する代わりに、データパケットのタイプに基づいてデータパケットを処理することができる。このようにして、パケット損失の量を低減することができ、それにより、データ送信効率が向上され、システム容量が増大する。

【0010】

1つの想定し得る実施態様において、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックするステップは、データパケットのチェックが失敗する場合に、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックするステップであってもよい。データパケットのチェックが失敗する場合、それは、データパケットの送信中にエラーが発生することを示す。このようにして、データパケットのパケットヘッダは、パケットヘッダにエラーが発生するかどうかを決定するためにデータパケット内の第2のCRCに基づいて更にチェックされる。データパケットのチェックが成功する場合、それは、データパケットの送信中にエラーが発生しないことを示す。この場合、チェック回数を減らしてチェック速度を向上させるために、データパケットのパケットヘッダを第2のCRCに基づいてチェックする必要がない。

【0011】

想定し得る実施態様では、データパケットのチェックが失敗する場合に、データパケットがマークされる。言い換えれば、データパケットのチェックが失敗する場合、データパケットは廃棄されない。代わりに、データパケットはマークされる。例えば、データパケットは、データパケットが更に決定される必要があるデータパケットであることを示すために、特殊文字又は特定のビット（又はビット位置）を使用してマークされ得る。続いて、データパケットのパケットヘッダは、再び第2のCRCを用いてチェックされ、第2のCRCのチェック結果に基づいて、データパケットを廃棄するか、データパケットを廃棄しないかどうかが決定される。また、マークは、データパケット内のデータにエラーがあることを、データパケットに対して次の処理を実行するモジュール又はデバイスに示し、又は促すこともできる。

【0012】

想定し得る実施態様において、データパケットのタイプに基づいてデータパケットを処理するステップは、データパケットのタイプがユーザプレーンデータである場合に、データパケットを廃棄することをスキップするステップであってもよく、又は、データパケットのタイプが制御プレーンデータである場合に、データパケットを廃棄するステップであってもよい。

【0013】

前述の解決策によれば、データパケットのタイプがユーザプレーンデータである場合、それは、データパケットのパケットヘッダが正しく送信され、データパケット内のデータに送信エラーが発生し、データがユーザプレーンデータであることを意味する。この場合、送信されたユーザプレーンデータには多少のエラーが発生するが、パケットヘッダが正しく送信されているため、ユーザプレーンデータを正しく処理することができる。加えて、ユーザプレーンデータのエラーは、ユーザ体験にわずかに影響を及ぼす可能性があり、実際には他のより深刻な影響を引き起こさない。したがって、第2のデバイスは、データパケットを廃棄しなくてもよい。このようにすると、データ送信効率を向上させ、システム容量を増大させることができる。データパケットのタイプが制御プレーンデータである場合、それは、データパケットのパケットヘッダが正しく送信され、データパケット内のデータに送信エラーが発生し、データが制御プレーンデータであることを意味する。この場合、パケットヘッダは正しく送信されるが、送信された制御プレーンデータにはエラーが発生する。制御プレーンデータのエラーによって引き起こされる結果は比較的深刻であるため、第2のデバイスはデータパケットを廃棄する。

【0014】

想定し得る実施態様では、データパケットがデータパケットのタイプに基づいて処理される前に、データパケットのタイプがパケットヘッダに基づいて最初に決定される。

【0015】

想定し得る実施態様では、データパケットを廃棄しないと決定する場合、第2のデバイスは、データパケットから第2のCRCを更に削除してもよい。

【0016】

前述の態様によれば、データパケットから第2のCRCを削除することにより、後続の処理手順を簡略化し、又は複雑さを低減し、処理モジュールの修正を低減し、第2のデバイス内で送信される必要があるデータ量又は第2のデバイスによって他のデバイスもしくはモジュールに送信される必要があるデータ量を低減することができる。

【0017】

想定し得る実施態様では、第1のCRCがデータパケットの末尾に位置され、第2のCRCがデータパケットのパケットヘッダの後に位置される。

【0018】

想定し得る実施態様において、第1のCRCは、データパケットのパケットヘッダ、データパケット内のデータ、及び第2のCRCに基づいて生成される。或いは、第1のCRCは、データパケットのパケットヘッダとデータパケット内のデータとに基づいて生成される。

【0019】

想定し得る実施態様において、第2のCRCは、データパケットのパケットヘッダに基づいて生成される。

【0020】

この解決策では、パケットヘッダに基づいて第2のCRCが生成されるため、第2のCRCを使用してパケットヘッダの送信の正確さをチェックすることができ、それにより、パケットヘッダの正しい送信を確保できる。

【0021】

想定し得る実施態様において、第2のCRCは、データパケットのパケットヘッダとデータパケット内のデータの一部とに基づいて生成される。

【0022】

この解決策において、第2のCRCは、データパケットの開始位置の後の固定長位置に挿入されてもよい。したがって、第2のCRCは、元のデータを、第2のCRCの前に位置される第1のデータ部分と、第2のCRCの後に位置される第2のデータ部分とに分割することができる。この場合、第2のCRCは、第2のCRCの前に位置されるパケットヘッダ及び第1のデータ部に基づいて生成され得る。1つの態様において、第2のCRCは、パケットヘッダとデータの一部とに基づいて生成されるため、第2のCRCを使用して、パケットヘッダの送信の正確さをチェックすることができ、それにより、データパケットの正しい送信を確保できる。他の態様において、第2のCRCは、データパケットの開始位置の後の固定位置に挿入されるため、第2のCRCを生成及び挿入する態様を簡略化でき、それにより、データパケット生成速度が向上する。

【0023】

1つの想定し得る実施態様では、データパケットが拡張共通公衆無線インタフェース（enhanced common public radio interface，eCPRI）データパケットであり、データパケット内のデータがeCPRIデータを含む。

【0024】

第2の態様によれば、この出願の一実施形態はデータパケット処理方法を提供する。方法は、第1のデバイス、又は、第1のデバイスにおいて使用されるモジュール（例えば、チップ）によって実行され得る。方法は、データパケットを生成するステップであって、データパケットが、パケットヘッダと、データと、第1の巡回冗長検査CRCと、第2のCRCとを含み、第1のCRCが、データパケットをチェックするために用いられ、第2のCRCが、パケットヘッダをチェックするために用いられる、ステップと、データパケットを第2のデバイスに送信するステップとを含む。

【0025】

この解決策において、データパケットは、データパケットをチェックするために使用される第1のCRCと、データパケットのパケットヘッダをチェックするために使用される第2のCRCとを搬送する。したがって、データパケットを受信した後、第2のデバイスは、第1のCRCと第2のCRCとに基づいて、データパケットを処理する態様を決定し得る。

【0026】

想定し得る実施態様では、第2のCRCがパケットヘッダに基づいて生成される。

【0027】

【0028】

想定し得る実施態様において、パケットヘッダに基づいて第2のCRCを生成するステップは、具体的には、パケットヘッダとデータの一部とに基づいて第2のCRCを生成するステップであってもよい。

【0029】

この解決策において、第2のCRCは、データパケットの開始位置の後の固定長位置に挿入されてもよい。したがって、第2のCRCは、元のデータを、第2のCRCの前に位置される第1のデータ部分と、第2のCRCの後に位置される第2のデータ部分とに分割することができる。この場合、第2のCRCは、第2のCRCの前に位置されるパケットヘッダ及び第1のデータ部に基づいて生成され得る。1つの態様において、第2のCRCは、パケットヘッダとデータの一部とに基づいて生成されるため、第2のCRCを使用して、パケットヘッダの送信の正確さをチェックすることができ、それにより、パケットヘッダの正しい送信を確保できる。他の態様において、第2のCRCは、データパケットの開始位置の後の固定位置に挿入されるため、第2のCRCを生成及び挿入する態様を簡略化でき、それにより、データパケット生成速度が向上する。

【0030】

想定し得る実施態様では、第1のCRCがパケットヘッダとデータとに基づいて生成される。

【0031】

想定し得る実施態様において、第1のCRCは、パケットヘッダ、データ、及び第2のCRCに基づいて生成される。

【0032】

この解決策では、パケットヘッダに基づいて第2のCRCが生成されるため、データ、第2のCRC、及び第1のCRCを使用してデータパケットの送信の正確さをチェックすることができ、それにより、パケットヘッダの正しい送信を確保できる。

【0033】

想定し得る実施態様では、第1のCRCがデータパケットの末尾に位置され、第2のCRCがデータパケットのパケットヘッダの後に位置される。

【0034】

1つの想定し得る実施態様では、データパケットがeCPRIデータパケットであり、データパケット内のデータがeCPRIデータを含む。

【0035】

想定し得る実施態様では、パケットヘッダがデータパケットのタイプを示し、データパケットのタイプがユーザプレーンデータ又は制御プレーンデータである。

【0036】

第3の態様によれば、この出願の一実施形態は通信装置を提供する。装置は、第2のデバイス、又は、第2のデバイスにおいて使用されるモジュール（例えば、チップ）であってもよい。装置は、第1の態様の任意の実施態様を実施する機能を有する。当該機能は、ハードウェアを用いて実施されてもよく、又は対応するソフトウェアを実行するハードウェアによって実施されてもよい。ハードウェア又はソフトウェアは、前述の機能に対応する1つ以上のモジュールを含む。

【0037】

第4の態様によれば、この出願の一実施形態は通信装置を提供する。装置は、第1のデバイス、又は、第1のデバイスにおいて使用されるモジュール（例えば、チップ）であってもよい。装置は、第2の態様の任意の実施態様を実施する機能を有する。当該機能は、ハードウェアを用いて実施されてもよく、又は対応するソフトウェアを実行するハードウェアによって実施されてもよい。ハードウェア又はソフトウェアは、前述の機能に対応する1つ以上のモジュールを含む。

【0038】

第5の態様によれば、この出願の一実施形態は、少なくとも1つのプロセッサを含む通信装置を提供し、少なくとも1つのプロセッサは、第1の態様及び第2の態様の任意の実施態様を実施するために、メモリに結合され、メモリ内の命令を読み出して実行するように構成される。メモリは、装置の内部又は外部に位置されてよい。

【0039】

第6の態様によれば、この出願の一実施形態は、プロセッサとメモリとを含む通信装置を提供する。メモリは、コンピュータ命令を記憶するように構成される。装置が実行されると、プロセッサはメモリに記憶されたコンピュータ命令を実行し、それにより、装置は第1の態様及び第2の態様の任意の実施態様を実行する。

【0040】

第7の態様によれば、この出願の一実施形態は、第1の態様及び第2の態様の任意の実施態様のステップを実行するように構成されるユニット又は手段（means）を含む通信装置を提供する。

【0041】

第8の態様によれば、この出願の一実施形態は、プロセッサ及びインタフェース回路を含む通信装置を提供する。プロセッサは、インタフェース回路を介して他の装置と通信し、第1の態様及び第2の態様における任意の実施態様を実行するように構成される。1つ以上のプロセッサが存在する。

【0042】

第9の態様によれば、この出願の一実施形態は、コンピュータプログラム製品を更に提供する。コンピュータプログラム製品は、コンピュータプログラム又は命令を含む。コンピュータプログラム又は命令が通信装置によって実行されると、第1の態様及び第2の態様の任意の実施態様が実行される。

【0043】

第10の態様によれば、この出願の一実施形態は、コンピュータ可読記憶媒体を更に提供し、コンピュータ可読記憶媒体は命令を記憶し、命令が通信装置上で実行されると、第1の態様及び第2の態様の任意の実施態様が実行される。

【0044】

第11の態様によれば、この出願の一実施形態は、第1の態様及び第2の態様における任意の実施態様を実行するように構成されるプロセッサを含むチップシステムを更に提供する。

【0045】

第12の態様によれば、この出願の一実施形態は、第1の態様の任意の実施態様を実行するように構成される第2のデバイスと、第2の態様の任意の実施態様を実行するように構成される第1のデバイスとを含む通信システムを更に提供する。

【図面の簡単な説明】

【0046】

【図1】サービスパケットの図の一例である。

【図2】この出願の一実施形態に係るデータパケット処理方法の概略フローチャートである。

【図3a】この出願の一実施形態に係るデータパケットフォーマットの概略図である。

【図3b】この出願の一実施形態に係るデータパケットフォーマットの他の概略図である。

【図4a】既存のeCPRIベースのサービスパケットの図の一例である。

【図4b】この出願の一実施形態に係るサービスデータパケットへのCRCの挿入の概略図である。

【図5】この出願の一実施形態に係る第1のデバイス及び第2のデバイスの構造の概略図である。

【図6】この出願の一実施形態に係る通信装置の概略図である。

【図7】この出願の一実施形態に係る通信装置の概略図である。

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

【0047】

図2は、この出願の一実施形態に係るデータパケット処理方法の概略フローチャートである。この実施形態では、第1のデバイスが送信側として機能し、第2のデバイスが受信側として機能する。確かに、本方法は、第2のデバイスが送信側として機能し、第1のデバイスが受信側として機能する場合にも適用可能である。例えば、第1のデバイスは、ベースバンド信号処理機能を有する、ベースバンドユニット（baseband unit，BBU）、中央ユニット（Central Unit，CU）、又は分散ユニット（Distributed Unit，DU）などの通信デバイス又は機能モジュールであってもよい。第2のデバイスは無線ユニット（radio unit，RU）であり、ここでのRUは、例えば、中間周波数信号、無線周波数信号、又は中間無線周波数信号を処理する機能を有する、無線遠隔ユニット（radio remote unit，RRU）又は適応アンテナユニット（adaptive antenna unit，AAU）などの通信デバイス又は機能モジュールであってもよい。或いは、第1のデバイスはRUであり、第2のデバイスはBBUである。第1のデバイスと第2のデバイスとの間のインタフェースは、eCPRI又は他のタイプのインタフェースであってもよい。これは、この出願のこの実施形態では限定されない。

【0048】

本方法は以下のステップを含む。

【0049】

ステップ201：第1のデバイスはデータパケットを生成し、データパケットはパケットヘッダ、データ、第1のCRC、及び第2のCRCを含む。

【0050】

第1のCRCは、データパケットをチェックするために使用される。任意選択的に、第1のデバイスは、パケットヘッダ及びデータに基づいて第1のCRCを生成してもよく、又は第1のデバイスは、パケットヘッダ、データ、及び第2のCRCに基づいて第1のCRCを生成する。

【0051】

第2のCRCは、パケットヘッダをチェックするために使用される。任意選択的に、第1のデバイスは、パケットヘッダに基づいて第2のCRCを生成し、又は第1のデバイスは、パケットヘッダとデータの一部とに基づいて第2のCRCを生成する。

【0052】

データパケットのパケットヘッダは、データパケットのタイプを示し、データパケットのタイプは、ユーザプレーンデータ又は制御プレーンデータである。データパケットのタイプがユーザプレーンデータであることは、データパケット内の全てのデータがユーザプレーンデータである、又はユーザプレーンデータ及び他のデータを含むことを意味する。データパケットのタイプが制御プレーンデータであることは、データパケット内の全てのデータが制御プレーンデータである、又は制御プレーンデータ及び他のデータを含むことを意味する。任意選択的に、データパケットが制御プレーンデータを含む場合、データパケットのタイプは制御プレーンデータである。データパケットのタイプは、データパケット内のデータのタイプとしても理解され得る。

【0053】

ユーザプレーンデータは、実際のサービスデータ、例えば音声データ又はパケットサービスデータを指す。制御プレーンデータは、制御メッセージ又はシグナリング、例えば、セルセットアップメッセージ、セル解放メッセージ、又は運用及び保守に関連するメッセージを指す。

【0054】

データパケットのパケットアセンブリ形態は、この出願のこの実施形態では限定されない。具体的には、データパケット内のパケットヘッダ、データ、第1のCRC、及び第2のCRCの間の位置関係は限定されない。例えば、第1のCRCがデータパケットの末尾に位置され、第2のCRCがデータパケットのパケットヘッダの後に位置される。他の例では、第1のCRCがデータパケットの末尾に位置され、第2のCRCがパケットヘッダとデータとの間に位置される。

【0055】

任意選択的に、データパケット内のデータは、保護される必要がある重要な情報（例えば、データパケット処理方法に影響を与える情報）及びサービスデータを含む。ここでの重要な情報は、例えば、eCPRIタイプを含む。この場合、第2のCRCは、パケットヘッダ及び重要な情報の後に挿入されてもよく、パケットヘッダ及び重要な情報に基づいて生成され、それにより、第2のCRCを使用することによって重要な情報の正しい送信を確保できる。例えば、データパケット内のデータはeCPRIタイプ及びeCPRIデータを含む。この場合、第2のCRCは、eCPRIタイプの後の位置に挿入されてもよい。

【0056】

以下、添付図面を参照して、一例を用いてデータパケットのアセンブリ形態について説明する。

【0057】

図3aは、データパケットフォーマットの概略図である。第2のCRCは、パケットヘッダとデータとの間に位置される。具体的には、第2のCRCは、パケットヘッダの後であってデータの前に位置される。第1のCRCは、データパケットの末尾に位置される。第2のCRCは、パケットヘッダに基づいて生成される。第1のCRCは、パケットヘッダとデータとに基づいて生成される、又はパケットヘッダと第2のCRCとデータとに基づいて生成される。異なるデータパケットに関しては、パケットヘッダサイズが異なり得ることに留意すべきである。したがって、異なるデータパケットにおける第2のCRCの開始位置とパケットヘッダの開始位置との間の距離は異なり得る。この実施態様に基づいて、パケットヘッダサイズを事前に学習することができ、それにより、パケットヘッダサイズに基づいてパケットヘッダの後に第2のCRCを挿入することができる。

【0058】

図3bは、データパケットフォーマットの他の概略図である。第2のCRCは、データ内に位置される。第2のCRCが挿入された後、第2のCRCによって元のデータが2つに分割される。第2のCRCの前のデータ部がdata＿1と称され、第2のCRCの後のデータ部がdata＿2と称される。data＿1とdata＿2の組み合わせが元のデータである。第1のCRCは、データパケットの末尾に位置される。第2のCRCは、パケットヘッダとdata＿1とに基づいて生成される。第1のCRCは、パケットヘッダとデータとに基づいて生成される、又はパケットヘッダと第2のCRCとデータとに基づいて生成される。この実施態様に基づいて、長さ（以下、事前設定長と呼ばれる）が事前設定されてもよく、第2のCRCの挿入位置（すなわち、以下では第1の位置と呼ばれる、第2のCRCの開始位置）は、パケットヘッダの開始位置＋事前設定長である。例えば、事前設定長は、第1の長さ以上であり、第1の長さは、様々な既知のパケットヘッダ長の最大の長さであってもよい。このようにして、パケットヘッダの後に第2のCRCを挿入でき、パケットヘッダに第2のCRCが挿入されず、それにより、パケットヘッダの完全性を確保できるようにすることができる。異なるデータパケットのパケットヘッダ長が異なり得るため、異なるデータパケットに関して、第2のCRCの前のdata＿1のビットサイズが異なり得ることに留意すべきである。例えば、事前設定長が100ビットであり、データパケットxのパケットヘッダが60ビットである場合、データパケットx内のdata＿1のビットサイズは40ビットである。データパケットyのパケットヘッダが70ビットである場合、データパケットy内のdata＿1のビットサイズは30ビットである。

【0059】

ステップ202：第1のデバイスが第2のデバイスにデータパケットを送信する。これに対応して、第2のデバイスがデータパケットを受信する。

【0060】

第1のデバイスは、第1のデバイスと第2のデバイスとの間のインタフェースを介して第2のデバイスにデータパケットを送信することができる。或いは、第1のデバイスは、1つ以上のサードパーティデバイスによって実行された転送によって第2のデバイスにデータパケットを送信する。

【0061】

ステップ203：第2のデバイスは、データパケット内の第1のCRCに基づいてデータパケットをチェックする。

【0062】

例えば、データパケットを受信した後、第2のデバイスは、データパケット内の第1のCRCを取得するとともに、データパケット内の第1のCRC以外の部分（例えば、パケットヘッダ、第2のCRC、及びデータ）に基づいて第3のCRCを生成する。

【0063】

第1のCRCが第3のCRCと同じである場合、データパケットのチェックは成功し、それは、データパケットの送信中にエラーが発生しないことを示す。

【0064】

第1のCRCが第3のCRCと異なる場合、データパケットのチェックが失敗し、それは、データパケットの送信中にエラーが発生することを示す。エラーが発生する位置は、パケットヘッダであってもよく、第2のCRCであってもよく、データであってもよく、又は第1のCRCであってもよい。

【0065】

ステップ204：第2のデバイスは、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックする。

【0066】

第2のデバイスは、データパケット内の第2のCRCを取得するとともに、データパケット内の、第2のCRCの前に位置される部分に基づいて第4のCRCを生成する。第2のCRCの前に位置される部分は、パケットヘッダであってもよい。例えば、図3aの例を参照されたい。或いは、第2のCRCの前に位置される部分は、パケットヘッダ及びdata＿1であってもよい。例えば、図3bの例を参照されたい。

【0067】

第2のCRCが第4のCRCと同じである場合、データパケットのパケットヘッダのチェックが成功し、それは、データパケットのパケットヘッダの送信中にエラーが発生しないことを示す。

【0068】

第2のCRCが第4のCRCと異なる場合、データパケットのパケットヘッダのチェックが失敗し、それは、データパケットのパケットヘッダの送信中にエラーが発生することを示す。図3aの例では、第2のCRCが第4のCRCと異なる場合、それは、データパケットのパケットヘッダのチェックが失敗すること、すなわち、パケットヘッダに送信エラーのあるビットが存在することを示す。図3bの例では、第2のCRCと第4のCRCとが異なる場合、パケットヘッダに送信エラーのあるビットが存在しもよく、data＿1に送信エラーのあるビットが存在してもよい。しかしながら、実際の適用中、一般に、データ中のdata＿1の割合は非常に小さい。したがって、図3bの例では、第2のCRCと第4のCRCとが異なる場合、それは、パケットヘッダ又はdata＿1にエラーが発生することを示す。或いは、区別しなくてもよく、一律に、データパケットのパケットヘッダのチェックが失敗する、すなわち、パケットヘッダに送信エラーのあるビットが存在すると考えられる。

【0069】

ステップ205：第2のデバイスは、データパケットのチェック結果及び／又はパケットヘッダのチェック結果に基づいてデータパケットを処理する。

【0070】

以下では、ステップ203からステップ205の2つの異なる具体的な実施態様について説明する。

【0071】

実施態様1：第2のデバイスは、データパケットのチェック結果を取得するためにステップ203を実行するだけでなく、パケットヘッダのチェック結果を取得するためにステップ204も実行し、データパケットのチェック結果及び／又はパケットヘッダのチェック結果に基づいてデータパケットを処理する。

【0072】

ステップ203及びステップ204の実行順序は限定されない。例えば、ステップ203がステップ204の前に実行されてもよく、ステップ204がステップ203の前に実行されてもよく、又は2つのステップが特定の順序でなく同時に実行される。

【0073】

実施態様1では、第2のデバイスがデータパケットのチェック結果及び／又はパケットヘッダのチェック結果に基づいてデータパケットを処理することは、以下のケース1とケース2とに特に分割され得る。

【0074】

ケース1：データパケットのチェックが成功する場合、それは、データパケットの送信中にエラーが発生しないことを示す。この場合、第2のデバイスはデータパケットを廃棄しない。この出願のこの実施形態における「破棄しない」は、例えば、データパケットを、記憶すること、予約すること、継続して処理すること、又は後続の処理のために次のレベルのデータ処理モジュールに送信することであってもよい。この出願のこの実施形態における「廃棄」は、データパケットを、削除すること、他のデータによって上書きすること、更に処理しないこと、又は次のレベルのデータ処理モジュールに送信しないことを含むことができる。ここでは説明が一律に提供され、以下では詳細を再度説明しない。任意選択的に、第2のCRCがデータ内に位置される場合、第2のデバイスは、第2のCRCを削除した後でデータパケット内のデータを取得し得る。例えば、図3bを参照されたい。第2のCRCを削除した後、第2のデバイスは、data＿1及びdata＿2に基づいてデータパケット内のデータを取得し得る。

【0075】

データパケットのチェックが成功する場合、それは、パケットヘッダ及びデータに送信エラーが発生しないことを意味する。したがって、パケットヘッダのチェックも成功すると考えてよい。したがって、データパケットのチェックが成功する場合、それは、データパケットのチェックが成功し、パケットヘッダのチェックが成功することを示し得る。

【0076】

ケース2：データパケットのチェックが失敗する場合、それは、データパケットの送信中にエラーが発生することを示す。エラーが発生する位置は、パケットヘッダであってもよく、第2のCRCであってもよく、データであってもよく、又は第1のCRCであってもよい。この場合、第2のデバイスは代替としてデータパケットを廃棄しなくてもよい。代わりに、第2のデバイスは、パケットヘッダのチェック結果に基づいて、データパケットをどのように処理するかを決定することができる。したがって、ケース2は、以下のケース2．1とケース2．2とに更に分割されてもよい。

【0077】

ケース2．1：データパケットのチェックが失敗するが、データパケットのパケットヘッダのチェックが成功する場合、それは、データパケットに送信エラーが発生するが、エラーが発生する位置がパケットヘッダではない、すなわち、パケットヘッダに送信エラーが発生しないことを示す。この場合、データパケット内のデータに送信エラーが発生すると理解することができる。この場合、第2のデバイスは、データパケットのタイプに基づいてデータパケットを処理することができる。図3aの例は、データ及び／又は第1のCRCに送信エラーが発生することを意味する。図3bの例は、データ及び／又は第1のCRCにおいてdata＿2に送信エラーが発生することを意味する。

【0078】

第2のデバイスは、パケットヘッダに基づいてデータパケットのタイプを決定することができる。例えば、パケットヘッダは、データパケットのタイプを含むことができ、又はデータパケットのタイプを示す表示情報を含むことができ、又はパケットヘッダは、データパケットのタイプに対応することができる。

【0079】

一実施態様において、第2のデバイスがデータパケットのタイプに基づいてデータパケットを処理することは、例えば、データパケットのタイプがユーザプレーンデータである場合に、データパケットを廃棄することをスキップすること、又は、データパケットのタイプが制御プレーンデータである場合に、データパケットを廃棄すること含む。

【0080】

具体的には、データパケットのタイプがユーザプレーンデータである場合、それは、データパケットのパケットヘッダが正しく送信され、データパケット内のデータに送信エラーが発生し、データがユーザプレーンデータを含む又はデータの全てがユーザプレーンデータであることを意味する。この場合、送信されたユーザプレーンデータには多少のエラーが発生するが、パケットヘッダが正しく送信されているため、ユーザプレーンデータを正しく処理することができる。加えて、ユーザプレーンデータのエラーは、ユーザ体験にわずかに影響を及ぼす可能性があり、実際には他のより深刻な影響を引き起こさない。したがって、第2のデバイスは、データパケットを廃棄しなくてもよい。このようにすると、データ送信効率を向上させ、システム容量を増大させることができる。任意選択的に、第2のCRCがデータ内に位置される場合、第2のデバイスは、第2のCRCを削除した後でデータパケット内のデータを取得し得る。例えば、図3bを参照されたい。第2のCRCを削除した後、第2のデバイスは、data＿1及びdata＿2に基づいてデータパケット内のデータを取得し得る。任意選択的に、データを取得するために第2のCRCを削除した後、第2のデバイスは、データに対して次の処理を実行する、又は後続の処理のためにデータを次のレベルのデータ処理モジュールに送信することができる。

【0081】

データパケットのタイプが制御プレーンデータである場合、それは、データパケットのパケットヘッダが正しく送信され、データパケット内のデータに送信エラーが発生し、データが制御プレーンデータであることを意味する。この場合、パケットヘッダは正しく送信されるが、送信された制御プレーンデータにはエラーが発生する。制御プレーンデータのエラーによって引き起こされる結果は比較的深刻であるため、第2のデバイスはデータパケットを廃棄する。

【0082】

ケース2．2：データパケットのチェックが失敗し、データパケットのパケットヘッダのチェックが失敗する場合、それは、データパケットに送信エラーが発生することを示し、エラーが発生する位置は少なくともパケットヘッダを含み、すなわち、パケットヘッダに送信エラーが発生する。この場合、第2のデバイスはデータパケットを廃棄することができる。

【0083】

パケットヘッダは、送信元アドレス、送信先アドレス、送信元ポート番号、送信先ポート番号、プロトコル情報などのうちの1つ以上を含むため、パケットヘッダは、第2のデバイスによってデータパケットをどのように正しく処理するかにおいて重大な影響を及ぼす。したがって、パケットヘッダのチェックが失敗する場合、データパケットは廃棄される。

【0084】

実施形態2：第2のデバイスは、データパケットのチェック結果を取得するためにステップ203を最初に実行する。データパケットのチェック結果がデータパケットのチェックが成功することである場合、データパケットは廃棄されない。詳細については、前述の実施態様1のケース1の説明を参照されたく、ステップ204及びステップ205は後で実行されない。データパケットのチェック結果がデータパケットのチェックが失敗することである場合、パケットヘッダのチェック結果を取得するためにステップ204が再度実行され、パケットヘッダのチェック結果に基づいてデータパケットが処理される。パケットヘッダのチェック結果に基づいてデータパケットを処理することは2つのケースを含み、それらのケースは、前述の実施態様1のケース2．1及びケース2．2としてそれぞれ説明される。

【0085】

実施態様2に基づいて、データパケットのチェックが成功する場合、パケットヘッダはそれ以上チェックされない。したがって、チェック回数を減らすことができ、それにより、チェック効率を向上させることができる。

【0086】

実施態様2に基づいて、任意選択的に、データパケットのチェックが失敗する場合、データパケットがマークされてもよい。言い換えれば、データパケットのチェックが失敗する場合、データパケットは廃棄されない。代わりに、データパケットはマークされる。例えば、データパケットは、データパケットが更に決定される必要があるデータパケットであることを示すために、特殊文字又は特定のビットを使用してマークされてもよい。続いて、データパケットのパケットヘッダが再び第2のCRCを用いてチェックされ、パケットヘッダのチェック結果に基づいて、データパケットを廃棄するか又はデータパケットを廃棄しないかどうかが決定される。

【0087】

一実施態様では、前述の実施態様のいずれか1つにおいて、第2のデバイスが受信したデータパケットを廃棄する場合、データパケットを廃棄した後に、第2のデバイスは、データパケットが正しく受信されるようにしてユーザ体験を向上させるために、データパケットを再送するように第1のデバイスに更に通知することができる。

【0088】

前述の解決策によれば、第2のデバイスは、データパケット内に、データパケットをチェックするために使用される第1のCRCと、データパケットのパケットヘッダをチェックするために使用される第2のCRCとを含む。データパケットのチェックが失敗するが、パケットヘッダのチェックが成功する場合、それは、パケットヘッダが正しく送信されるが、データが誤って送信されることを示す。この場合、第2のデバイスは、データパケットを直接廃棄する代わりに、データパケットのタイプに基づいてデータパケットを処理することができる。このようにして、パケット損失の量を低減することができ、それにより、データ送信効率が向上され、システム容量が増大する。

【0089】

この出願のこの実施形態で提供される前述の解決策は、様々なシナリオに適用され得る。これは、この出願で限定されない。以下では、特定の適用シナリオを参照して説明する。

【0090】

以下の例では、第1のデバイスと第2のデバイスとの間のインタフェースがeCPRIであることが説明のための例として使用される。この例では、第1のデバイスによって第2のデバイスへ送信されるデータパケットはeCPRIデータパケットと称され、データパケット内のデータはeCPRIデータと称され得る。

【0091】

現在、従来のCPRIでは、送信されるデータは、実際にはエアインタフェースデータのデジタルサンプリング信号である。幾つかのビットエラーは、サンプリングされたデータの数値精度にのみ影響し、他のサンプルには影響しない。このため、CPRIリンクは、光ファイバのビットエラーに対する耐性が高い。ワイヤレスフロントホールがCPRIからeCPRIに切り替えられた後、フロントホールリンクにビットエラーがあり、現在の処理メカニズムによれば、1つのビットエラーが1つのデータパケットのCRCチェック失敗を引き起こす。したがって、データパケットは廃棄される。しかしながら、1つのデータパケットを廃棄すると、全てのデータパケットを受信できるわけではないため、サービスパケット全体が廃棄される。そのため、ビットエラーによるデータロスが大きく拡大してしまう。その結果、ワイヤレスフロントホールがCPRIからeCPRIに切り替えられた後、サービス性能が比較的低下し、これはユーザ体験に影響を及ぼす。

【0092】

図4aは、既存のeCPRIベースのサービスパケットのフォーマットの概略図である。1つのサービスパケットは1つ以上のデータパケットを含み、各データパケットは媒体アクセス制御（medium access control，MAC）ヘッダ、MACデータ、及びCRCを含む。

【0093】

MACヘッダは、送信元MACアドレス及び送信先MACアドレス等の情報を含む。

【0094】

MACデータは、eCPRIタイプ及びeCPRIデータを含む。eCPRIデータは、送信されるべきユーザプレーンデータ又は制御プレーンデータを含む。

【0095】

CRCは、MACヘッダ及びMACデータの正確さをチェックするために用いられる。受信側によって実行されたCRCのチェックが成功する場合、それは、MACヘッダとMACデータの両方が正しく送信されることを示し、エラービットはない。CRCのチェックが失敗する場合、それは、MACヘッダ及びMACデータに誤ったビットがあることを示す。

【0096】

図4aは一例として使用される。データパケット3内のビット又は幾つかのビットに送信エラーが発生すると仮定すると、受信側によって実行されるサービスデータパケット3のCRCチェックが失敗する。この場合、受信側は、現在の処理メカニズムに従ってデータパケット3を廃棄する。加えて、受信側はデータパケット3を正しく受信することができないため、サービスパケット全体も廃棄される。これは、全てのデータパケットを受信することができないからである。これは、受信側がデータパケット3以外のn－1個のデータパケットを正しく受信したとしても、受信側はn－1個のデータパケットを廃棄することを意味する。その結果、サービス性能が相対的に低下し、ユーザ体験が影響を受ける。

【0097】

既存のeCPRIデータパケットは、図2に示される方法を参照して以下で改良される。具体的には、第1のデバイスによって生成されるeCPRIデータパケットは、第1のCRCと第2のCRCとの2つのCRCを含む。次いで、第1のデバイスはeCPRIデータパケットを第2のデバイスに送信する。第2のデバイスは、eCPRIデータパケット内の第1のCRC及び第2のCRCに基づいて、eCPRIデータパケットを処理するための態様を決定することができる。

【0098】

eCPRIデータパケットの送信及び処理プロセスは以下のステップを含む。

【0099】

ステップ1：第1のデバイスはデータパケットaを取得し、データパケットaは、MACヘッダと、eCPRIタイプと、eCPRIデータとを含む。

【0100】

ここでのMACヘッダは、図2の実施の形態におけるパケットヘッダの具体例である。

【0101】

ここでのeCPRIタイプとeCPRIデータとの組み合わせは、図2の実施形態におけるデータの具体例である。

【0102】

ステップ2：第1のデバイスは、データパケットbを取得するために、データパケットaにCRC1を挿入する。

【0103】

ここでのCRC1は、図2の実施形態における第2のCRCの具体例である。

【0104】

図4bは、サービスデータパケットにCRCを挿入する概略図である。この例では、CRC1が第1の位置に挿入される。CRC1が挿入された後、eCPRIデータは、eCPRI data＿1とeCPRI data＿2とに分割される。CRC1は、MACヘッダと、eCPRIタイプと、eCPRI data＿1とに基づいて生成される。ここでのeCPRIタイプとeCPRI data＿1との組み合わせは、図2の実施形態におけるdata＿1の具体例である。

【0105】

ステップ3：第1のデバイスは、データパケットcを取得するために、データパケットbの末尾にCRC2を挿入する。

【0106】

ここでのCRC2ヘッダは、図2の実施形態における第1のCRCの具体例である。

【0107】

CRC2は、MACヘッダ、eCPRIタイプ、CRC1、eCPRIdata＿1、及びeCPRI data＿2に基づいて生成される。

【0108】

ステップ4：第1のデバイスは、データパケットcを第2のデバイスに送信する。

【0109】

ここでのデータパケットcは、図2の実施形態において第1のデバイスによって第2のデバイスに送信されるデータパケットの具体例である。

【0110】

ステップ5：第2のデバイスは、データパケットc内のCRC2をチェックし、任意選択的に、CRC1を更にチェックする。これは以下のケース1とケース2とに分けられる。

【0111】

ケース1：CRC2のチェックが成功する場合、それは、MACヘッダ、eCPRIタイプ、及びeCPRIデータが全て正しく送信されることを示す。この場合、第2のデバイスはデータパケットcを廃棄しない。任意選択的に、第2のデバイスは、eCPRIデータを取得するためにCRC1を更に削除し、eCPRIデータを記憶する。

【0112】

ケース2：CRC2のチェックが失敗する場合、CRC1が更にチェックされる。これは、以下のケース2．1とケース2．2とに分けられる。

【0113】

ケース2．1：CRC1のチェックが失敗する場合、データパケットcは廃棄される。

【0114】

ケース2．2：CRC1のチェックが成功する場合、以下のケース2．2．1とケース2．2．2とが分割され得る。

【0115】

ケース2．2．1：eCPRIデータのタイプがユーザプレーンデータである場合、データパケットcは廃棄されない。任意選択的に、第2のデバイスは、eCPRIデータを取得するためにCRC1を更に削除する。

【0116】

ケース2．2．2：eCPRIデータのタイプが制御プレーンデータである場合、データパケットcは廃棄される。

【0117】

第2のデバイスは、MACヘッダ及び／又はeCPRIタイプに基づいてeCPRIデータのタイプを決定し得る。

【0118】

前述の方法によれば、eCPRIデータパケットの送信及び処理が実施され、その結果、データ送信効率を向上させることができ、システム容量を増大させることができ、それによってユーザ体験を改善するのに役立つ。

【0119】

例えば、以下は、第1のデバイス及び第2のデバイスの実施態様を提供する。図5は、この出願の一実施形態に係る第1のデバイス及び第2のデバイスの構造の概略図である。以下では、図5に示される第1のデバイス及び第2のデバイスが前述のeCPRIデータパケットの送信及び処理プロセスに適用される例を用いて説明する。

【0120】

第1のデバイスは、ベースバンド処理ユニットと、ヘッダチェック符号化ユニットと、イーサネットMAC層パケット送信ユニットとを含む。

【0121】

（1）ベースバンド処理ユニットはデータパケットaを生成し、データパケットaは、MACヘッダと、eCPRIタイプと、eCPRIデータとを含む。

【0122】

（2）ヘッダチェック処理ユニットは、MACヘッダ、eCPRIタイプ、及びeCPRI data＿1に基づいてCRC1を生成するとともに、CRC1を第1の位置に挿入してデータパケットbを取得する。

【0123】

（3）イーサネットMAC層パケット送信ユニットは、MACヘッダ、eCPRIタイプ、CRC1、及びeCPRIデータに基づいてCRC2を生成し、CRC2をデータパケットbの末尾に付加してデータパケットcを取得するとともに、データパケットcを、第1のデバイスと第2のデバイスとの間のeCPRIインタフェースを介して第2のデバイスへ送信する。

【0124】

第2のデバイスは、イーサネットMAC層パケット受信ユニットと、ヘッダチェック復号ユニットと、ベースバンド処理ユニットとを含む。

【0125】

（1）イーサネットMAC層パケット受信ユニットは、データパケットcを受信し、データパケットc内のCRC2をチェックする。CRC2のチェックが成功する場合、イーサネットMAC層パケット受信ユニットは、データパケットc内のCRC2を削除してデータパケットbを取得し、マーク情報1を生成する。マーク情報1は、データパケットのチェックが成功することを示す。その後、イーサネットMAC層パケット受信ユニットは、データパケットb及びマーク情報1をヘッダチェックユニットに送る。CRC2のチェックが失敗する場合、イーサネットMAC層パケット受信ユニットは、CRC2を削除してデータパケットbを取得し、マーク情報2を生成する。マーク情報2は、データパケットのチェックが失敗することを示す。その後、イーサネットMAC層パケット受信ユニットは、データパケットb及びマーク情報2をヘッダチェックユニットに送る。

【0126】

（2）ヘッダチェック処理ユニットは、データパケットbを受信するとともに、マーク情報1又はマーク情報2を受信する。ヘッダチェック処理ユニットは、データパケットb及びマーク情報1を受信する場合、CRC1を除去してデータパケットaとし、マーク情報3を生成する。マーク情報3は、データパケットのチェックが成功することを示す。その後、ヘッダチェック処理ユニットは、データパケットa及びマーク情報3をベースバンド処理ユニットに送る。ヘッダチェック処理ユニットは、データパケットb及びマーク情報2を受信する場合、データパケットbにおけるCRC1をチェックする。CRC1のチェックが成功し、データパケットbのタイプがユーザプレーンデータである場合、ヘッダチェック処理ユニットは、CRC1を削除してデータパケットaを取得し、マーク情報3を生成する。マーク情報3は、データパケットのチェックが成功することを示す。その後、ヘッダチェック処理ユニットは、データパケットa及びマーク情報3をベースバンド処理ユニットに送る。CRC1のチェックが成功し、データパケットbのタイプが制御プレーンデータである、又はCRC1のチェックが失敗する場合、ヘッダチェック処理ユニットは、CRC1を削除してデータパケットaを取得し、マーク情報4を生成する。マーク情報4は、データパケットのチェックが失敗することを示す。その後、ヘッダチェック処理ユニットは、データパケットa及びマーク情報4をベースバンド処理ユニットに送る。

【0127】

（3）ベースバンド処理ユニットは、データパケットaを受信するとともに、マーク情報3又はマーク情報4を受信する。ベースバンド処理ユニットは、データパケットa及びマーク情報3を受信する場合、データパケットaを廃棄しない。例えば、ベースバンド処理ユニットは、データパケットaを処理し、又はデータパケットaを処理のために次のレベルのデータ処理モデルに送信することができる。ベースバンド処理ユニットは、データパケットa及びマーク情報4を受信する場合、データパケットaを破棄する。

【0128】

前述の実施態様では、マーク情報1、マーク情報2、マーク情報3、及びマーク情報4は、同時に存在しなくてもよい。上記で提供された実施態様において、第2のデバイスのイーサネットMAC層パケット受信ユニットは、マーク情報1を使用することにより、データパケットのチェックが成功することをヘッダチェックユニットに通知するとともに、マーク情報2を使用することにより、データパケットのチェックが失敗することをヘッダチェックユニットに通知する。他の実施態様では、データパケットcのチェックが成功すると決定すると、イーサネットMAC層パケット受信ユニットは、データパケットb及び1つのマーク情報をヘッダチェックユニットに送る。データパケットcのチェックが失敗すると決定すると、イーサネットMAC層パケット受信ユニットは、データパケットbをヘッダチェックユニットに送る。したがって、ヘッダチェックユニットは、データパケットb及び1つのマーク情報を受信すると、データパケットbのチェックが成功する、すなわち、データパケットbに送信エラーが発生しないと決定する。ヘッダチェックユニットは、データパケットbを受信すると、データパケットbのチェックが失敗する、すなわち、データパケットbに送信エラーが発生すると決定する。或いは、データパケットcのチェックが成功すると決定する場合、イーサネットMAC層パケット受信ユニットは、データパケットbをヘッダチェックユニットに送る。イーサネットMAC層パケット受信ユニットは、データパケットcのチェックが失敗すると決定すると、データパケットb及び1つのマーク情報をヘッダチェックユニットに送る。

【0129】

一実施態様において、ヘッダチェックユニット及びベースバンド処理ユニットは、代替として、以下の処理態様でデータパケットを処理することができる。ヘッダチェックユニットは、データパケットbを受信するとともに、マーク情報1又はマーク情報2を受信する。ヘッダチェック処理ユニットは、データパケットbとマーク情報1とを受信する場合、データパケットbにおけるCRC1を削除してデータパケットaを取得し、データパケットaをベースバンド処理ユニットに送る。ヘッダチェック処理ユニットは、データパケットb及びマーク情報2を受信する場合、データパケットbにおけるCRC1をチェックする。CRC1のチェックが成功し、データパケットbのタイプがユーザプレーンデータである場合、ヘッダチェック処理ユニットは、CRC1を削除して、データパケットaを取得するとともに、データパケットaをベースバンド処理ユニットに送信する。CRC1のチェックが成功し、データパケットbのタイプが制御プレーンデータである、又はCRC1のチェックが失敗する場合、ヘッダチェック処理ユニットは、データパケットbを破棄する。これに対応して、ベースバンド処理ユニットはデータパケットaを受信し、ベースバンド処理ユニットはデータパケットaを廃棄しない。例えば、ベースバンド処理ユニットは、データパケットaを処理し、又はデータパケットaを処理のために次のレベルのデータ処理モデルに送信することができる。

【0130】

前述の機能ユニットの分割及び名称は単なる例であり、前述の例で同じユニットに実装された機能は、代替的に異なる機能モジュール又は機能ユニットによって実装されてもよいことが理解され得る。同様に、前述の例の異なるユニットで実施される機能は、代替的に、要件に従って同じ機能モジュール又はユニットによって実施されてもよい。これは、この出願で限定されない。

【0131】

前述の解決策によれば、ユーザプレーンデータを搬送してエラービットを有するほとんどのデータパケットを取り出すことができ、フロントホールリンクのビットエラー状態におけるシステム性能を向上させることができる。

【0132】

前述の実施形態の機能を実装するために、第1のデバイス又は第2のデバイスは、各機能を実行するための対応するハードウェア構造及び／又は対応するソフトウェアモジュールを含むことが理解され得る。当業者であれば容易に認識できるように、この出願に開示された実施形態に記載された例のユニット及び方法ステップに基づいて、この出願がハードウェア又はハードウェアとコンピュータソフトウェアとの組み合わせによって実施され得る。機能がハードウェアによって実行されるか、コンピュータソフトウェアによって駆動されるハードウェアによって実行されるかどうかは、特定の適用シナリオ及び技術的解決策の設計制約に依存する。

【0133】

図6及び図7は、この出願の実施形態に係る想定し得る通信装置の構造の概略図である。通信装置600は、前述の方法の実施形態における第1のデバイス又は第2のデバイスの機能を実装するように構成されてもよい。したがって、通信装置は、前述の方法の実施形態の有益な効果を実現することもできる。この出願の実施形態において、通信装置は、第1のデバイスもしくは第2のデバイスであってもよく、又は第1のデバイスもしくは第2のデバイスで使用されるモジュール（例えば、チップ）であってもよい。図6に示されるように、通信装置600、処理ユニット610と、トランシーバユニット620とを含む。通信装置600は、前述の方法の実施形態における第1のデバイス又は第2のデバイスの機能を実装するように構成される。例えば、通信装置600が図5の第1のデバイスの機能を実装するように構成される場合、処理ユニット610は第1のデバイスのベースバンド処理ユニットとヘッダチェック処理ユニットの機能を実装するように構成されてもよく、トランシーバユニット620は第1のデバイスのイーサネットMAC層パケット送信ユニットの機能を実装するように構成されてもよい。通信装置600が図5の第2のデバイスの機能を実装するように構成される場合、処理ユニット610は、第2のデバイスのベースバンド処理ユニット及びヘッダチェック処理ユニットの機能を実装するように構成されてもよく、トランシーバユニット620は、第2のデバイスのイーサネットMAC層パケット受信ユニットの機能を実装するように構成されてもよい。

【0134】

第1の実施形態では、通信装置は、図2に示す方法の実施形態における第2のデバイスの動作を実施するように構成される。トランシーバユニット620は、第1のデバイスからデータパケットを受信するように構成され、データパケットは、パケットヘッダ、データ、第1のCRC、及び第2のCRCを含む。処理ユニット610は、データパケット内の第1のCRCに基づいてデータパケットをチェックし、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックし、データパケットのチェック結果及び／又はパケットヘッダのチェック結果に基づいてデータパケットを処理するように構成される。

【0135】

想定し得る実施態様において、処理ユニット610は、データパケットのチェックが成功する場合、又はデータパケットのチェックが成功し、パケットヘッダのチェックが成功する場合、データパケットの廃棄をスキップし、データパケットのチェックが失敗し、パケットヘッダのチェックが失敗する場合、データパケットを廃棄し、又は、データパケットのチェックが失敗するが、パケットヘッダのチェックが成功する場合、データパケットのタイプに基づいてデータパケットを処理するように特に構成される。

【0136】

想定し得る実施態様において、処理ユニット610は、データパケットのチェックが失敗する場合、データパケット内の第2のCRCに基づいてデータパケットのパケットヘッダをチェックするように特に構成される。

【0137】

想定し得る実施態様において、処理ユニット610は、データパケットのチェックが失敗する場合にデータパケットをマークするように特に構成される。

【0138】

想定し得る実施態様において、処理ユニット610は、データパケットのタイプがユーザプレーンデータである場合、データパケットを廃棄することをスキップし、データパケットのタイプが制御プレーンデータである場合、データパケットを廃棄するように特に構成される。

【0139】

想定し得る実施態様において、処理ユニット610は、パケットヘッダに基づいてデータパケットのタイプを決定するように更に構成される。

【0140】

想定し得る実施態様において、処理ユニット610は、データパケットから第2のCRCを削除するように更に構成される。

【0141】

想定し得る実施態様では、第1のCRCがデータパケットの末尾に位置され、第2のCRCがデータパケットのパケットヘッダの後に位置される。

【0142】

想定し得る実施態様において、第1のCRCは、データパケットのパケットヘッダ及びデータパケット内のデータに基づいて生成される。

【0143】

想定し得る実施態様において、第1のCRCは、データパケットのパケットヘッダ、データパケット内のデータ、及び第2のCRCに基づいて生成される。

【0144】

想定し得る実施態様において、第2のCRCは、データパケットのパケットヘッダに基づいて生成される。

【0145】

想定し得る実施態様において、第2のCRCは、データパケットのパケットヘッダとデータパケット内のデータの一部とに基づいて生成される。

【0146】

1つの想定し得る実施態様では、データパケットがeCPRIデータパケットであり、データパケット内のデータがeCPRIデータを含む。

【0147】

第2の実施形態において、通信装置は、図2に示される方法の実施形態における第1のデバイスの動作を実施するように構成される。処理ユニット610はデータパケットを生成するように構成され、データパケットはパケットヘッダ、データ、第1のCRC、及び第2のCRCを含み、第1のCRCはデータパケットをチェックするために使用され、第2のCRCはパケットヘッダをチェックするために使用される。トランシーバユニット620は、データパケットを第2のデバイスに送信するように構成される。

【0148】

想定し得る実施態様において、処理ユニット610は、パケットヘッダに基づいて第2のCRCを生成するように更に構成される。

【0149】

想定し得る実施態様において、処理ユニット610は、パケットヘッダ及びデータの一部に基づいて第2のCRCを生成するように特に構成される。

【0150】

想定し得る実施態様において、処理ユニット610は、パケットヘッダ、データ、及び第2のCRCに基づいて第1のCRCを生成するように更に構成される。

【0151】

想定し得る実施態様では、第1のCRCがデータパケットの末尾に位置され、第2のCRCがデータパケットのパケットヘッダの後に位置される。

【0152】

1つの想定し得る実施態様では、データパケットがeCPRIデータパケットであり、データパケット内のデータがeCPRIデータを含む。

【0153】

【0154】

処理ユニット610及びトランシーバユニット620に関する詳細については、前述の方法実施形態の関連説明を直接参照されたい。ここでは詳細を繰り返さない。

【0155】

図7に示されるように、通信装置700は、少なくとも1つのプロセッサ710を含み、インタフェース回路720を更に含み得る。プロセッサ710及びインタフェース回路720は、互いに結合されてもよい。インタフェース回路720は、トランシーバ又は入力／出力インタフェースであってもよいことが理解され得る。任意選択的に、通信装置700は、プロセッサ710によって実行される命令を記憶し、命令を実行するためにプロセッサ710によって必要とされる入力データを記憶し、又はプロセッサ710が命令を実行した後に生成されたデータを記憶するように構成されるメモリ730を更に含んでもよい。

【0156】

通信装置700が前述の方法の実施形態を実施するように構成される場合、プロセッサ710は、前述の処理ユニット610の機能を実装するように構成され、インタフェース回路720は、前述のトランシーバユニット620の機能を実装するように構成され得る。

【0157】

この出願の実施形態におけるプロセッサは、中央処理ユニット（central processing unit、CPU）であってもよく、又は別の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor、DSP）、特定用途向け集積回路（application specific integrated circuit、ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）もしくは別のプログラマブルロジックデバイス、トランジスタ論理デバイス、ハードウェア構成要素、もしくはそれらの任意の組み合わせであってもよいことが理解され得る。汎用プロセッサは、マイクロプロセッサ又は任意の従来のプロセッサであってもよい。

【0158】

この出願の実施形態における方法ステップは、ハードウェア態様で実施されてもよく、又はプロセッサによってソフトウェア命令を実行する態様で実施されてもよい。ソフトウェア命令は、対応するソフトウェアモジュールを含んでもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、消去可能プログラマブル読み出し専用メモリ、電気的消去可能プログラマブル読み出し専用メモリ、レジスタ、ハードディスク、リムーバブルハードディスク、CD－ROM、又は当技術分野でよく知られている任意の他の形態の記憶媒体に記憶され得る。例えば、記憶媒体は、プロセッサが記憶媒体から情報を読み出すことができ、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。もちろん、記憶媒体は、代替的にプロセッサの構成要素であってもよい。プロセッサ及び記憶媒体はASIC内に配置されてもよい。加えて、ASICは、基地局又は端末に配置されてもよい。確かに、プロセッサ及び記憶媒体は、代替として、個別の構成要素として基地局又は端末に存在してもよい。

【0159】

前述の実施形態の全部又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はこれらの任意の組み合わせによって実装されてもよい。ソフトウェアが前述の実施形態を実施するために使用されるとき、前述の実施形態の全部又は一部は、コンピュータプログラム製品の形態で実現されてもよい。コンピュータプログラム製品は、1つ以上のコンピュータプログラム又は命令を含む。コンピュータプログラム又は命令がコンピュータにロードされて実行されると、この出願の実施形態における手順又は機能の全部又は一部が実行される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、基地局、ユーザ機器、又は他のプログラム可能な装置であってもよい。コンピュータプログラム又は命令は、コンピュータ可読記憶媒体に記憶されてもよく、又はコンピュータ可読記憶媒体から他のコンピュータ可読記憶媒体に送信されてもよい。例えば、コンピュータプログラム又は命令は、ウェブサイト、コンピュータ、サーバ、又はデータセンタから他のウェブサイト、コンピュータ、サーバ、又はデータセンタに有線又は無線の態様で送信されてもよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体、又は1つ以上の使用可能な媒体を組み込むサーバ又はデータセンタなどのデータ記憶デバイスであってもよい。使用可能な媒体は、磁気媒体、例えば、フロッピーディスク、ハードディスク、又は磁気テープであってもよく、光媒体、例えばデジタルビデオディスクであってもよく、又は半導体媒体、例えばソリッドステートドライブであってもよい。コンピュータ可読記憶媒体は、揮発性又は不揮発性記憶媒体であってもよく、又は揮発性及び不揮発性記憶媒体の両方のタイプを含んでもよい。

【0160】

この出願の様々な実施形態では、特に明記しない限り、又は論理的な矛盾がない限り、異なる実施形態間の用語及び／又は説明は、一貫しており、相互に参照することができ、また、異なる実施形態の技術的特徴は、その内部論理的関係に基づいて組み合わされて、新しい実施形態を形成することができる。

【0161】

この出願では、「少なくとも1つの」は1つ以上を意味し、「複数の」は2つ以上を意味する。「及び／又は」という用語は、関連付けられた対象間の、関連付けの関係を記述し、3つの関係が存在し得ることを表す。例えば、A及び／又はBは、以下のケース：Aのみが存在する、AとBの両方が存在する、及びBのみが存在する、を表す場合があり、A及びBは、単数でも複数でもよい。この出願のテキスト記述において、文字「／」は、一般に、関連するオブジェクト間の「又は」関係を表す。この出願の式において、文字「／」は、関連するオブジェクト間の「分割」関係を表す。

【0162】

この出願の実施形態における様々な数字は、説明を容易にするための区別に使用されているにすぎず、この出願の実施形態の範囲を限定するためには使用されていないことが理解され得る。上記のプロセスの順序番号は実行順序を意味するものではなく、プロセスの実行順序は、プロセスの関数及び内部ロジックに基づいて決定されるべきである。

【符号の説明】

【0163】

600 通信装置
610 処理ユニット
620 トランシーバユニット
700 通信装置
710 プロセッサ
720 インタフェース回路
730 メモリ

【図1】