特許 6100780 モバイル通信システム、インフラストラクチャ機器、モバイル通信端末、およびユーザデータをアップリンクランダムアクセスチャネル内で通信する方法

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

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

(11)【特許番号】6100780

(24)【登録日】2017年3月3日

(45)【発行日】2017年3月22日

(54)【発明の名称】モバイル通信システム、インフラストラクチャ機器、モバイル通信端末、およびユーザデータをアップリンクランダムアクセスチャネル内で通信する方法

(51)【国際特許分類】

   H04W 4/20 20090101AFI20170313BHJP

   H04W 8/22 20090101ALI20170313BHJP

   H04W 74/08 20090101ALI20170313BHJP

【ＦＩ】

   H04W4/20

   H04W8/22

   H04W74/08

【請求項の数】16

【全頁数】19

(21)【出願番号】特願2014-526543(P2014-526543)

(86)(22)【出願日】2012年8月10日

(65)【公表番号】特表2014-529235(P2014-529235A)

(43)【公表日】2014年10月30日

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

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

(87)【国際公開日】20130228

【審査請求日】2015年6月8日

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

(32)【優先日】2011年8月19日

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

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

(32)【優先日】2011年8月19日

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

(73)【特許権者】

【識別番号】513018028

【氏名又は名称】エスシーエー アイピーエルエー ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】100095957

【弁理士】

【氏名又は名称】亀谷 美明

(74)【代理人】

【識別番号】100096389

【弁理士】

【氏名又は名称】金本 哲男

(74)【代理人】

【識別番号】100101557

【弁理士】

【氏名又は名称】萩原 康司

(74)【代理人】

【識別番号】100128587

【弁理士】

【氏名又は名称】松本 一騎

(72)【発明者】

【氏名】モリオカ ユウイチ

【審査官】 石田 昌敏

(56)【参考文献】

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

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

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

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

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

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

モバイル通信ネットワークの１以上の基地局によって提供される無線インターフェースを介して通信するように構成されているモバイル通信端末であって、前記通信することは、
ランダムアクセスメッセージを前記１以上の基地局に送信するために、前記無線インターフェースのアップリンクランダムアクセスチャネルを使用することを含み、
前記アップリンクランダムアクセスチャネルは、モバイル通信端末が前記アップリンクランダムアクセスチャネルを介してランダムアクセスメッセージを伝送するためのランダムアクセスリソースのブロックのセットを提供し、
前記モバイル通信端末は、複数のビットで表現されるユーザデータを取得し、前記ランダムアクセスリソースのブロックのセットから前記ユーザデータに対応するブロックを選択し、選択したブロックにおいて前記ランダムアクセスメッセージを送信し、
前記モバイル通信端末により取得される少なくともいずれかのユーザデータは、前記ランダムアクセスリソースのブロックのセットのうちの複数のブロックに対応し、
前記ランダムアクセスメッセージの各々は、ランダムアクセスコンポーネントを含み、前記ランダムアクセスコンポーネントは、前記モバイル通信端末に対する応答を認識する際に、前記モバイル通信端末によって、前記ランダムアクセスメッセージの各々に対して使用され、前記ランダムアクセスメッセージの各々は、前記モバイル通信端末が、前記応答は前記ランダムアクセスメッセージの各々に対することを識別するために送信しており、
前記モバイル通信端末は、前記ランダムアクセスメッセージのうちの１以上の少なくとも１つに対して、前記ユーザデータの少なくとも一部を表すために、前記ランダムアクセスコンポーネントを選択するように構成される、モバイル通信端末。

【請求項2】

前記モバイル通信端末は、ケイパビリティメッセージを前記１以上の基地局へ伝送するように構成され、前記ケイパビリティメッセージは、前記アップリンクランダムアクセスチャネルを介してユーザデータを伝送する前記モバイル通信端末のケイパビリティの表示を含む、請求項１に記載のモバイル通信端末。

【請求項3】

前記ケイパビリティの表示は、サブフレームタイミング選択方法を使用するケイパビリティと、ランダムアクセスリソースのブロックのタイミング選択を使用するケイパビリティと、ランダムアクセスリソースのブロックのタイミング内のタイミング選択を使用するケイパビリティと、のうちの少なくとも１つであり、前記ケイパビリティメッセージは、前記ケイパビリティが、静的または動的であることを任意で示し、前記ケイパビリティに対する時間期間を任意で含む、請求項２に記載のモバイル通信端末。

【請求項4】

前記モバイル通信端末は、ユーザデータが、前記ランダムアクセスメッセージを介して通信されていることを示すために、標識を前記ランダムアクセスメッセージに含むように構成される、請求項１〜３のいずれか１項に記載のモバイル通信端末。

【請求項5】

前記モバイル通信端末は、前記ランダムアクセスメッセージを、前記アップリンクランダムアクセスチャネルを介するユーザデータ通信に関連付けられるランダムアクセスリソースで伝送するように構成され、前記ブロックは、任意で前記アップリンクランダムアクセスチャネルを介するユーザデータ通信専用にされる、請求項１〜４のいずれか１項に記載のモバイル通信端末。

