特許 6806411 コネクションレス伝送における同期維持のためのシステムおよび方法

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

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

(11)【特許番号】6806411

(24)【登録日】2020年12月8日

(45)【発行日】2021年1月6日

(54)【発明の名称】コネクションレス伝送における同期維持のためのシステムおよび方法

(51)【国際特許分類】

   H04W 76/11 20180101AFI20201221BHJP

   H04W 76/30 20180101ALI20201221BHJP

【ＦＩ】

   H04W76/11

   H04W76/30

【請求項の数】18

【全頁数】23

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

(86)(22)【出願日】2017年4月28日

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

(43)【公表日】2019年6月6日

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

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

(87)【国際公開日】20171116

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

(31)【優先権主張番号】62/334,740

(32)【優先日】2016年5月11日

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

(31)【優先権主張番号】15/484,540

(32)【優先日】2017年4月11日

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

(73)【特許権者】

【識別番号】504161984

【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド

(74)【代理人】

【識別番号】110000877

【氏名又は名称】龍華国際特許業務法人

(72)【発明者】

【氏名】テニー、ネイサン エドワード

(72)【発明者】

【氏名】ズン、シャオシャオ

【審査官】 吉村 真治▲郎▼

(56)【参考文献】

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

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

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

【文献】 国際公開第２０１６／０１３５９０（ＷＯ，Ａ１）

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

【文献】 3GPP，TS 43.064 V13.0.0 (2015-11)，General Packet Radio Service (GPRS); Overall description of the GPRS radio interface; Stage 2 (Release 13)，２０１５年１１月，pages 45,87,92-94,96-99，ＵＲＬ，https://www.3gpp.org/DynaReport/43-series.htm

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

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

受信デバイスを動作させるための方法であって、前記方法は、
前記受信デバイスによって、第１のバースト伝送の第１のプロトコルデータユニット（ＰＤＵ）を受信する段階であって、前記第１のＰＤＵは、前記第１のバースト伝送に関連付けられた第１の伝送識別子（Ｔ＿ＩＤ）を有し、前記第１のＰＤＵは、前記第１のＰＤＵが前記第１のバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示をさらに有する、段階と、
前記第１のＴ＿ＩＤに関連付けられた第１の無線リンク制御（ＲＬＣ）リソースを、前記第１のＴ＿ＩＤに関連付けられた前記第１のＲＬＣリソースが存在する場合、前記受信デバイスによってリリースする段階と、
前記受信デバイスによって、第２のバースト伝送の第２のＰＤＵを受信する段階であって、前記第２のＰＤＵは、前記第２のバースト伝送に関連付けられた第２のＴ＿ＩＤを有する、段階と、
前記第２のＴ＿ＩＤが古いＴ＿ＩＤの場合、前記受信デバイスによってエラー指示を送信デバイスへ送信する段階と
を備える方法。

【請求項2】

前記受信デバイスによって、前記第１のＰＤＵのための確認応答を送信する段階をさらに備える、請求項１に記載の方法。

【請求項3】

前記第２のＴ＿ＩＤが新たなＴ＿ＩＤである場合、前記第２のＴ＿ＩＤに関連付けられた第２のＲＬＣリソースを前記受信デバイスによって確立する段階と、
前記第２のＴ＿ＩＤが古いＴ＿ＩＤの場合、且つ前記第２のＴ＿ＩＤが関連付けられたＲＬＣリソースを有さない場合、前記受信デバイスによってエラー状態を示す段階とをさらに備える、請求項１または２に記載の方法。

【請求項4】

前記受信デバイスによって、前記第２のＴ＿ＩＤを古いＴ＿ＩＤとして更新する段階をさらに備える、請求項３に記載の方法。

【請求項5】

前記第１のバースト伝送および前記第２のバースト伝送は、全く同じである、請求項３または４に記載の方法。

【請求項6】

前記受信デバイスによって、前記第２のＰＤＵのための確認応答を送信する段階をさらに備える、請求項３に記載の方法。

【請求項7】

前記確認応答および前記エラー状態は、単一のＰＤＵで送信される、請求項６に記載の方法。

【請求項8】

