(57)【要約】  本出願の実施例は、データ複製をサポートする方法、送信側デバイスおよび受信側デバイスを提供し、車両インターネットシステムにおける複製データの確実な伝送を実現することができる。当該方法は、送信側デバイスが、受信側デバイスに複数の無線リンク制御（ＲＬＣ：Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）プロトコルデータユニット（ＰＤＵ：Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  ｕｎｉｔ）を送信することであって、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことを含む。
2020529148.tif 000002
【特許請求の範囲】
【請求項１】
データ複製をサポートする方法であって、
送信側デバイスが、受信側デバイスに複数の無線リンク制御プロトコルデータユニット（ＲＬＣ  ＰＤＵ：Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  ｕｎｉｔ）を送信することであって、前記複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダ（ｈｅａｄｅｒ）には、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことを含む、前記方法。
【請求項２】
前記指示フィールドには、現在のＲＬＣ  ＰＤＵに対応するパケットデータ収束プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）に対応する無線ベアラの識別子（ＩＤ）を含む、
請求項１に記載の方法。
【請求項３】
前記指示フィールドは、論理チャネルの識別子（ＩＤ）を含む、
請求項１に記載の方法。
【請求項４】
前記指示フィールドは、予約ビットをさらに含む、
請求項３に記載の方法。
【請求項５】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダである、
請求項１ないし４のいずれか一項に記載の方法。
【請求項６】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである、
請求項１ないし４のいずれか一項に記載の方法。
【請求項７】
前記ＲＬＣヘッダは、メディアアクセス制御（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）を形成することに使用される、
請求項５に記載の方法。
【請求項８】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは、異なる論理チャネルに対応し、および前記少なくとも２つのＲＬＣ  ＰＤＵは、同じ無線ベアラに対応する、
請求項１ないし４のいずれか一項に記載の方法。
【請求項９】
前記方法は、車両インターネット（ＩＯＶ）システムに適用される、
請求項１ないし８のいずれか一項に記載の方法
【請求項１０】
データ複製をサポートする方法であって、
受信側デバイスは、送信側デバイスによって送信される複数のＲＬＣ  ＰＤＵを受信することと、
前記受信側デバイスは、論理チャネルと無線ベアラとの間の対応関係にしたがって、前記複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することとを含む、前記方法。
【請求項１１】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを含む指示フィールドを含み、
前記論理チャネルと無線ベアラとの間の対応関係にしたがって、前記複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することの前に、前記方法は、
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、前記論理チャネルと前記無線ベアラとの間の対応関係を決定することをさらに含む、
請求項１０に記載の方法。
【請求項１２】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、論理チャネルの識別子（ＩＤ）を含む指示フィールドを含み、
前記論理チャネルと無線ベアラとの間の対応関係にしたがって、前記複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することの前に、前記方法は、
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、前記論理チャネルと前記無線ベアラとの間の対応関係を決定することをさらに含む、
請求項１０に記載の方法。
【請求項１３】
前記指示フィールドは、予約ビットをさらに含む、
請求項１２に記載の方法。
【請求項１４】
前記論理チャネルと前記無線ベアラとの間の対応関係は事前に構成されたものである、
請求項１０に記載の方法。
【請求項１５】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは異なる論理チャネルに対応し、および前記少なくとも２つのＲＬＣ  ＰＤＵは同じ無線ベアラに対応する、
請求項１０ないし１４のいずれか一項に記載の方法。
【請求項１６】
前記方法は、車両インターネット（ＩＯＶ）システムに適用される、
請求項１０ないし１４のいずれか一項に記載の方法。
【請求項１７】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダである、
請求項１０ないし１４のいずれか一項に記載の方法。
【請求項１８】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである、
請求項１０ないし１４のいずれか一項に記載の方法。
【請求項１９】
前記ＲＬＣヘッダは、メディアアクセス制御（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）サブヘッダを形成することに使用される、
請求項１８に記載の方法。
【請求項２０】
送信側デバイスであって、
受信側デバイスに複数のＲＬＣ  ＰＤＵを送信する送信ユニットであって、前記複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことに使用される送信ユニットを含む、前記送信側デバイス。
【請求項２１】
前記指示フィールドは、現在のＲＬＣ  ＰＤＵに対応するＰＤＣＰに対応する無線ベアラの識別子（ＩＤ）を含む、
請求項２０に記載の送信側デバイス。
【請求項２２】
前記指示フィールドは、論理チャネルの識別子（ＩＤ）を含む、
請求項２０に記載の送信側デバイス。
【請求項２３】
前記指示フィールドは、予約ビットをさらに含む、
請求項２２に記載の送信側デバイス。
【請求項２４】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダである、
請求項２０ないし２３のいずれか一項に記載の送信側デバイス。
【請求項２５】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである、
請求項２０ないし２３のいずれか一項に記載の送信側デバイス。
【請求項２６】
前記ＲＬＣヘッダは、メディアアクセス制御（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）サブヘッダを形成することに使用される、
請求項２４に記載の送信側デバイス。
【請求項２７】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは異なる論理チャネルに対応し、および前記少なくとも２つのＲＬＣ  ＰＤＵは同じ無線ベアラに対応する、
請求項２０ないし２３のいずれか一項に記載の送信側デバイス。
【請求項２８】
前記送信側デバイスは、車両インターネット（ＩＯＶ）システムに適用される、
請求項２０ないし２７のいずれか一項に記載の送信側デバイス。
【請求項２９】
受信側デバイスであって、
送信側デバイスによって送信される複数のＲＬＣ  ＰＤＵを受信する受信ユニットと、
論理チャネルと無線ベアラとの間の対応関係にしたがって、前記複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する処理ユニットとを含む、前記受信側デバイス。
【請求項３０】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを含む指示フィールドを含み、
前記処理ユニットが、論理チャネルと無線ベアラとの間の対応関係にしたがって、前記複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、前記処理ユニットは、さらに前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、前記論理チャネルと前記無線ベアラとの間の対応関係を決定することに使用される、
請求項２９に記載の受信側デバイス。
【請求項３１】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、論理チャネルの識別子（ＩＤ）を含む指示フィールドを含み、
前記処理ユニットが、論理チャネルと無線ベアラとの間の対応関係にしたがって、前記複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、前記処理ユニットは、さらに前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、前記論理チャネルと前記無線ベアラとの間の対応関係を決定することに使用される、
請求項２９に記載の受信側デバイス。
【請求項３２】
前記指示フィールドは、予約ビットをさらに含む、
請求項３１に記載の受信側デバイス。
【請求項３３】
前記論理チャネルと前記無線ベアラとの間の対応関係は事前に構成されたものである、
請求項２９に記載の受信側デバイス。
【請求項３４】
前記複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは異なる論理チャネルに対応し、および前記少なくとも２つのＲＬＣ  ＰＤＵは同じ無線ベアラに対応する、
請求項２９ないし３３のいずれか一項に記載の受信側デバイス。
【請求項３５】
前記受信側デバイスは、車両インターネット（ＩＯＶ）システムに適用される、
請求項２９ないし３３のいずれか一項に記載の受信側デバイス。
【請求項３６】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダである、
請求項２９ないし３２のいずれか一項に記載の受信側デバイス。
【請求項３７】
前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである、
請求項２９ないし３２のいずれか一項に記載の受信側デバイス。
【請求項３８】
前記ＲＬＣヘッダは、メディアアクセス制御（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）サブヘッダを形成することに使用される、
請求項３６に記載の受信側デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、通信分野に関し、より具体的には、データ複製をサポートする方法、送信側デバイスおよび受信側デバイスに関する。
【背景技術】
【０００２】
車両インターネット（ＩＯＶ：Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｖｅｈｉｃｌｅｓ）またはビークルツーエブリシング（Ｖ２Ｘ：Ｖｅｈｉｃｌｅ  ｔｏ  Ｅｖｅｒｙｔｈｉｎｇ）と呼ばれる通信システムは、デバイスからデバイス（Ｄ２Ｄ：Ｄｅｖｉｃｅ  ｔｏ  Ｄｅｖｉｃｅ）通信に基づくサイドリンク（ＳＬ：ＳｉｄｅＬｉｎｋ）伝送技術であり、基地局を介して通信データを受信または送信する従来のロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムの方式とは異なって、車両インターネットシステムは、端末間直接に通信する方式を使用するため、スペクトル効率が高く、伝送遅延も低い。
【０００３】
車両インターネットシステムにおいて、データ伝送の信頼性に対する要求が高くて、データの伝送を信頼性の高い方法で実現することが解決しようとする課題である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本出願の実施例は、データ複製をサポートする方法、送信側デバイスおよび受信側デバイスを提供し、車両インターネットシステムにおける複製データの確実な伝送を実現することができる。
【課題を解決するための手段】
【０００５】
第１の態様において、本出願の実施例は、
送信側デバイスが、受信側デバイスに複数の無線リンク制御（ＲＬＣ：Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）プロトコルデータユニット（ＰＤＵ：Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  ｕｎｉｔ）を送信することであって、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダ（ｈｅａｄｅｒ）には、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことを含む、データ複製をサポートする方法を提供する。
【０００６】
選択的に、送信側デバイスは、端末装置であってもよい。
【０００７】
選択的に、受信側デバイスは、端末装置であってもよく、ネットワーク装置（例えば、基地局）であってもよい。
【０００８】
したがって、本出願の実施例のデータ複製をサポートする方法において、送信側デバイスが複数のＲＬＣ  ＰＤＵを送信する場合、複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことにより、受信側デバイスが複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することができ、なお、複製データの確実な伝送を実現することができる。
【０００９】
選択的に、第１の態様の実施形態において、当該指示フィールドは、現在のＲＬＣ  ＰＤＵに対応するパケットデータ収束プロトコル（ＰＤＣＰ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）に対応する無線ベアラの識別子（ＩＤ）を含む。
【００１０】
選択的に、第１の態様の実施形態において、当該指示フィールドは、論理チャネルの識別子（ＩＤ）を含む。
【００１１】
選択的に、第１の態様の実施形態において、前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダである。
【００１２】
選択的に、第１の態様の実施形態において、前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである。
【００１３】
選択的に、第１の態様の実施形態において、前記ＲＬＣヘッダは、メディアアクセス制御（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）サブヘッダを形成することに使用される。
【００１４】
選択的に、第１の態様の実施形態において、前記複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは、異なる論理チャネルに対応し、および前記少なくとも２つのＲＬＣ  ＰＤＵは、同じ無線ベアラに対応する。
【００１５】
選択的に、第１の態様の実施形態において、前記方法は、車両インターネット（ＩＯＶ）システムに適用される。
【００１６】
第２の態様において、本出願の実施例は、
受信側デバイスは、送信側デバイスによって送信される複数のＲＬＣ  ＰＤＵを受信することと、
当該受信側デバイスは、論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することとを含む、データ複製をサポートする方法を提供する。
【００１７】
したがって、本出願の実施例のデータ複製をサポートする方法において、受信側デバイスが複数のＲＬＣ  ＰＤＵを受信する場合、論理チャネルと無線ベアラとの間の対応関係にしたがって、複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することができ、なお、複製データの確実な伝送を実現することができる。
【００１８】
選択的に、第２の態様の実施形態において、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを含む指示フィールドを含み、
当該論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、当該方法は、
当該少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、当該論理チャネルと当該無線ベアラとの間の対応関係を決定することをさらに含む。
【００１９】
選択的に、第２の態様の実施形態において、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、論理チャネルの識別子（ＩＤ）を含む指示フィールドを含み、
当該論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、当該方法は、
当該少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、当該論理チャネルと当該無線ベアラとの間の対応関係を決定することをさらに含む。
【００２０】
選択的に、第２の態様の実施形態において、当該論理チャネルと当該無線ベアラとの間の対応関係は事前に構成されたものである。
【００２１】
選択的に、第２の態様の実施形態において、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは、異なる論理チャネルに対応し、および当該少なくとも２つのＲＬＣ  ＰＤＵは、同じ無線ベアラに対応する。
【００２２】
選択的に、第２の態様の実施形態において、当該方法は、車両インターネットシステムに適用される。
【００２３】
選択的に、第２の態様の実施形態において、前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダである。
【００２４】
選択的に、第２の態様の実施形態において、前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである。
【００２５】
選択的に、第２の態様の実施形態において、前記ＲＬＣヘッダは、メディアアクセス制御（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）サブヘッダを形成することに使用される。
【００２６】
第３の態様において、本出願の実施例は、第１の態様または第１の態様におけるいずれかの選択的な実施形態の方法のモジュールまたはユニットを実行することができる送信側デバイスを提供する。
【００２７】
第４の態様において、本出願の実施例は、第２の態様または第２の態様におけるいずれかの選択的な実施形態の方法のモジュールまたはユニットを実行することができる受信側デバイスを提供する。
【００２８】
第５の態様において、プロセッサ、メモリおよび通信インターフェースを含む送信側デバイスを提供する。プロセッサは、メモリおよび通信インターフェースに接続される。メモリは、命令を記憶するために使用され、プロセッサは、当該命令を実行するために使用され、通信インターフェースは、プロセッサの制御下で他のネットワーク要素と通信するために使用される。当該プロセッサが当該メモリに記憶された命令を実行する場合、当該実行により、当該プロセッサが第１の態様または第１の態様のいずれかの可能な実施形態における方法を実行する。
【００２９】
第６の態様において、プロセッサ、メモリおよび通信インターフェースを含む受信側デバイスを提供する。プロセッサは、メモリおよび通信インターフェースに接続される。メモリは、命令を記憶するために使用され、プロセッサは、当該命令を実行するために使用され、通信インターフェースは、プロセッサの制御下で他のネットワーク要素と通信するために使用される。当該プロセッサが当該メモリに記憶された命令を実行する場合、当該実行により、当該プロセッサが第２の態様または第２の態様のいずれかの可能な実施形態における方法を実行する。
【００３０】
第７の態様において、前記第１の態様または第１の態様のいずれかの可能な実施形態の方法の命令をコンピュータに実行するように指示するためのプログラムコードが記憶されるコンピュータ記憶媒体を提供する。
【００３１】
第８の態様において、前記第２の態様または第２の態様のいずれかの可能な実施形態の方法の命令をコンピュータに実行するように指示するためのプログラムコードが記憶されるコンピュータ記憶媒体を提供する。
【００３２】
第９の態様において、命令が含まれるコンピュータプログラム製品を提供し、コンピュータで実行されると、コンピュータに前記各態様に記載の方法を実行させる。
【図面の簡単な説明】
【００３３】
【図１】本出願の実施例の適用シナリオの概略図である。
【図２】本出願の実施例の別の適用シナリオの概略図である。
【図３】本出願の実施例におけるキャリアアグリゲーション（Ｃａｒｒｉｅｒ  ａｇｇｒｅｇａｔｉｏｎ）を介してデータ伝送を行う概略図である。
【図４】本出願の実施例に係るデータ複製をサポートする方法の模式的なフローチャートである。
【図５】本出願の実施例に係る別のデータ複製をサポートする方法の模式的なフローチャートである。
【図６】本出願の実施例に係る送信側デバイスの模式的なブロック図である。
【図７】本出願の実施例に係る受信側デバイスの模式的なブロック図である。
【図８】本出願の実施例によって提供されるデータ複製をサポートする装置の模式的なブロック図である。
【図９】本出願の実施例に係るシステムチップの模式的な構造図である。
【図１０】本出願の実施例における２種類のフレーム構造の概略図である。
【発明を実施するための方式】
【００３４】
以下、本出願の実施例における技術的解決策を本出願の実施例における図面を参照して明確かつ完全に説明する。
【００３５】
本出願の実施例の技術的解決策は、車両インターネットシステムに適用されることができ、車両インターネットシステムは、様々な通信システム、例えば、ＬＴＥ−Ｄ２Ｄの車両インターネットシステムに基づいてもよいことを理解されたい。従来のＬＴＥシステム中の端末間の通信データは、ネットワーク装置（例えば、基地局）を介して送受信する方法とは異なって、車両インターネットシステムは、端末間に直接に通信する方式を使用するため、スペクトル効率が高く、伝送遅延も低い。
【００３６】
選択的に、車両インターネットシステムが基づく通信システムは、可以是グローバル移動通信（ＧＳＭ：Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｏｆ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）システム、コード分割多重アクセス（ＣＤＭＡ：Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）システム、広帯域コード分割多重アクセス（ＷＣＤＭＡ：Ｗｉｄｅｂａｎｄ  Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）システム、汎用パケット無線サービス（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ、ＧＰＲＳ）、ＬＴＥシステム、ＬＴＥ周波数分割二重（ＦＤＤ：Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）システム、ＬＴＥ時分割二重（ＴＤＤ：Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）、汎用移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）、マイクロ波アクセスのための世界的な相互運用性（ＷｉＭＡＸ：Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ）通信システム、ニューラジオ（ＮＲ：Ｎｅｗ  Ｒａｄｉｏ）または未来の５Ｇシステムなどであってもよい。
【００３７】
本出願の実施例における端末装置は、車載端末装置を指してもよく、未来５Ｇネットワークにおける端末装置または未来進化の公衆陸上移動通信網（ＰＬＭＮ：Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）の端末装置などであってもよく、本出願の実施例は限定されない。
【００３８】
本出願は、ネットワーク装置を参照して各実施例を説明する。本出願の実施例におけるネットワーク装置は、端末装置と通信する装置であってもよく、当該ネットワーク装置は、ＧＳＭまたはＣＤＭＡの基地局（Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｔａｔｉｏｎ、ＢＴＳ）であってもよく、ＷＣＤＭＡシステムの基地局（ＮｏｄｅＢ、ＮＢ）であってもよく、さらにＬＴＥシステムの進化型基地局（Ｅｖｏｌｕｔｉｏｎａｌ  ＮｏｄｅＢ、ｅＮＢまたはｅＮｏｄｅＢ）であってもよく、クラウド無線アクセスネットワーク（ＣＲＡＮ：Ｃｌｏｕｄ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）シナリオでのワイヤレスコントローラであってもよく、または当該ネットワーク装置は、リレーステーション、アクセスポイント、車載装置、ウェアラブル装置および未来５Ｇネットワークのネットワーク装置または未来進化のＰＬＭＮネットワークのネットワーク装置などであってもよく、本出願の実施例は限定されない。
【００３９】
図１および図２は、本出願の実施例の適用シナリオの概略図である。図１には、ネットワーク装置と２つの端末装置を例示的に示し、選択的に、本出願の実施例における無線通信システムは、複数のネットワーク装置を含むことができ、そして各ネットワーク装置のカバレッジ内には他の数の端末装置を含むことができ、本出願の実施例はこれに対して限定しない。なお、当該無線通信システムは、モビリティ管理エンティティ（ＭＭＥ：Ｍｏｂｉｌｅ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）、サービスゲートウェイ（Ｓ−ＧＷ：Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ）など他のネットワークエンティティをさらに含むことができるが、本出願の実施例はこれに限定されない。
【００４０】
具体的には、端末装置２０および端末装置３０は、Ｄ２Ｄ通信モードで通信することができ、Ｄ２Ｄ通信する場合、端末装置２０および端末装置３０は、Ｄ２Ｄリンク、即ち、サイドリンク（ＳＬ：Ｓｉｄｅｌｉｎｋ）を介して直接に通信する。例えば、図１または図２に示されたように、端末装置２０および端末装置３０は、サイドリンクを介して直接に通信する。図１では、端末装置２０と端末装置３０との間は、サイドリンクを介して通信して、その伝送リソースは、ネットワーク装置によって割り当てられ、図２では、端末装置２０と端末装置３０との間は、サイドリンクを介して通信して、その伝送リソースは、端末装置が自律的に選択され、ネットワーク装置が伝送リソースを割り当てる必要がない。
【００４１】
Ｄ２Ｄ通信は、車両間（Ｖｅｈｉｃｌｅ  ｔｏ  Ｖｅｈｉｃｌｅ、「Ｖ２Ｖ」と略称する）通信または車両から他の装置（Ｖｅｈｉｃｌｅ  ｔｏ  Ｅｖｅｒｙｔｈｉｎｇ、Ｖ２Ｘ）への通信を指すことができる。Ｖ２Ｘ通信において、一般的に、Ｘは、低速移動の無線装置、高速移動の車載装置などであるが、これに限定されない。無線で送受信する機能を備えるいずれかの装置、または無線送受信機能を備えるネットワーク制御ノードなどを指すことができる。本発明の実施例は、主にＶ２Ｘ通信のシナリオに適用されるが、他の任意のＤ２Ｄ通信シナリオにも適用されることができ、本出願の実施例はこれに対して限定しないことを理解されたい。
【００４２】
車両インターネットシステムにおいて、車載端末（ＶＵＥ：Ｖｅｈｉｃｌｅ  Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）または歩行者用ハンドヘルド端末（ＰＵＥ：Ｐｅｄｅｓｔｒｉａｎ  Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）などの検知機能を持つ端末装置、およびＰＵＥなどの検知機能を持たない端末装置の２種類のタイプの端末装置を有することができる。ＶＵＥは、より高い処理機能を持ち、そして通常は車内のバッテリにより電力が供給されるが、ＰＵＥは処理機能が低くて、電力消費の削減もＰＵＥが考慮する必要のある主な要素であるため、既存の車両インターネットシステムでは、ＶＵＥは完全な受信機能および検知機能を持つが、ＰＵＥは、受信機能および検知機能が一部持つかまたは持たないと見なされる。ＰＵＥに一部の検知機能があれば、そのリソースの選択はＶＵＥと類似な検知方法を採用し、検知することができる部分のリソースで利用可能なリソースの選択を行うことができる。ＰＵＥに検知機能がなければ、ＰＵＥがリソースプールで伝送リソースをランダムに選択する。
【００４３】
３ＧＰＰプロトコルのバージョンＲｅｌｅａｓｅ−１４において、伝送モード３（ｍｏｄｅ  ３）及び伝送モード４（ｍｏｄｅ  ４）の２種類の伝送モードが定義される。伝送モード３を使用する端末装置の伝送リソースは、基地局により割り当てられるものであり、端末装置は、基地局によって割り当てられたリソースをサイドリンクでデータ送信を行い、基地局は、端末装置に一回伝送されるリソースを割り当てることができ、端末装置に準静的に伝送されるリソースを割り当てることもできる。伝送モード４の端末装置が検知機能を備えると、検知（ｓｅｎｓｉｎｇ）と予約（ｒｅｓｅｒｖａｔｉｏｎ）の方式でデータを伝送し、検知機能を備えないと、リソースプールで伝送リソースをランダムに選択する。検知機能を備える端末装置は、リソースプールで検知の方式で利用可能なリソースセットを取得し、端末装置は、当該セットから１つのリソースをランダムに選択してデータを伝送する。車両インターネットシステムにおけるサービスには周期的な特徴があるため、端末装置は通常に準静的に伝送方式を採用し、即ち、端末装置が１つの伝送リソースを選択した後、複数の伝送周期の中で当該リソースを継続的に使用することにより、リソース再選択およびリソースの競合の確率を低下させる。端末装置は、現在伝送の制御情報に次回の伝送リソースの情報を予約する情報を搬送するため、他の端末装置は、当該端末装置の制御情報を検出することにより、このリソースが当該端末装置によって予約及び使用されるかどうかを判断することができ、リソース競合を減らす目的を達成する。
【００４４】
伝送モード３のリソースは基地局によってスケジュールされるため、伝送モード４のリソースプールは事前構成または基地局による構成であるので、両方はリソースプールで重複する場合が存在しなく、即ち、伝送モード３と伝送モード４にそれぞれ対応するリソースプールは、分離または重複しないものであり、モード３を使用する端末装置は、モード３をサポートするリソースプール中の時間−周波数リソースでデータを伝送し、モード４を使用する端末装置は、モード４をサポートするリソースプール中の時間−周波数リソースでデータを伝送する。
【００４５】
３ＧＰＰプロトコルの新しいバージョンＲｅｌｅａｓｅ−１５通信プロトコルをサポートする端末装置において、同様に前述した伝送モード３および伝送モード４のような２種類の伝送モードをサポートする。Ｒｅｌｅａｓｅ−１５の端末装置とＲｅｌｅａｓｅ−１４の端末装置が通信システムで一緒にデータを伝送する場合、検知機能を備える端末装置は、リソース検知を介してリソース選択することができ、検知機能を備えない端末装置にとっては、他の端末装置のデータ伝送との干渉を避けることは困難である。伝送モード３を使用する端末装置は基地局と接続し、そしてその伝送リソースは基地局により割り当てられるため、伝送モード３を使用する端末装置と伝送モード４を使用する端末装置が共存する場合、伝送モード３を使用する端末装置の伝送の信頼性をより保護する必要がある。
【００４６】
選択的に、図３に示されたように、車両インターネットシステムにおいて、端末装置は、キャリアアグリゲーションの方式に基づいて、２つのキャリアを介してネットワーク装置または他の端末装置に同じＰＤＣＰ層データを送信することができる。具体的には、図３に示されたように、１つのＰＤＣＰエンティティが２つのＲＬＣエンティティとバインドされる。当該端末装置は、送信しようとする第１のＰＤＣＰ  ＰＤＵを複製（ｄｕｐｌｉｃａｔｉｏｎ）して、第２のＰＤＣＰ  ＰＤＵを取得する。端末装置は、当該第１のＰＤＣＰ  ＰＤＵを当該２つのＲＬＣエンティティ中の１つのＲＬＣエンティティＲＬＣ１に送信し、当該第２のＰＤＣＰ  ＰＤＵを当該２つのＲＬＣエンティティ中の別の１つのＲＬＣエンティティＲＬＣ２に送信する。当該２つのＲＬＣエンティティは、それぞれ受信したＰＤＣＰ  ＰＤＵを処理し、２つの異なるキャリアを介して当該第１のＰＤＣＰ  ＰＤＵと当該第２のＰＤＣＰ  ＰＤＵをネットワーク装置または他の端末装置に送信する。
【００４７】
端末装置がネットワーク装置または他の端末装置によって送信されたデータを受信する場合、図３に示されたようなデータ送信プロセスの逆のプロセスを実行し得ることを理解されたい。
【００４８】
なお、本出願の各態様または特徴は、方法、装置または標準的なプログラミングおよび／またはエンジニアリング技術を使用した製造品として具現されることができる。本出願で使用した「製造品」という用語
は、任意のコンピュータ読み取り可能なデバイス、キャリアまたは媒体からアクセス可能なコンピュータプログラムを含む。例えば、コンピュータ読み取り可能な媒体は、磁気記憶装置（例えば、ハードディスク、フロッピーディスクまたは磁気テープなど）、光ディスク（例えば、コンパクトディスク（ＣＤ：Ｃｏｍｐａｃｔ  Ｄｉｓｃ）、デジタル多用途ディスク（ＤＶＤＤｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）など）、スマートカード及びフラッシュメモリデバイス（例えば、消去可能なプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ：Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、カード、スティックまたはキードライバなど）を含むことができるが、これらに限定されない。さらに、本明細書で説明された様々な記憶媒体は、情報を記憶するための１つまたは複数の装置および／または他の機械読み取り可能な媒体を表すことができる。「機械読み取り可能な媒体」という用語は、命令および／またはデータを格納、収容および／または搬送することができる様々な媒体を含むことができるが、これらに限定されない。
【００４９】
本明細書における「システム」および「ネットワーク」という用語は、本明細書で常に互換的に使用されることを理解されたい。本明細書における「および／または」という用語は、関連付けられたオブジェクトを説明する単なる関連付けであり、３種類の関係が存在することができることを示し、例えば、Ａおよび／またはＢは、Ａが独立で存在する場合、ＡとＢが同時に存在する場合、Ｂが独立で存在する場合など３つの場合を表す。さらに、本明細書における文字「／」は、一般的に、コンテキストオブジェクトが「または」の関係であることを示す。
【００５０】
図４は、本出願の実施例に係るデータ複製をサポートする方法２００の模式的なフローチャートである。図４に示されたように、当該方法２００は、送信側デバイスによって実行されることができ、当該送信側デバイスは、図１または図２に示されたような端末装置であってもよく、当該端末装置は、図３に示されたようなデータ伝送を実行することができ、当該方法２００における受信側デバイスは、図１に示されたようなネットワーク装置であってもよく、図１または図２に示されたような端末装置であってもよく、当該方法２００は、車両インターネットシステムに適用されることができる。当該方法２００は、次のコンテンツを含む。
【００５１】
ステップ２１０において、送信側デバイスは、受信側デバイスに複数のＲＬＣ  ＰＤＵを送信し、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含む。
【００５２】
送信側デバイスは、キャリアアグリゲーションを介してデータ複製サービスを行う場合、少なくとも２つのＲＬＣ  ＰＤＵを送信することを理解されたい。
【００５３】
選択的に、当該送信側デバイスが、キャリアアグリゲーションを介してデータ複製サービスを行う場合、当該指示フィールドを介して現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示する必要がある。
【００５４】
選択的に、当該指示フィールドは、現在のＲＬＣ  ＰＤＵに対応するＰＤＣＰに対応する無線ベアラの識別子（ＩＤ：Ｉｄｅｎｔｉｔｙ）を含む。
【００５５】
選択的に、当該指示フィールドは、論理チャネルの識別子（ＩＤ）を含む。
【００５６】
指示フィールドに論理チャネル（ＬＣＩＤ）および予約ビットが含まれる別の方式が存在することができる。ここで、同じベアラにサービスする２つの異なる論理チャネルは、異なる予約ビットの値によって区別することができる。具体的に、方式としては、以下である。
【００５７】
キャリア１：論理チャネルＡのために１つのＭＡＣ  ＳＤＵ  Ａを伝送して、予約ビット（ｒｅｓｅｒｖｅｄ  ｂｉｔ）＝０、ＬＣＩＤ＝Ｘを設定し、例えば、Ｘ＝００００１である。
【００５８】
キャリア２：論理チャネルＢのために別の１つのＭＡＣ  ＳＤＵ  Ｂ（複製ＳＤＵと理解してもよい）を伝送して、その予約ビット＝１、ＬＣＩＤ＝Ｘを設定し、同様にＸ＝００００１である。
【００５９】
前述した論理チャネルＡとＢは、ＰＤＣＰ複製の操作を具現するために、同じＰＤＣＰエンティティにサービスすることに留意する必要がある。上記の方法を使用することにより、予約のＬＣＩＤスペースを保留することができ、そして複製機能がＰＣ５−Ｓ情報に拡張することができる。図１０を参照すると、Ｒは、予約ビットが位置する位置を表し、その中の一つは、７ビットのＬ領域を含むフレーム構造であり、別の１つは１５ビットのＬ領域を含むフレーム構造であり、ここでは再び説明しない。
【００６０】
選択的に、前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、
前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダであり、
または、
前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダである。
【００６１】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは、異なる論理チャネルに対応し、および当該少なくとも２つのＲＬＣ  ＰＤＵは、同じ無線ベアラに対応する。
【００６２】
したがって、本出願の実施例のデータ複製をサポートする方法において、送信側デバイスが複数のＲＬＣ  ＰＤＵを送信する場合、複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことにより、受信側デバイスが複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することができ、なお、複製データの確実な伝送を実現することができる。
【００６３】
図５は、本出願の実施例に係るデータ複製をサポートする方法３００の模式的なフローチャートである。図５に示されたように、当該方法３００は、受信側デバイスによって実行されることができ、当該受信側デバイスは、図１に示されたようなネットワーク装置であってもよく、図１または図２に示されたような端末装置であってもよく、当該方法３００における送信側デバイスは、図１または図２に示されたような端末装置であってもよく、当該端末装置は、図３に示されたようにデータ伝送を実行することができ、当該方法３００は、車両インターネットシステムに適用されることができる。当該方法３００は、次のコンテンツを含む。
【００６４】
ステップ３１０において、受信側デバイスは、送信側デバイスによって送信される複数のＲＬＣ  ＰＤＵを受信する。
【００６５】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、指示フィールドを含む。
【００６６】
選択的に、当該指示フィールドは、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを含む。
【００６７】
選択的に、当該指示フィールドは、論理チャネルの識別子（ＩＤ）を含む。
【００６８】
選択的に、当該受信側デバイスは、当該少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、論理チャネルと無線ベアラとの間の対応関係を決定する。
【００６９】
選択的に、当該指示フィールドは、１ｂｉｔのコンテンツのみを含むことができ、例えば、プロトコルには、０００１０が００００１とのみ一緒にデータ複製（ｄｕｐｌｉｃａｔｉｏｎ）サービスを行うか、または独立的なベアラをサポートすることだけできないと規定すると、この場合、当該指示フィールドは、１ｂｉｔのコンテンツだけ含めば、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示することができる。
【００７０】
選択的に、当該論理チャネルと当該無線ベアラとの間の対応関係は事前に構成されたものであり、例えば、プロトコルによって決定される。
【００７１】
例えば、表１に示される論理チャネル識別子（ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  Ｉｄｅｎｔｉｔｙ：ＬＣ  ＩＤ）割り当て表では、予約索引（ｒｅｓｅｒｖｅｄ  Ｉｎｄｅｘ）の中で０１０１１−１０１００をデータ複製（ｄｕｐｌｉｃａｔｉｏｎ）のためにサービスするＲＬＣに割り当てることができ、例えば、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ００００１とｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ０１０１１は、ベアラ１に使用されるＰＤＣＰエンティティに共同でサービスすることができ、ｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ０００１０とｌｏｇｉｃａｌ  ｃｈａｎｎｅｌ  ０１１００は、ベアラ２に使用されるＰＤＣＰエンティティに共同でサービスすることができる。
【表１】
2020529148.tif 000003
【００７２】
選択的に、前記少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダは、
前記少なくとも１つのＲＬＣ  ＰＤＵに対応するＲＬＣヘッダであり、
または、
前記少なくとも１つのＲＬＣ  ＰＤＵに含まれるＲＬＣヘッダであることに留意する必要がある。
【００７３】
つまり、ＲＬＣ  ＰＣＵとＲＬＣヘッダには２つの対応方法があり、その中の１つ方法としては、ＲＬＣ  ＰＤＵとＲＬＣヘッダは対応関係であり、つまり、この関係では、ＲＬＣ  ＰＤＵにはＲＬＣヘッダが含まれなくてもよくて、ＲＬＣヘッダがＲＬＣ  ＰＤＵ以外に含まれるが、この場合、ＲＬＣヘッダはＭＡＣサブヘッダ（ＭＡＣ  Ｓｕｂ−ｈｅａｄｅｒ）を形成することができるため、こうして、ＲＬＣ  ＰＤＵとＭＡＣサブヘッドを構成するＲＬＣヘッダを利用して、ＭＡＣヘッダ（ＭＡＣｈｅａｄｅｒ）を再結合して、ＭＡＣ層のデータユニットを共同に構成することができる。
【００７４】
別の１つの方法としては、ＲＬＣ  ＰＣＵにＲＬＣヘッダがふくまれ、この方法では、ＲＬＣ  ＰＣＵがＭＡＣ層のデータユニットを構成する。ＭＡＣ層のデータユニットはＭＡＣ  ＰＤＵであってもよい。
【００７５】
指示フィールドに論理チャネル（ＬＣＩＤ）および予約ビットが含まれる別の方式がさらに存在することもできる。ここで、同じベアラにサービスする２つの異なる論理チャネルは、異なる予約ビットの値によって区別することができる。具体的に、方式としては、以下である。
【００７６】
キャリア１：論理チャネルＡのために１つのＭＡＣ  ＳＤＵ  Ａを伝送して、予約ビット（ｒｅｓｅｒｖｅｄ  ｂｉｔ）＝０、ＬＣＩＤ＝Ｘを設定し、例えば、Ｘ＝００００１である。
【００７７】
キャリア２：論理チャネルＢのために別の１つのＭＡＣ  ＳＤＵ  Ｂ（複製ＳＤＵと理解してもよい）を伝送して、その予約ビット＝１、ＬＣＩＤ＝Ｘを設定し、同様にＸ＝００００１である。
【００７８】
前述した論理チャネルＡとＢは、ＰＤＣＰ複製の操作を具現するために、同じＰＤＣＰエンティティにサービスすることに留意する必要がある。上記の方法を使用することにより、予約のＬＣＩＤスペースを保留することができ、そして複製機能がＰＣ５−Ｓ情報に拡張することができる。図１０を参照すると、Ｒは、予約ビットが位置する位置を表し、その中の一つは、７ビットのＬ領域を含むフレーム構造であり、別の１つは１５ビットのＬ領域を含むフレーム構造であり、ここでは再び説明しない。
【００７９】
ステップ３２０において、当該受信側デバイスは、論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する。
【００８０】
したがって、本出願の実施例のデータ複製をサポートする方法において、受信側デバイスが複数のＲＬＣ  ＰＤＵを受信する場合、論理チャネルと無線ベアラとの間の対応関係にしたがって、複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定することができ、なお、複製データの確実な伝送を実現することができる。
【００８１】
図６は、本出願の実施例に係る送信側デバイス４００の模式的なブロック図である。図６に示されたように、当該送信側デバイス４００は、
受信側デバイスに複数のＲＬＣ  ＰＤＵを送信することであって、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを指示するための指示フィールドを含むことに使用される送信ユニット４１０を含む。
【００８２】
選択的に、当該指示フィールドは、現在のＲＬＣ  ＰＤＵに対応するパケットデータ収束プロトコル（ＰＤＣＰ）に対応する無線ベアラの識別子（ＩＤ）を含む。
【００８３】
選択的に、当該指示フィールドは、論理チャネルの識別子（ＩＤ）を含む。
【００８４】
指示フィールドに論理チャネル（ＬＣＩＤ）および予約ビットが含まれる別の方式がさらに存在することもできる。ここで、同じベアラにサービスする２つの異なる論理チャネルは、異なる予約ビットの値によって区別することができる。具体的に、方式としては、以下である。
【００８５】
キャリア１：論理チャネルＡのために１つのＭＡＣ  ＳＤＵ  Ａを伝送して、予約ビット（ｒｅｓｅｒｖｅｄ  ｂｉｔ）＝０、ＬＣＩＤ＝Ｘを設定し、例えば、Ｘ＝００００１である。
【００８６】
キャリア２：論理チャネルＢのために別の１つのＭＡＣ  ＳＤＵ  Ｂ（複製ＳＤＵと理解してもよい）を伝送して、その予約ビット＝１、ＬＣＩＤ＝Ｘを設定し、同様にＸ＝００００１である。
【００８７】
前述した論理チャネルＡとＢは、ＰＤＣＰ複製の操作を具現するために、同じＰＤＣＰエンティティにサービスすることに留意する必要がある。上記の方法を使用することにより、予約のＬＣＩＤスペースを保留することができ、そして複製機能がＰＣ５−Ｓ情報に拡張することができる。図１０を参照すると、Ｒは、予約ビットが位置する位置を表し、その中の一つは、７ビットのＬ領域を含むフレーム構造であり、別の１つは１５ビットのＬ領域を含むフレーム構造であり、ここでは再び説明しない。
【００８８】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは、異なる論理チャネルに対応し、および当該少なくとも２つのＲＬＣ  ＰＤＵは、同じ無線ベアラに対応する。
【００８９】
選択的に、当該送信側デバイス４００は、車両インターネットシステムに適用される。
【００９０】
本出願の実施例に係る送信側デバイス４００における各モジュールの上述した及び他の操作および／または機能は、それぞれ図４の方法２００における送信側デバイスの対応するプロセスを具現するためであることを理解されたい。簡潔のために、ここで再び説明しない。
【００９１】
図７は、本出願の実施例に係る受信側デバイス５００の模式的なブロック図である。図７に示されたように、当該受信側デバイス５００は、
送信側デバイスによって送信される複数のＲＬＣ  ＰＤＵを受信するための受信ユニット５１０と、
論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定するための処理ユニット５２０とを含む。
【００９２】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、現在のＲＬＣ  ＰＤＵに対応する無線ベアラを含む指示フィールドを含み、
当該処理ユニット５２０が、論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、当該処理ユニット５２０は、当該少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、当該論理チャネルと当該無線ベアラとの間の対応関係を決定する。
【００９３】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、論理チャネルの識別子（ＩＤ）を含む指示フィールドを含み、
在当該処理ユニット５２０論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、当該処理ユニット５２０は、さらに当該少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、当該論理チャネルと当該無線ベアラとの間の対応関係を決定することに使用される。
【００９４】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダには、論理チャネルの識別子（ＩＤ）を含む指示フィールドを含み、
当該処理ユニットが、論理チャネルと無線ベアラとの間の対応関係にしたがって、当該複数のＲＬＣ  ＰＤＵ中の各ＲＬＣ  ＰＤＵに対応する無線ベアラを決定する前に、当該処理ユニットは、さらに当該少なくとも１つのＲＬＣ  ＰＤＵのＲＬＣヘッダに含まれる指示フィールドにしたがって、当該論理チャネルと当該無線ベアラとの間の対応関係を決定することに使用される。
【００９５】
指示フィールドに論理チャネル（ＬＣＩＤ）および予約ビットが含まれる別の方式がさらに存在することもできる。ここで、同じベアラにサービスする２つの異なる論理チャネルは、異なる予約ビットの値によって区別することができる。具体的に、方式としては、以下である。
【００９６】
キャリア１：論理チャネルＡのために１つのＭＡＣ  ＳＤＵ  Ａを伝送して、予約ビット（ｒｅｓｅｒｖｅｄ  ｂｉｔ）＝０、ＬＣＩＤ＝Ｘを設定し、例えば、Ｘ＝００００１である。
【００９７】
キャリア２：論理チャネルＢのために別の１つのＭＡＣ  ＳＤＵ  Ｂ（複製ＳＤＵと理解してもよい）を伝送して、その予約ビット＝１、ＬＣＩＤ＝Ｘを設定し、同様にＸ＝００００１である。
【００９８】
前述した論理チャネルＡとＢは、ＰＤＣＰ複製の操作を具現するために、同じＰＤＣＰエンティティにサービスすることに留意する必要がある。上記の方法を使用することにより、予約のＬＣＩＤスペースを保留することができ、そして複製機能がＰＣ５−Ｓ情報に拡張することができる。図１０を参照すると、Ｒは、予約ビットが位置する位置を表し、その中の一つは、７ビットのＬ領域を含むフレーム構造であり、別の１つは１５ビットのＬ領域を含むフレーム構造であり、ここでは再び説明しない。
【００９９】
選択的に、当該論理チャネルと当該無線ベアラとの間の対応関係は事前に構成されたものである。
【０１００】
選択的に、当該複数のＲＬＣ  ＰＤＵのうちの少なくとも２つのＲＬＣ  ＰＤＵは、異なる論理チャネルに対応し、および当該少なくとも２つのＲＬＣ  ＰＤＵは、同じ無線ベアラに対応する。
【０１０１】
選択的に、当該受信側デバイス５００は、車両インターネットシステムに適用される。
【０１０２】
本出願の実施例に係る受信側デバイス５００における各モジュールの上述したおよび他の操作および／または機能は、それぞれ図５の方法３００における受信側デバイスの対応するプロセスを具現するためであることを理解されたい。簡潔のために、ここで再び説明しない。
【０１０３】
図８は、本出願の実施例によって提供されるデータ複製をサポートする装置６００の模式的なブロック図であり、当該装置６００は、
コードを含むプログラムを記憶するためのメモリ６１０と、
他の装置と通信するためのトランシーバ６２０と、
メモリ６１０中のプログラムコードを実行するためのプロセッサ６３０とを含む。
【０１０４】
選択的に、当該コードが実行されるとき、当該プロセッサ６３０は、さらに図４における方法２００中の送信側デバイスによって実行される各動作を具現することもでき、簡潔のために、ここで再び説明しない。この場合、当該装置６００は、車載端末などの端末装置であり得る。
【０１０５】
選択的に、当該コードが実行されるとき、当該プロセッサ６３０は、さらに図５における方法３００中の受信側デバイスによって実行される各動作を具現することもでき、簡潔のために、ここで再び説明しない。この場合、当該装置６００は、アクセスネットワーク機器であってもよく、コアネットワーク機器であってもよい。トランシーバ６２０は、プロセッサ６３０の駆動下で具体的な信号の送受信するために使用される。
【０１０６】
本出願の実施例において、当該プロセッサ６３０は、中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）であってもよく、当該プロセッサ６３０は他の汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジックデバイス、ディスクリートハードウェアデバイスなどであってもよいことを理解されたい。汎用プロセッサは、マイクロプロセッサであってもよく、または当該プロセッサが任意の従来のプロセッサなどであってもよい。
【０１０７】
当該メモリ６１０は、読み取り専用メモリおよびランダムアクセスメモリを含むことができ、プロセッサ６３０に命令およびデータを提供する。メモリ６１０の一部は、さらに不揮発性ランダムアクセスメモリを含むことができる。例えば、メモリ６１０は、さらに装置のタイプの情報を記憶することもできる。
【０１０８】
トランシーバ６２０は、例えば、周波数変調および復調機能または高周波数およびダウンコンバージョン機能等の信号の送信および受信の機能を具現するために使用されることができる。
【０１０９】
具現プロセスにおいて、前記方法の少なくとも１つのステップは、プロセッサ６３０中のハードウェアの集積論理回路によって完成することができ、または当該集積論理回路は、ソフトウェアの形の命令の駆動下で当該少なくとも１つのステップを完成することができる。したがって、データ複製をサポートする装置６００は、チップまたはチップセットであることができる。本出願の実施例によって開示された方法のステップは、直接に、ハードウェアプロセッサによって実行されて完成することとして具現され、またはプロセッサ中のハードウェアおよびソフトウェアモジュールの組み合わせによって実行して完成する。ソフトウェアモジュールは、ランダムメモリ、フラッシュメモリ、読み取り専用メモリ、プログラマブル読み取り専用メモリまたは電気的に消去可能なプログラマブルメモリ、レジスタなど従来の記憶媒体に配置されることができる。当該記憶媒体は、メモリに配置され、プロセッサ６３０は、メモリ中の情報を読み取り、そのハードウェアに結合して前記方法のステップを完成する。繰り返しを避けるため、ここでは詳しく説明しない。
【０１１０】
図９は、本出願の実施例に係るシステムチップ７００の模式的な構造図である。図９のシステムチップ７００は、入力インターフェース７０１、出力インターフェース７０２、プロセッサ７０３およびメモリ７０４を含み、これらの間には内部通信接続ラインを介して接続されることができ、当該プロセッサ７０３は、当該メモリ７０４中のコードを実行するために使用される。
【０１１１】
選択的に、当該コードが実行されるとき、当該プロセッサ７０３は、方法の実施例における送信側デバイスによって実行される方法を具現する。簡潔のために、ここで再び説明しない。
【０１１２】
選択的に、当該コードが実行されるとき、当該プロセッサ７０３は、方法の実施例における受信側デバイスによって実行される方法を具現する。簡潔のために、ここで再び説明しない。
【０１１３】
前記実施例において、ソフトウェア、ハードウェア、ファームウェアまたはそれらの任意の組み合わせによって全体的または部分的に実現することができる。ソフトウェアを使用して実現する場合、コンピュータプログラム製品の形態で全体的または部分的に実現することができる。当該コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータに当該コンピュータプログラム命令をロードして実行する場合、本出願の実施例に記載のプロセスまたは機能を全体的または部分的に生成する。当該コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であり得る。当該コンピュータ命令は、コンピュータ読み取り可能な記憶媒体に記憶されることができ、または１つのコンピュータ読み取り可能な記憶媒体から別のコンピュータ読み取り可能な記憶媒体に伝送することができ、例えば、当該コンピュータ命令は、有線（例えば、同軸ケーブル、光ファイバ、デジタル加入者線（ＤＳＬ））または無線（例えば、赤外線、無線、マイクロ波等）を介して、１つのＷｅｂサイト、コンピュータ、サーバまたはデータセンタから別のＷｅｂサイト、コンピュータ、サーバまたはデータセンタに伝送することができる。当該コンピュータ読み取り可能な記憶媒体は、コンピュータがアクセス可能ないずれの利用可能な媒体であることができ、または1つ以上の利用可能な媒体によって統合されたサーバ、データセンタなどのデータ記憶装置であることができる。当該利用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、磁気テープ）、光学媒体（例えば、ＤＶＤ）、または半導体媒体（例えば、ソリッドステートハードディスク（ＳＳＤ：Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｉｓｋ））などであり得る。
【０１１４】
本出願の様々な実施例において、前記各プロセスの番号の大きさは実行する前後順番を意味せず、各プロセスの実行順番は、その機能と内部論理によって決定されるべきであり、本出願の実施例の実施プロセスに対してあらゆる制限を構成してはならないことを理解されたい。
【０１１５】
当業者は、説明の便宜上および簡潔のために、上記したシステム、装置およびユニットの具体的な作業プロセスは、前述方法の実施例における対応するプロセスを参照し得ることを明確に理解することができ、ここでは再び説明しない。
【０１１６】
上記の説明は本出願の具体的な実施形態に過ぎず、本出願の保護範囲はそれに限定せず、当業者が本出願に開示された技術的範囲内で容易に想到し得る変更または置換は、すべて本出願の保護範囲内に含まれるべきある。したがって、本出願の保護範囲は、特許請求の保護範囲を基準とするべきである。
【図１】
2020529148.tif 000004
【図２】
2020529148.tif 000005
【図３】
2020529148.tif 000006
【図４】
2020529148.tif 000007
【図５】
2020529148.tif 000008
【図６】
2020529148.tif 000009
【図７】
2020529148.tif 000010
【図８】
2020529148.tif 000011
【図９】
2020529148.tif 000012
【図１０】
2020529148.tif 000013
【国際調査報告】
2020529148.tif 000014
2020529148.tif 000015
2020529148.tif 000016
2020529148.tif 000017