【請求項6】

前記モバイル通信端末は、タイミングアドバンス情報を前記１以上の基地局から受信し、前記タイミングアドバンス情報および前記選択された送信の時刻に従った初期化の後、前記ランダムアクセスメッセージの送信タイミングのタイミングを適合するように構成され、その後、前記タイミングアドバンス情報が変化しないと想定する、請求項１〜５のいずれか１項に記載のモバイル通信端末。

【請求項7】

前記モバイル通信ネットワークは、３ＧＰＰ準拠システムを含む、請求項１〜６のいずれか１項に記載のモバイル通信端末。

【請求項8】

前記モバイル通信ネットワークは、ＬＴＥ準拠システムを含み、前記１以上の基地局は、少なくとも１つのｅ−ＮｏｄｅＢを含む、請求項７に記載のモバイル通信端末。

【請求項9】

前記アップリンクランダムアクセスチャネルは、ＲＡＣＨである、請求項８に記載のモバイル通信端末。

【請求項10】

モバイル通信デバイスを用いて通信する方法であって、前記方法は、
モバイル通信ネットワークの１以上の基地局と通信することを含み、前記１以上の基地局は、モバイル通信端末と通信するための無線インターフェースを提供するように構成され、前記通信することは、
ランダムアクセスメッセージを前記１以上の基地局へ送信するために、前記無線インターフェースのアップリンクランダムアクセスチャネルを使用することを含み、
前記アップリンクランダムアクセスチャネルは、モバイル通信端末が前記アップリンクランダムアクセスチャネルを介してランダムアクセスメッセージを伝送するためのランダムアクセスリソースのブロックのセットを提供し、
前記モバイル通信端末は、複数のビットで表現されるユーザデータを取得し、前記ランダムアクセスリソースのブロックのセットから前記ユーザデータに対応するブロックを選択し、選択したブロックにおいて前記ランダムアクセスメッセージを送信し、
前記モバイル通信端末により取得される少なくともいずれかのユーザデータは、前記ランダムアクセスリソースのブロックのセットのうちの複数のブロックに対応し、
前記ランダムアクセスメッセージの各々は、ランダムアクセスコンポーネントを含み、前記ランダムアクセスコンポーネントは、前記モバイル通信端末に対する応答を認識する際に、前記モバイル通信端末によって、前記ランダムアクセスメッセージの各々に対して使用され、前記ランダムアクセスメッセージの各々は、前記モバイル通信端末が、前記応答は前記ランダムアクセスメッセージの各々に対することを識別するために送信しており、前記方法は、
前記ランダムアクセスメッセージのうちの１以上の少なくとも１つに対して、前記ユーザデータの少なくとも一部を表すために、前記ランダムアクセスコンポーネントを選択することを含む、通信する方法。

【請求項11】

前記方法は、ケイパビリティメッセージを前記モバイル通信端末から前記１以上の基地局へ伝送することを含み、前記ケイパビリティメッセージは、前記アップリンクランダムアクセスチャネルを介してユーザデータを伝送する前記モバイル通信端末のケイパビリティの表示を含む、請求項１０に記載の通信する方法。

【請求項12】

前記ケイパビリティの表示は、サブフレームタイミング選択方法を使用するケイパビリティと、ランダムアクセスリソースのブロックのタイミング選択を使用するケイパビリティと、ランダムアクセスリソースのブロックのタイミング内のタイミング選択を使用するケイパビリティと、のうちの少なくとも１つであり、前記ケイパビリティメッセージは、前記ケイパビリティが、静的または動的であることを任意で示し、前記ケイパビリティに対する時間期間を任意で含む、請求項１１に記載の通信する方法。

【請求項13】

前記方法は、標識を前記モバイル通信端末による前記ランダムアクセスメッセージに含むことを含み、前記ランダムアクセスメッセージは、ユーザデータが前記ランダムアクセスメッセージを介して通信されていることを示す、請求項１０または１２に記載の通信する方法。

【請求項14】

前記モバイル通信ネットワークは、３ＧＰＰ準拠ネットワークである、請求項１０〜１３のいずれか１項に記載の通信する方法。

【請求項15】

前記１以上の基地局は、少なくとも１つのｅ−ＮｏｄｅＢを含む、請求項１４に記載の通信する方法。

【請求項16】

前記アップリンクランダムアクセスチャネルは、ＲＡＣＨである、請求項１５に記載のデータを通信する方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを通信端末へ／から通信するモバイル通信システムおよび通信する方法に関する。

【背景技術】

【0002】