前記第２のＲＬＣリソースを確立する段階は、前記第２のバースト伝送に関連付けられたＲＬＣエンティティを確立する段階を含む、請求項３から７のいずれか一項に記載の方法。

【請求項9】

前記受信デバイスは、ダウンリンクバースト伝送におけるユーザ機器（ＵＥ）、またはアップリンクバースト伝送におけるアクセスノードのうちの１つを含む、請求項１から８のいずれか一項に記載の方法。

【請求項10】

伝送デバイスを動作させるための方法であって、前記方法は、
前記伝送デバイスによって、第１のバースト伝送の第１の伝送識別子（Ｔ＿ＩＤ）に関連付けられた無線リンク制御（ＲＬＣ）リソースを確立する段階と、
前記伝送デバイスによって、前記第１のバースト伝送の第１のプロトコルデータユニット（ＰＤＵ）を送信する段階であって、前記第１のＰＤＵは、前記第１のＴ＿ＩＤと、前記第１のＰＤＵが前記第１のバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示とを有する、段階と、
前記伝送デバイスによって、第２のバースト伝送の第２のＰＤＵを送信する段階であって、前記第２のＰＤＵは、前記第２のバースト伝送に関連付けられた第２のＴ＿ＩＤを有する、段階と、
前記第２のＴ＿ＩＤが古いＴ＿ＩＤの場合に受信デバイスによって送信される前記第１のバースト伝送に関連付けられたエラー指示を前記伝送デバイスが受信した場合、前記第１のＴ＿ＩＤに関連付けられた前記ＲＬＣリソースを前記伝送デバイスによってリリースする段階と
を備える方法。

【請求項11】

前記伝送デバイスは、アップリンクバースト伝送におけるユーザ機器（ＵＥ）、またはダウンリンクバースト伝送におけるアクセスノードのうちの１つを含む、請求項１０に記載の方法。

【請求項12】

受信デバイスであって、
１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサによって実行されるプログラミングを格納するコンピュータ可読記憶媒体と
を備え、
前記プログラミングは、
第１のバースト伝送の第１のプロトコルデータユニット（ＰＤＵ）を受信することであって、前記第１のＰＤＵは、前記第１のバースト伝送に関連付けられた第１の伝送識別子（Ｔ＿ＩＤ）を有し、前記第１のＰＤＵはさらに、前記第１のＰＤＵが前記第１のバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示を有する、受信することと、
前記第１のＴ＿ＩＤに関連付けられた第１の無線リンク制御（ＲＬＣ）リソースを、前記第１のＴ＿ＩＤに関連付けられた前記第１のＲＬＣリソースが存在する場合、リリースすることと
第２のバースト伝送の第２のＰＤＵを受信することであって、前記第２のＰＤＵは、前記第２のバースト伝送に関連付けられた第２のＴ＿ＩＤを有する、受信することと、
前記第２のＴ＿ＩＤが古いＴ＿ＩＤの場合、エラー指示を送信デバイスへ送信することと
を実行するよう前記受信デバイスを構成する命令を含む、
受信デバイス。

【請求項13】

前記プログラミングは、前記第１のＰＤＵのための確認応答を送信するよう前記受信デバイスを構成する命令を含む、請求項１２に記載の受信デバイス。

【請求項14】

前記プログラミングは、前記第２のＴ＿ＩＤが新たなＴ＿ＩＤである場合、前記第２のＴ＿ＩＤに関連付けられた第２のＲＬＣリソースを確立することと、前記第２のＴ＿ＩＤが古いＴ＿ＩＤの場合、且つ前記第２のＴ＿ＩＤが関連付けられたＲＬＣリソースを有さない場合、エラー状態を示すこととを実行するよう前記受信デバイスを構成する命令を含む、請求項１２または１３に記載の受信デバイス。

【請求項15】

前記プログラミングは、前記第２のＴ＿ＩＤを古いＴ＿ＩＤとして更新するよう前記受信デバイスを構成する命令を含む、請求項１４に記載の受信デバイス。

【請求項16】

前記プログラミングは、前記第２のＰＤＵのための確認応答を送信するよう前記受信デバイスを構成する命令を含む、請求項１４または１５に記載の受信デバイス。

【請求項17】

伝送デバイスであって、
１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサによって実行されるプログラミングを格納するコンピュータ可読記憶媒体と
を備え、
前記プログラミングは、
第１のバースト伝送の第１の伝送識別子（Ｔ＿ＩＤ）に関連付けられた無線リンク制御（ＲＬＣ）リソースを確立することと、
前記第１のバースト伝送の第１のプロトコルデータユニット（ＰＤＵ）を送信することであって、前記第１のＰＤＵは、前記第１のＴ＿ＩＤと、前記第１のＰＤＵが前記第１のバースト伝送の最終ＰＤＵであることを示す最終ＰＤＵ指示とを有する、送信することと、
第２のバースト伝送の第２のＰＤＵを送信することであって、前記第２のＰＤＵは、前記第２のバースト伝送に関連付けられた第２のＴ＿ＩＤを有する、送信することと、
前記伝送デバイスが、前記第２のＴ＿ＩＤが古いＴ＿ＩＤの場合に受信デバイスによって送信される前記第１のバースト伝送に関連付けられたエラー指示を受信する場合、前記第１のＴ＿ＩＤに関連付けられた前記ＲＬＣリソースをリリースすることと
を実行するよう前記伝送デバイスを構成する命令を含む。

【請求項18】

請求項１から１１のいずれか一項に記載の方法を実行するよう適合化されているプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１７年４月１１日出願の「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ Ｍａｉｎｔａｉｎｉｎｇ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｉｎ Ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ Ｔｒａｎｓｍｉｓｓｉｏｎｓ」と題する米国非仮特許出願第１５／４８４，５４０号に基づく優先権を主張し、当該出願は、２０１６年５月１１日出願の「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ Ｍａｉｎｔａｉｎｉｎｇ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｉｎ Ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ Ｔｒａｎｓｍｉｓｓｉｏｎｓ」と題する米国仮特許出願第６２／３３４，７４０号に基づく優先権を主張し、両特許出願は、参照によってそれらの全体が再現されるかのように本明細書に組み込まれる。

【0002】

本開示は、概して、デジタル通信のためのシステムおよび方法に関連し、具体的な実施形態では、コネクションレス伝送における同期維持のためのシステムおよび方法に関連する。

【背景技術】

【0003】

第３世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）、狭域インターネットオブシングス（ＮＢ‐ＩｏＴ）、第５世代（５Ｇ）などの多くの技術的規格に関する提案により、通信ネットワーク（または単純にネットワーク）におけるエンティティとユーザ機器（ＵＥ）との間のコネクションレス型バースト伝送の何らかの形態の可能性が高まっている。概して、これらの技術は、ＵＥと、モビリティ管理エンティティ（ＭＭＥ）などのコアネットワークノードにおいてＵＥのために維持される非アクセス層（ＮＡＳ）コンテキストとの間のエンドツーエンドセキュリティに依拠し、基地局または発展型ＮｏｄｅＢ（ｅＮＢ）などのアクセスノードにおけるＵＥのためのアクセス層（ＡＳ）コンテキストの確立および維持に関連付けられるオーバーヘッドを回避する。

【0004】

ＮＡＳコンテキストはバースト伝送の複数のインスタンスにわたって永続的であるので、ＮＡＳコンテキストの状態情報は、１回の伝送の間のみでなく、当該バースト伝送が完了した後も、ＵＥとネットワークとの間で同期されたままである必要がある。特に、ＮＡＳコンテキストからの情報（例えば、ＮＡＳシーケンス番号）が暗号同期として用いられる場合、当該情報は、確実に同期されたままでなければならず、そうでなければ、正しくない復号化が行われることになる。同期が失われたことは検出可能でない場合があり、アプリケーション層に不要データを搬送することになる。同期が要件となることによって、例えば、レイヤ２における自動再送要求（ＡＲＱ）メカニズムを用いることによる、信頼できる搬送が必要となる。

【発明の概要】

【0005】

例示的な実施形態は、コネクションレス伝送における同期維持のためのシステムおよび方法を提供する。

【0006】