３ＧＰＰ定義のＵＭＴＳおよびＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）アーキテクチャに基づくシステムのような第３および第４世代モバイル通信システムは、前世代のモバイル通信システムによって提供される単なる音声サービスやメッセージングサービスよりも高度なサービスをサポートし得る。例えば、ＬＴＥシステムによって提供される改善された無線インターフェースおよび改良されたデータレートによって、ユーザは、以前は固定回線のデータ接続を介してのみ利用可能であったモバイルビデオストリーミングおよびモバイルビデオ会議といった高いデータレートのアプリケーションを享受可能である。そのため、第３および第４世代ネットワーク展開への要望は強く、これらのネットワークのカバレッジエリア、つまり、ネットワークへのアクセスが可能な全ての地理的な場所は急速に増加することが予想される。

【0003】

第３および第４世代ネットワークの予想される広域展開は、ＬＴＥ無線インターフェースを介して利用可能な高いデータレートを要求せず、代わりにロバストな無線インターフェースを利用するクラスのより単純な端末およびアプリケーションの並行開発をもたらし、カバレッジエリアの偏在性の増強に寄与する。例として、少量のデータを相対的に低い頻度で通信する準自律的または自律的なワイヤレス通信端末（つまり、ＭＴＣ端末）に代表されるような、いわゆるマシンタイプコミュニケーション（ＭＴＣ）のアプリケーションが含まれる。したがって、ＭＴＣ端末の使用は、従来のＬＴＥ端末のための従来の「ａｌｗａｙｓ−ｏｎ」の使用の場合とは異なり得る。ＭＴＣ端末の例として、いわゆるスマートメータ、例えば、消費者の家に配置され、中央ＭＴＣサーバデータに返る消費者のガス、水道、電気などの諸設備の使用量に関係する情報を定期的に送信するスマートメータが含まれる。スマートメータの例では、メータは、小データ送信の受信（例えば、新たな価格表）および小データ送信の伝送（例えば、新たな示度）を共に行い得るが、それらのデータ送信は、一般的には低頻度であり、遅延耐性のある送信である。ＭＴＣ端末の特徴としては、例えば、ｌｏｗ ｍｏｂｉｌｉｔｙ、ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｄ、ｔｉｍｅ ｔｏｌｅｒａｎｔ、ｐａｃｋｅｔ ｓｗｉｔｃｈｅｄ（ＰＳ） ｏｎｌｙ、ｓｍａｌｌ ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎｓ、ｍｏｂｉｌｅ ｏｒｉｇｉｎａｔｅｄ ｏｎｌｙ、ｉｎｆｒｅｑｕｅｎｔ ｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｅｄ、ＭＴＣ ｍｏｎｉｔｏｒｉｎｇ、ｐｒｉｏｒｉｔｙ ａｌａｒｍ、ｓｅｃｕｒｅ ｃｏｎｎｅｃｔｉｏｎ、ｌｏｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｔｒｉｇｇｅｒ、ｎｅｔｗｏｒｋ ｐｒｏｖｉｄｅｄ ｄｅｓｔｉｎａｔｉｏｎ ｆｏｒ ｕｐｌｉｎｋ ｄａｔａ、ｉｎｆｒｅｑｕｅｎｔ ｔｒａｎｓｍｉｓｓｉｏｎ、およびｇｒｏｕｐ ｂａｓｅｄ ＭＴＣ ｆｅａｔｕｒｅｓ（例えば、ｇｒｏｕｐ ｂａｓｅｄ ｐｏｌｉｃｉｎｇおよびｇｒｏｕｐ ｂａｓｅｄ ａｄｄｒｅｓｓｉｎｇ）のうちの１以上が含まれ得る。ＭＴＣ端末の他の例として、自動販売機、「サトナブ」端末、および防犯カメラまたは防犯センサなどが含まれ得る。

【0004】

近年開発されたモバイルネットワークは、一般的に、高レートであり、かつ高い信頼性を有するサービスによく適合されており、必ずしもＭＴＣサービスに十分には適合していない場合がある。

【発明の概要】

【0005】

発明の態様によれば、モバイル通信端末が提供され、前記モバイル通信端末は、モバイル通信ネットワークの１以上の基地局によって提供される無線インターフェースを介して通信するように構成される。前記モバイル通信端末は、ランダムアクセスメッセージを前記１以上の基地局へ送信するために、前記無線インターフェースのアップリンクランダムアクセスチャネルを使用することによって、前記無線インターフェースを介して前記１以上の基地局と通信するように構成される。前記モバイル通信端末は、前記ランダムアクセスメッセージの１以上を前記アップリンクランダムアクセスチャネル内の選択されたタイミングで送信することによって、前記アップリンクランダムアクセスチャネルを介してユーザデータを通信するように構成され、前記タイミングは、前記ユーザデータの少なくとも一部を表すために、前記第１のモバイル通信端末によって選択される。そのため、モバイル通信端末が提供され得、前記モバイル通信端末は、ランダムアクセスチャネルにおけるランダムアクセスメッセージの送信のタイミングを選択することによって、ユーザデータを前記ランダムアクセスチャネルで送信し得、それによって、前記端末は、予め定義された規格に従う、従来は他の所定の情報を通信するための、例えば、アップリンクリソースの要求などの前記ランダムアクセスメッセージに加えて、アップリンクランダムアクセスチャネルでデータを通信可能となる。