例示的な実施形態によれば、受信デバイスを動作させるための方法が提供される。 本方法は、受信デバイスによって、第１のバースト伝送の第１のプロトコルデータユニット（ＰＤＵ）を受信する段階であって、第１のＰＤＵは、第１のバースト伝送に関連付けられた第１の伝送識別子（Ｔ＿ＩＤ）を有し、第１のＰＤＵは、第１のＰＤＵが第１のバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示をさらに有する、段階と、第１のＴ＿ＩＤに関連付けられた第１の無線リンク制御（ＲＬＣ）リソースを、第１のＴ＿ＩＤに関連付けられた第１のＲＬＣリソースが存在する場合、受信デバイスによってリリースする段階とを備える。

【0007】

本方法は、受信デバイスによって、第１のＰＤＵのための確認応答を送信する段階を備える。本方法は、また受信デバイスによって、第２のバースト伝送の第２のＰＤＵを受信する段階であって、第２のＰＤＵは、第２のバースト伝送に関連付けられた第２のＴ＿ＩＤを有する、段階と、第２のＴ＿ＩＤが新たなＴ＿ＩＤである場合、第２のＴ＿ＩＤに関連付けられた第２のＲＬＣリソースを受信デバイスによって確立する段階と、第２のＴ＿ＩＤが古いＴ＿ＩＤの場合、且つ第２のＴ＿ＩＤが関連付けられたＲＬＣリソースを有さない場合、受信デバイスによってエラー状態を示す段階とを備える。

【0008】

本方法は、また受信デバイスによって、第２のＴ＿ＩＤを古いＴ＿ＩＤとして更新する段階を備える。第１のバースト伝送および第２のバースト伝送は、全く同じである。本方法は、また受信デバイスによって、第２のＰＤＵのための確認応答を送信する段階を備える。確認応答およびエラー状態は、単一のＰＤＵで送信される。 第２のＲＬＣリソースを確立する段階は、第２のバースト伝送に関連付けられたＲＬＣエンティティを確立する段階を含む。受信デバイスは、ダウンリンクバースト伝送におけるユーザ機器（ＵＥ）、またはアップリンクバースト伝送におけるアクセスノードのうちの１つを含む。

【0009】

例示的な実施形態によれば、伝送デバイスを動作させるための方法が提供される。本方法は、伝送デバイスによって、バースト伝送のＴ＿ＩＤに関連付けられたＲＬＣリソースを確立する段階と、伝送デバイスによって、バースト伝送の第１のＰＤＵを送信する段階であって、第１のＰＤＵは、Ｔ＿ＩＤと、第１のＰＤＵがバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示とを有する、段階と、第１のＰＤＵのための確認応答、またはバースト伝送に関連付けられたエラー指示のうちの１つを伝送デバイスが受信した場合、Ｔ＿ＩＤに関連付けられたＲＬＣリソースを伝送デバイスによってリリースする段階とを備える。

【0010】

本方法は、また伝送デバイスによって、バースト伝送の第２のＰＤＵを送信する段階であって、第２のＰＤＵがＴ＿ＩＤを有する段階を備える。第２のＰＤＵはさらに、第２のＰＤＵを示す先頭ＰＤＵ指示がバースト伝送の先頭ＰＤＵであることを有する。伝送デバイスは、アップリンクバースト伝送におけるＵＥ、またはダウンリンクバースト伝送おけるアクセスノードのうちの１つを含む。

【0011】

例示的な実施形態によれば、受信デバイスが提供される。受信デバイスは、１つまたは複数のプロセッサと、当該１つまたは複数のプロセッサによる実行のためのプログラミングを格納するコンピュータ可読記憶媒体とを含む。本プログラミングは、第１のバースト伝送の第１のＰＤＵを受信することであって、第１のＰＤＵは、第１のバースト伝送に関連付けられた第１のＴ＿ＩＤを有し、第１のＰＤＵは、第１のＰＤＵが第１のバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示をさらに有する、ことと、第１のＴ＿ＩＤに関連付けられた第１のＲＬＣリソースを、第１のＴ＿ＩＤに関連付けられた第１のＲＬＣリソースが存在する場合、リリースすることとを有する受信デバイスが構成されるよう命令を含む。