【0006】

本発明の実施形態によって対処される技術的な問題は、例えば、ＭＴＣ通信に対して使用されるような小メッセージを送信するために、モバイル通信ネットワークを用いてデータを通信する効率を改善することである。これは、例えば、ＬＴＥなどのモバイル通信ネットワークが、相当な量のユーザデータを通信するためのアップリンクリソースを要求するランダムアクセスメッセージを送信するために、ランダムアクセスチャネルを含むように設計されているためである。典型的には、前記ランダムアクセスメッセージは、前記アップリンクリソースを要求するために予め定義されるフォーマットを有する。理解されるように、これは一例である。しかし、例えば、前記モバイル端末が、ＭＴＣ通信デバイスの一部を形成するような一部の使用例に関しては、少量のデータのみが伝送されることを要求される。したがって、本発明の実施形態は、前記ランダムアクセスチャネル内のランダムアクセスメッセージの送信のタイミングを選択することによって、データを通信するように構成される。前記ランダムアクセスメッセージ自体は、例えば、前記モバイル端末および／または前記モバイル端末のアップリンクリソースに関する要求を識別するためなどの異なる目的のためにデータを通信する予め定義されたフォーマットを有し得る。

【0007】

一例では、ユーザデータは、前記ランダムアクセスチャネル内の前記ランダムアクセスメッセージの相対的な時間的位置を変更することによって表され得る。別の例では、前記ランダムアクセスメッセージは、無線アクセスインターフェースの一部のサブフレームの前記無線アクセスチャネルで通信され得るが、その他では通信されない場合がある。例えば、前記サブフレームは、対にされ得、前記ランダムアクセスメッセージは、２進数の「１」または「０」を表すために、前記対のサブフレームの第１のサブフレームまたは第２のサブフレームで送信され得る。さらに、他の例では、前記ランダムアクセスチャネルの一部を形成するランダムアクセス時間および周波数リソースのブロックは、前記ユーザデータの少なくとも一部を通信するために、ランダムアクセス時間および周波数リソースのブロックの利用可能なセットから選択され得る。以下の節では、異なる例示的な技術を提供するが、それらは本技術の態様および特徴を形成する。

【0008】

一部の例では、前記通信端末は、前記ランダムアクセスチャネルにおける前記ランダムアクセスメッセージの送信のタイミングを調節するために使用されるタイミングアドバンス情報を、前記ユーザデータを表すために前記送信のタイミングが選択され得る前に定期的に受信する。この例は、モバイル端末である通信端末に対応し得る。しかし、特にＭＴＣ端末のようなより単純な通信デバイスに対応する他の例では、タイミングアドバンス情報は、例えば、電源を入れられた際に一度またはデバイスリセットの際に一度というように、より低頻度で前記通信デバイスに通信され得る。前記タイミングアドバンス情報が前記基地局から受信されると、前記通信デバイスは、リセット状態または電源が切られるまでタイミングアドバンスは正しいと想定する。したがって、例えば、パーキングメータなどの実質的に静的な使用例で展開されることが知られるＭＴＣデバイスにより単純化された構成が提供される。

【0009】

本発明のさらなる様々な態様および特徴は、添付の特許請求の範囲で定義され、基地局、通信端末、モバイル通信ネットワーク、および通信する方法などのインフラストラクチャ機器を含む。

【図面の簡単な説明】

【0010】

ここで、本発明の例示的な実施形態が、添付の図面を参照して説明される。同様部分は、同一の指定の参照番号を有する。

【図1】ＬＴＥ標準に従うモバイル通信ネットワークの概略的なブロック図である。

【図2】ＭＴＣデバイスおよびサービスに適したモバイルネットワークの例を示す。

【図3】端末がｅ−ＮｏｄｅＢに接続し、データをアップリンクで伝送するための方法の例示である。

【図4】ＬＴＥネットワーク内のアップリンクリソースを要求し、そのアップリンクリソースを使用する端末のための従来のメッセージ交換の例示である。

【図5】図４の方法での使用に適した従来のアップリンクフレームの例示である。

【図6】アップリンクランダムアクセスチャネルを用いて、データを伝送する方法の例である。

【図7】図６の方法での使用に適したアップリンクフレームの例である。

【図8】アップリンクランダムアクセスチャネルおよびプリアンブルの位置付けを用いて、データを伝送する方法の例である。

【図9】図８の方法での使用に適したアップリンクフレームの例である。

【図10】図８の方法での使用に適したアップリンクフレームの例である。

【図11】ランダムアクセスチャネルで送信されるデータを符号化するためのプリアンブル選択の例である。

【図12】ランダムアクセスチャネルで送信されるデータを符号化するためのプリアンブル選択の例である。

【図13】ランダムアクセスチャネルで送信されるデータを符号化するためのプリアンブル選択の例である。

【図14】端末が、アップリンクランダムアクセスチャネルを用いて、データを伝送していることを検出する方法の例である。

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

【0011】

本願は、２０１１年８月１９日に出願された英国特許出願第１１１４３３９．３号、および２０１１年８月１９日出願された英国特許出願第１１１４３４０．１号のパリ条約による優先権の主張の利益を享受し、これらの内容は参照されることにより本書に組み込まれる。

【0012】

本技術の例示的な実施形態が、３ＧＰＰ ＬＴＥアーキテクチャとの関連で概略的に説明される。しかし、発明は３ＧＰＰ ＬＴＥアーキテクチャでの実装に限定されない。逆に、いずれの適切なモバイルアーキテクチャも関連していることが想定される。例えば、説明が「ｅＮＢ」または「ｅ−ＮｏｄｅＢ」に言及する場合、ｅＮＢは、例示的な目的のために例として使用され、本技術が、その他のタイプの基地局（例えば、ＧＳＭにおけるＢＴＳ）と共にどのように使用され得るかということは、当業者に明らかであろう。

【0013】

＜従来のネットワーク＞
図１は、従来のＬＴＥモバイル通信ネットワークの基本的な機能性を示す概略的な図を提供する。ネットワークは、ユーザプレーンにおけるトラフィックのためのサービングゲートウェイ（Ｓ−ＧＷ）１０３および制御プレーンにおけるシグナリングのための移動性管理エンティティ（ＭＭＥ）に接続されている１以上の基地局１０２（基地局は１つ表されている）を含む。ＬＴＥでは、基地局は、ｅ−ＮｏｄｅＢと呼ばれ、以下の説明ではｅＮＢと呼ぶ。各基地局は、カバレッジエリア１０３を提供し、カバレッジエリア１０３内において、データがモバイル端末１０１（またはＵＥ）へ、およびモバイル端末１０１（またはＵＥ）から通信され得る。データは、無線ダウンリンク（ＤＬ）を介して、基地局１０２からカバレッジエリア内のモバイル端末１０１へ送信される。データは、無線アップリンク（ＵＬ）を介して、モバイル端末１０１から基地局１０２へ送信される。ＭＭＥ１０５、Ｓ−ＧＷ１０３、およびＰＤＮゲートウェイ（Ｐ−ＧＷ）１０４を含むコアネットワークは、データをモバイル端末１０１へ、およびモバイル端末１０１からルーティングし、認証、移動性管理、課金などの機能を提供する。Ｐ−ＧＷは、例えば、インターネット、ＩＭＳコアネットワークなどを含み得る１以上の他のネットワークに接続される。図１の例示では、ユーザプレーンでの接続は、実線で表されているが、制御プレーンでの接続は、破線で表されている。

【0014】

図２の例示では、モバイルネットワークは、ＩＰネットワーク（例えば、インターネット）を介したＭＴＣアプリケーションサーバ１２０へのアクセスも提供する。別の例では、ＭＴＣアプリケーションサーバ１２０は、モバイルネットワーク内に配置され得る。モバイル端末１０１のうちの１以上は、例えば、自動販売機またはスマートメータのようなＭＴＣデバイスを形成し得、データを受信し得るか、かつ／またはデータをＭＴＣアプリケーションサーバ１２０に伝送し得る。

【0015】

以下の説明は、モバイル端末がモバイルネットワークに接続し、データを１以上のｅＮＢ１０２へ伝送（つまり、アップリンクで）することを所望する従来の動作の例の概略的な説明を図３〜図５を参照して提供する。これは、本技術のいくつかの態様および利点を認識する助けとなる。

【0016】