【0012】

プログラミングは、第１のＰＤＵのための確認応答を送信するよう受信デバイスを構成する命令を含む。本プログラミングは、第２のバースト伝送の第２のＰＤＵを受信し、第２のＰＤＵは、第２のバースト伝送に関連付けられた第２のＴ＿ＩＤを有し、第２のＴ＿ＩＤが新たなＴ＿ＩＤである場合、第２のＴ＿ＩＤに関連付けられた第２のＲＬＣリソースを確立することと、第２のＴ＿ＩＤが古いＴ＿ＩＤの場合、且つ第２のＴ＿ＩＤが関連付けられたＲＬＣリソースを有さない場合、エラー状態を示すこととを実行するよう受信デバイスを構成する命令を含む。本プログラミングは、第２のＴ＿ＩＤを古いＴ＿ＩＤとして更新するよう受信デバイスを構成する命令を含む。本プログラミングは、第２のＰＤＵための確認応答を送信するよう受信デバイスを構成する命令を含む。

【0013】

例示的な実施形態によれば、伝送デバイスが提供される。伝送デバイスは、１つまたは複数のプロセッサと、当該１つまたは複数のプロセッサによる実行のためのプログラミングを格納するコンピュータ可読記憶媒体とを含む。本プログラミングは、バースト伝送のＴ＿ＩＤに関連付けられたＲＬＣリソースを確立することと、バースト伝送の第１のＰＤＵを送信することと、第１のＰＤＵは、Ｔ＿ＩＤと、第１のＰＤＵがバースト伝送の最終ＰＤＵである旨を示す最終ＰＤＵ指示とを有する、ことと、第１のＰＤＵのための確認応答、またはバースト伝送に関連付けられたエラー指示のうちの１つを伝送デバイスが受信した場合、Ｔ＿ＩＤに関連付けられたＲＬＣリソースをリリースすることとを有する伝送デバイスが構成される命令を含む。

【0014】

プログラミングは、バースト伝送の第２のＰＤＵを送信するよう伝送デバイスを構成する命令を含み、当該第２のＰＤＵがＴ＿ＩＤを含む。

【0015】

前述の実施形態の実施によって、バースト伝送を用いて通信する送信デバイスと受信デバイスとの間において、同期外れ状態の発生が抑制される。同期外れ状態になると、受信デバイスは受信したデータを復号化することが不可能になるので、データ伝送が無意味となる。

【図面の簡単な説明】

【0016】

本開示およびその利点をより十分に理解するために、ここで、添付図面と併せて、以下の説明が参照される。

【0017】

【図1】例示的な通信システムを図示する。

【0018】

【図2】本明細書に提示される実施形態に応じたＵＥとアクセスノードとの間のアップリンクバースト伝送において交換されるメッセージおよび実行される処理の図を図示する。

【0019】

【図3】本明細書に提示される実施形態に応じた暗号同期問題に焦点を当てたアップリンクバースト伝送において交換されるメッセージおよび実行される処理の図を図示する。

【0020】

【図4】本明細書に提示される実施形態に応じたＵＥ、アクセスノード、およびＣＮにおける例示的なプロトコルスタックを図示する。

【0021】

【図5】本明細書に提示される実施形態に応じた伝送デバイスで実行される例示的な動作のフロー図を図示する。

【0022】

【図6】本明細書に提示される実施形態に応じた受信デバイスで実行される例示的な動作のフロー図を図示する。

【0023】

【図7】本明細書に提示される実施形態に応じた、交換されるＲＬＣ ＰＤＵが状態情報の維持を容易にするための追加情報を含むバースト伝送において交換されるメッセージおよび実行される処理の図を図示する。

【0024】

【図8】本明細書に提示される実施形態に応じた、交換されるＲＬＣ ＰＤＵが状態情報の維持を容易にするための追加情報を含み、エラー状態の例示的なハンドリングに焦点を当てたバースト伝送において交換されるメッセージおよび実行される処理の図を図示する。

【0025】