図３は、端末がｅＮＢに接続し、データをアップリンクで伝送するための方法の例示である。方法のステップ４００の開始では、モバイル端末（ＵＥとも呼ばれる）であっても、モバイル端末でなくともよい通信端末は、例えば、オンに切り替えられ得るか、ｅＮＢのカバレッジエリアに入り得るか、または既にネットワークに接続されて、新たなｅＮＢにハンドオーバし得る。いずれの場合でも、ステップ４０２で、端末は、例えばｅＮＢによって定期的に伝送されるＰＳＳ、ＳＳＳ、およびＰＢＣＨ信号を用いて、ｅＮＢに同期する。端末は、ｅＮＢに同期されると、アップリンクデータをｅＮＢへ伝送できるように、アップリンクリソースを要求しなければならない。ステップ４０２では、端末は、リソース要求をｅＮＢへＲＡＣＨメッセージで伝送する。ＲＡＣＨは、「ランダムアクセスチャネル」を意味し、ＬＴＥでは、自身に割り当てられているアップリンクリソースを有しておらず、そのリソースに関して割当てを所望する端末に対して使用される。ＬＴＥでは、端末は、メッセージをＲＡＣＨチャネルで特定の時刻および周波数で伝送する。メッセージは、プリアンブル（６４の可能性の中から選ばれた数）を含む。ステップ４０３では、ｅＮＢは、端末からＲＡＣＨメッセージを受信すると、ＰＤＣＣＨおよびＰＤＳＣＨを介して伝送されるメッセージによって端末に応答し、メッセージは、いくつかのパラメータを含む。それらのパラメータは、以下を含み得る。
・ＲＡ−ＲＮＴＩ：ＲＡ−ＲＮＴＩは、ランダムアクセスプリアンブルと、ＲＡＣＨメッセージが伝送された時刻および周波数との組合せに基づく。これは、同一のプリアンブルを有する２つのＲＡＣＨメッセージを伝送し得た２つの端末を区別するためである。ＲＡ−ＲＮＴＩは、端末に対する識別子として使用されることによって、端末は、受信する応答が、別の端末への応答ではなく、先に伝送された端末のＲＡＣＨメッセージに対する応答であることを検出し得る。応答のＣＲＣは、ＲＡ−ＲＮＴＩによってスクランブルされる。
・ランダムアクセスプリアンブル：この応答メッセージが関わるプリアンブルは、端末がＲＡＣＨメッセージで使用したプリアンブルであることを端末がチェックし得るためのものである。
・一時的なＣ−ＲＮＴＩ：少なくとも将来のダウンリンク通信で使用される、端末に対する一次的な識別子である。
・タイミングアドバンス：ｅＮＢは、ｅＮＢがサービスを提供するセル内の推定された位置からの端末の送信信号がｅＮＢに到着する遅延量を推定し、端末に、ＵＬ送信信号をｅＮＢに到着する他の全てのＵＬ送信信号と一致させるために、どの程度メッセージをシフトすべきかという表示を付与する。
・ＵＬリソース許可：ｅＮＢは、端末がＵＬデータを伝送するために割り当てられているＵＬリソースを端末に通知する。

【0017】

次いで、ステップ４０４では、端末は、ＵＬデータを伝送するために割り当てられたＵＬリソースを使用する。データが伝送されると、端末およびｅＮＢは、伝送すべきデータをもはや有していないと想定され、端末およびｅＮＢは、方法が終了（ステップ４０６）する前に、ステップ４０５で、割り当てられているＵＬ（およびＤＬもあり得る）リソースを解放し得る。

【0018】

図４は、図３の方法に対応する、単純化した、可能性のある呼フローを示す。図４は、特に、ステップ４０２〜４０５に対応するメッセージを示す。まず、端末１０１は、リソースを要求するためにＲＡＣＨメッセージをｅＮＢ１０２へ伝送し、ＵＬリソース割当てを含む応答４２を受信する。次いで、端末は、ＵＬリソースを用いて、データをアップリンク（メッセージ４３）で伝送する。図４の例では、ＵＬデータメッセージ４３が成功裏に受信されたことを確認する確認（「ａｃｋ」）メッセージ４４がメッセージ４３に続く。端末１０１によって伝送されるデータの量に応じて、より多くのメッセージ４３（および任意でａｃｋメッセージ４４）が続いてもよい。ＵＬリソースがもはや要求されなくなると、端末１０１またはｅＮＢ１０２は、それらＵＬリソースの解放をメッセージ４５でトリガし得る。

【0019】

図５は、図３の方法での使用および／または図４の呼フローでの使用に適した従来のアップリンクフレーム２０の例示である。ＬＴＥでは、フレーム２０は、概して１０のサブフレーム２１に分割され、図５では、０〜９の番号が付されている。図５の例では、ＲＡＣＨ２２は、端末がフレームの全てのサブフレームでＲＡＣＨメッセージを伝送するために利用可能なリソースを有する。他の設定では、サブフレームの全てではなく、一部がＲＡＣＨチャネルに対して利用可能なリソースを有し得るか、一部のフレームが、ＲＡＣＨに割り当てられたいずれのリソースも有していない場合がある。例えば、ＲＡＣＨは、偶数フレームの第１のサブフレームにのみ提供されてもよい。従来のＲＡＣＨ方法および本技術は、ＲＡＣＨリソースをいずれのサブフレームにも有するフレームとの関連で提示される。しかし、発明は、その構成に限定されず、１以上のフレームがＲＡＣＨリソースを有していないサブフレームを含む構成に同一の原理が適用され得、一部のフレームがＲＡＣＨリソースも含まない構成にも任意で適用され得る。

【0020】

図５の例では、端末１０１が、第２のサブフレームに提供されたＲＡＣＨでＲＡＣＨメッセージを伝送したことを示すために、その第２のサブフレームのＲＡＣＨリソースが陰影を付されている。

【0021】