【図9】本明細書に提示される実施形態に応じた、交換されるＲＬＣ ＰＤＵが状態情報の維持を容易にするための追加情報を含み、再伝送に対応するべく時間を延長してその間受信デバイスがＲＬＣリソースを維持することに焦点を当てたバースト伝送において交換されるメッセージおよび実行される処理の図を図示する。

【0026】

【図10】本明細書に提示される実施形態に応じた、長いバースト伝送に焦点を当てたアップリンクバースト伝送における例示的なデータフローの詳細図を図示する。

【0027】

【図11】本明細書で説明する方法を実行するための処理システムの実施形態のブロック図を図示する。

【0028】

【図12】本明細書に提示される実施形態に応じた、遠隔通信ネットワークを介してシグナリングを伝送および受信するように適合されている送受信機のブロック図を図示する。

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

【0029】

本実施形態例の作成および使用は、以下で詳細に説明される。しかしながら、本開示は、さまざまな具体的状況において具現化され得る多くの適用可能な発明の概念を提供するものであることを理解すべきである。説明される具体的な実施形態は、単に実施形態を作成および使用するための具体的な方法を説明するものであり、本開示の範囲を制限するものではない。

【0030】

図１は、例示的な通信システム１００を図示する。通信システム１００は、ＮｏｄｅＢ、ｅＮＢ、基地局、コントローラ、アクセスポイント、ｇＮｏｄｅ Ｂ (ｇＮＢ)などのアクセスノード１０５を含む。セルラ動作モードにおいて、アクセスノード１０５は、ＵＥ１１０、ＵＥ１１２、およびＵＥ１１４などのＵＥとの間の通信を、ネットワークリソースを通信に許可することによって、制御する。ＵＥは、また一般的に、局、移動局、モバイル、ユーザ、加入者、端末などと称され得る。直接動作モードにおいて、ＵＥ同士は、中継としてアクセスノード１０５を挟むことなく互いに直接通信することができる。一例として、ＵＥは、アクセスノード１０５との間で送受信を行うことなく他のＵＥと通信することができる。ＵＥは、また一般的に移動局、モバイル、加入者、端末、ユーザ、局などと称され得る。多くのＵＥと通信することが可能な多重アクセスノードを通信システムは採用し得ると理解されたいが、図示を簡略化するべく図示しているのは１つのアクセスノードおよび５つのＵＥのみである。

【0031】

ＵＥとアクセスノードとの間の通常のアップリンクバースト伝送において、短縮された手順、またはランダムアクセス手順が存在する。ランダムアクセス手順は、実行される場合、アップリンクタイミングを取得するため、またはＵＥを識別するために用いられてよい。ランダムアクセス手順はまた、必要であれば、ＭＭＥを選択する場合など、ユーザデータのルーティングを確立するために用いられ得る。概して、ＵＥは、１つのインターネットプロトコル（ＩＰ）パケットとほぼ同様の少量のデータを伝送する。当該データは、ＮＡＳセキュリティコンテキストで暗号化される。伝送は、レイヤ２の構成に応じて、１つまたはいくつかの無線リンク制御（ＲＬＣ）プロトコルデータユニット（ＰＤＵ）に対応し得る。伝送が完了した後、ＡＳコンテキストは維持されず、ＵＥはアイドル状態に戻る。バースト伝送は一般的に、ショート伝送とも称される。

【0032】

例示的な実施形態の説明を容易にすべく、以下のように仮定される。
ＵＥ−アクセスノード間のリンクは、レイヤ２のＡＲＱメカニズムの何らかの形態を利用し、何らかのＲＬＣコンテキストが存在するので、伝送が真にコネクションレス型ではないことを示唆する。伝送は、準コネクションレス型であるとして特徴付けられてよい。
ＵＥ−コアネットワーク（ＣＮ）間のリンクは、例えば、暗号同期などのカウンタベースメカニズムを用いて、セキュリティを担当する。
コネクション設定、構成、またはリリースメッセージングなどの明示的なコネクション維持のシグナリングは、実行されない。
アクセスノードは、バーストの最終ＰＤＵを認識することができる。

【0033】