図３〜図５に示される従来のＲＡＣＨ手続きは、端末がアップリンクリソースを要求するための第１のステップである。一般的に、端末が、例えば、端末１０１とｅＮＢ１０２との間のＲＲＣ接続のような関連するアップリンクおよびダウンリンク接続をセットアップするためには、さらなるシグナリングが要求される。そのため、関係するシグナリングの量は、小メッセージのサイズに比較した場合、多くあり得る。端末１０１が大量のデータを伝送しなければならない場合、この従来の方法は、データ／シグナリング比が高くなるので、効率的であり得る。しかし、端末が伝送すべきデータをごく少量のみ有する場合、この方法は、データ／シグナリング比が低くなるので、非効率的であり得る。したがって、データの量が少なくなると、シグナリングの量は実質的に一定であるために効率は低くなる。ＭＴＣタイプのアプリケーションの場合、端末は、伝送すべきデータをごく少量のみ有する傾向があり、一般的に、そのデータは遅延に敏感なデータではない。さらに、ＭＴＣタイプのアプリケーションは、従来のモバイル端末に比較して、そのようなデバイスを製造するコストを低減するため、低減された機能性を要求する傾向がある。なぜならば、ＭＴＣデバイスは、従来のモバイル端末よりも普及し、実利を求めることが予測されるので、モバイル通信ネットワークを用いて、データを送受信するのに魅力的であるために、製造をより廉価にすべきことが予測されるからである。その結果、ＭＴＣタイプのサービスおよびアプリケーションに対して、単純化された端末を有することが望ましくあり得る。

【0022】

そのため、小メッセージ（または非常に小さいメッセージ）を送信および／またはＭＴＣ通信するネットワークの効率を改善する方法を提供することが望ましくあり得る。以下の節では、異なる例示的な技術を提供するが、それらは本技術の態様および特徴を形成する。

【0023】

＜ランダムアクセスチャネルを介したデータの送信および符号化＞
以上の説明から認識されるように、小メッセージ（または非常に小さいメッセージ）を送信および／またはＭＴＣ通信するモバイル通信ネットワークの効率を改善する方法を提供するという技術的な問題が提示される。以下の節では、異なる例示的な技術を提供するが、それらは本技術の態様および特徴を形成する。

【0024】

本技術によれば、端末は、少なくともタイミング選択を用いて、データをｅＮＢへ伝送するためにＲＡＣＨメッセージを使用する。タイミング選択は、例えば、ショートメッセージのデータのようなデータを符号化するために使用され得る。ランダムアクセスチャネルを介してデータを伝送する方法の例は、図６に示される。この例では、端末１０１は、ＭＴＣデバイスであり、端末１０１のデータを伝送するために、利用可能なＲＡＣＨメッセージを再使用する。方法が開始（６００）されると、端末１０１は、ステップ６０１で、例えば従来の様式でｅＮＢに同期する。次いで、端末１０１は、送信タイミングを用いて、少なくともデータの一部をステップ６０２で符号化するＲＡＣＨメッセージを伝送する。どのように符号化が行われ得るかに関する詳細は、以下にさらに提供される。この例では、端末１０１は、ステップ６０２で伝送されたＲＡＣＨメッセージに応じて、「ａｃｋ」メッセージを想定する。そのようなａｃｋメッセージは、例えば、ＲＡＣＨ応答メッセージまたはその他のタイプの適切なメッセージで搬送され得る。端末は、そのような確認をＲＡＣＨメッセージに応じて受信したか否かをステップ６０３で判定する。端末は、例えば、ＲＡＣＨメッセージの送信によってトリガされたタイマの満了の前にいずれの確認も受信していない場合、ステップ６０２に戻り、当該ＲＡＣＨメッセージを再伝送する。しかし、端末がＲＡＣＨメッセージに対して、ａｃｋメッセージを受信する場合、端末はステップ６０４に進み得る。図６の例は、確認メッセージが受信されたか否かをチェックすることを含むが、このステップ６０３は、任意である。別の例では、端末は、いずれのａｃｋメッセージも想定しない場合があり、ステップ６０２からステップ６０４へジャンプし得る。ステップ６０４では、端末１０１は、ＲＡＣＨを介して伝送すべきデータをさらに有しているか否かを判定する。端末が、伝送しなければならなかったデータを既に全て伝送している場合、方法は終了（ステップ６０５）し得る。しかし、端末１０１が、この様式で伝送すべきデータをまだ有している場合、端末１０１が未処理のデータを１以上のＲＡＣＨメッセージで伝送するために、方法はステップ６０２に戻る。

【0025】

データを符号化するために送信タイミングを使用することは、端末１０１が従来のＲＡＣＨメッセージに見え得るものを用いて、データを伝送することを可能にし、それによって、優れた上位互換性ケイパビリティを提供する。送信タイミングを用いた符号化の例は、図７に示される。図７は、０〜９の番号が付されている１０のサブフレームを含むフレーム２０を示す。各サブフレームは、（例えば従来の）ＲＡＣＨのために割り当てられたリソースを含む。この例では、端末は、ＲＡＣＨメッセージを送信するサブフレームを選択することによってデータを符号化し得る。例えば、２進コード化を用いて、ＲＡＣＨメッセージを偶数サブフレームで伝送することは、「０」を符号化するが、ＲＡＣＨメッセージを奇数サブフレームで伝送することは、「１」を符号化する。したがって、図７の例では、５ビットが１つのフレームで符号化され得、ＲＡＣＨメッセージをサブフレーム１、３、４、６、および９で伝送することによって、端末は、「１１００１」を符号化し得る。この例では、最初の３ビットは、ＩＤ（「１１０」＝６）を符号化し、最後の２ビットは、状態（「０１」＝バッテリ低下）を符号化する。例えば、スマートメータは、内部要素番号６（例えば、ガスメータまたは他の要素ではなく、電気メータ）がバッテリ低下していることを中央サーバに示し得る。