３ＧＰＰ ＬＴＥ技術規格において規定されたＲＬＣ手順が用いられた場合、バースト伝送の大多数が機能することとなる。しかしながら、同期外れ状態が、バーストの最終ＰＤＵにおいて発生する場合がある。本問題は、最終ＰＤＵのための確認応答（ＡＣＫ）が失われた場合に生じ、図２に示される。図２は、ＵＥ２０５とアクセスノード２１０との間のアップリンクバースト伝送において交換されるメッセージおよび実行される処理のダイアグラム２００を図示する。ＵＥ２０５は、ＰＤＵ１（イベント２１５）およびＰＤＵ２（イベント２１７）をアクセスノード２１０に送信する。ＵＥ２０５はまた、ポーリング指示を送信し、確認応答を要求する（イベント２１９）。ポーリング指示は、図２では別個のイベントとして示されるが、実際には、例えば、ＰＤＵ２のヘッダにおいてポーリングフラグを設定することによって、単一のメッセージにおいて他のイベントと組み合わせてよいことを理解すべきである。アクセスノード２１０は、ＲＬＣ ＳＴＡＴＵＳ ＰＤＵなどの、ＰＤＵ１およびＰＤＵ２のための確認応答を送信する（イベント２２１）。ＵＥ２０５はＰＤＵ３を送信する。ＰＤＵ３は、バースト伝送の最終ＰＤＵとなる（イベント２２３）。ＵＥ２０５はまた、ポーリング指示および「ＥＮＤ ＢＵＲＳＴ」指示を送信する（イベント２２５）。アクセスノード２１０は、ＰＤＵ３のための確認応答を送信する（イベント２２７）。しかしながら、ＰＤＵ３のための確認応答が失われる。従って、ＵＥ２０５は、ＰＤＵ３のための確認応答を受信することはない（ブロック２２９）。しかしながら、アクセスノード２１０は、ＵＥ２０５がＰＤＵ３のための確認応答の受信に成功したと仮定し、存在する場合、バースト伝送に関連付けられたＲＬＣ状態をリリースする（ブロック２３１）。ＵＥ２０５は、アクセスノード２１０がＰＤＵ３を受信しなかったと想定して、ＰＤＵ３を再送信する（イベント２３３）。アクセスノード２１０は、再送信されたＰＤＵ３を受信するが、バースト伝送に関連付けられたＲＬＣ状態が既にリリースされたので、再送信されたＰＤＵ３を新たなバースト伝送と解釈する（ブロック２３５）。従って、ＵＥ２０５とアクセスノード２１０との間で同期外れ状態が生じる。通信を行うデバイスの役割を逆転させるだけで、同じ状況がダウンリンク伝送においても生じ得ることに留意されたい。

【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】

送受信機１２００は、任意の種類の通信媒体を介して、シグナリングを伝送および受信してよい。いくつかの実施形態において、送受信機１２００は、無線媒体を介して、シグナリングを伝送および受信する。例えば、送受信機１２００は、セルラプロトコル（例えば、ロングタームエボリューション（ＬＴＥ）など）、無線ローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、Ｗｉ−Ｆｉ（登録商標）など）、または任意の他の種類の無線プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）など）などの無線遠隔通信プロトコルに従って通信を行うよう適合されている無線送受信機であってよい。そのような実施形態において、ネットワーク側インタフェース１２０２は、１つまたは複数のアンテナ／放射要素を含む。例えば、ネットワーク側インタフェース１２０２は、単一のアンテナ、複数の別個のアンテナ、または、例えば、単入力多出力（ＳＩＭＯ）、多入力単出力（ＭＩＳＯ）、多入力多出力（ＭＩＭＯ）などの多層通信のために構成されるマルチアンテナアレイを含んでよい。他の実施形態において、送受信機１２００は、例えば、ツイストペアケーブル、同軸ケーブル、光ファイバなどの有線媒体を介して、シグナリングを伝送および受信する。具体的な処理システムおよび／または送受信機は、図示されるコンポーネントのすべて、またはコンポーネントのサブセットのみを利用してよく、統合のレベルがデバイス毎に異なるとしてよい。本開示およびその利点を詳細に説明してきたが、添付の特許請求の範囲によって定義される本開示の趣旨および範囲から逸脱することなく、さまざまな変更、置換、および改変が本明細書において可能であってよいことを理解すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】