【0026】

ＲＡＣＨが全てのサブフレーム（示されていない）にではなく、一部のサブフレームにのみ提供される例では、端末は、ＲＡＣＨチャネルリソースのブロックの選択に関連する送信タイミングを用いてデータを符号化し得る。ＲＡＣＨリソースのブロックは、端末がＲＡＣＨメッセージを伝送するためにアップリンクに提供される時間および周波数スロットである。実質的に、ＲＡＣＨリソースのブロックの全てがＲＡＣＨを形成する。例えば、ＲＡＣＨが３サブフレームに１回提供される状況では、端末は、「０」または「１」を符号化するために、２つの異なるサブフレームにおける１対の後続するブロックのＲＡＣＨリソース内のＲＡＣＨメッセージの位置付けを使用し得る。別の例では、サブフレーム選択ではなく、ＲＡＣＨリソースのブロックの選択を基準に選択が行われ得る。例えば、２ブロックのＲＡＣＨリソースがサブフレームに提供される場合があり得る。その場合、端末は、「０」または「１」を符号化するように、サブフレーム内の第１のリソースブロックおよび第２のリソースブロックのうちの一方を選択し得る。その場合、２ブロックのＲＡＣＨリソースを含むサブフレームごとに、ビットが符号化され得る。

【0027】

別の例（示されていない）では、例えば、各フレームの第２のサブフレームに１ブロックのＲＡＣＨリソースといった、フレーム毎に１ブロックのみのＲＡＣＨリソースがあり得る。そして、サブフレーム選択がフレームよりも広い範囲にわたって行われ得る。例えば、サブフレーム選択は、１０フレームのグループにわたって行われ得、その場合、２進コード化に基づくサブフレーム選択は、１０フレームのグループで、５ビットの可能性のある符号化を可能にする。

【0028】

図８に示される方法では、端末１０１は、ランダムアクセスチャネルリソースのアップリンクブロックにおけるプリアンブルの位置付けを用いて、ＲＡＣＨを介してデータを伝送し得る。アップリンクランダムアクセスチャネルが、プリアンブル以外のメッセージを伝送するために使用されるような他の例では、データを符号化するために、このメッセージをブロックランダムアクセスリソース内に位置付けることによって、同一の原理が適用され得る。図８の例では、方法がステップ８００で開始され、端末１０１は、ステップ８０１でｅＮＢに同期する。次いで、端末１０１は、タイミングアドバンスを例えばｅＮＢから取得し、アップリンクタイミングに完全に一致し得るようにＲＡＣＨメッセージを使用する。次いで、ステップ８０３では、端末１０１は、ＲＡＣＨリソースのブロックにおけるプリアンブルの位置付けを用いて、ＲＡＣＨを介してデータを伝送する。この例は、確認メッセージが、ステップ８０３で伝送されたデータに対して受信されたか否かをチェックする任意のステップ８０４も含む。受信されていない場合、端末は、ステップ８０３に戻り、データを再伝送する。受信された場合、端末１０１がＲＡＣＨを介して伝送すべきデータをまだ有しているか否かを判定するステップ８０５に方法が進む。有していない場合、方法はステップ８０６で終了し得る。しかし、端末１０１が伝送すべきデータをまだ有している場合、端末１０１がタイミングアドバンスを再取得する必要があるか否かを判定するステップ８０７に方法は進む。例えば、端末１０１は、ｅＮＢ１０２に対して移動したか否かを判定し得る位置要素を有し得るので、新たなタイミングアドバンスを要求する。あるいは、端末１０１は、例えば、スマートメータまたはパーキングメータのような固定要素であり得、その場合、端末１０１が固定要素であることを知っているので、ステップ８０７は完全に省略され得る。現在のタイミングアドバンスが十分満足いくものであると判定される場合、方法は、ステップ８０３に戻り、ＲＡＣＨリソースにおけるプリアンブルの位置付けを用いて、さらなるデータを伝送し得る。しかし、新たなタイミングアドバンスが取得されることが判定される場合、端末１０１が新たなタイミングアドバンスを取得するステップ８０２へ方法は進む。

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

本発明のさらなる多様な態様および特徴は添付の特許請求の範囲において定義される。
本発明の範囲を逸脱せず、様々な修正が上記実施形態になされ得る。例えば、本発明の実施形態は、他のタイプのモバイル通信ネットワークを用いて使用され、ＬＴＥに限定されない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】