JP2015525041A - 二重優先度アクセスのための無線リソース管理 - Google Patents

二重優先度アクセスのための無線リソース管理 Download PDF

Info

Publication number
JP2015525041A
JP2015525041A JP2015524795A JP2015524795A JP2015525041A JP 2015525041 A JP2015525041 A JP 2015525041A JP 2015524795 A JP2015524795 A JP 2015524795A JP 2015524795 A JP2015524795 A JP 2015524795A JP 2015525041 A JP2015525041 A JP 2015525041A
Authority
JP
Japan
Prior art keywords
priority
terminal
base station
radio resource
indicator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2015524795A
Other languages
English (en)
Other versions
JP6211081B2 (ja
Inventor
プラティーク バス−マリック
プラティーク バス−マリック
ジェナディ ヴェルヴ
ジェナディ ヴェルヴ
尚志 田村
尚志 田村
ヨアヒム ロアー
ヨアヒム ロアー
マルティン フォイヤーサンゲル
マルティン フォイヤーサンゲル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2015525041A publication Critical patent/JP2015525041A/ja
Application granted granted Critical
Publication of JP6211081B2 publication Critical patent/JP6211081B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/52—Allocation or scheduling criteria for wireless resources based on load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release
    • H04W76/34—Selective release of ongoing connections
    • H04W76/36—Selective release of ongoing connections for reassigning the resources associated with the released connections

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本発明は、少なくとも基地局と端末を含む通信システムにおいて無線リソース管理タスクを実行することに関する。遅延耐性アプリケーションと通常アプリケーションを同時に動作させることができる、二重優先度デバイスに対する無線リソース管理タスクを実行する際の矛盾を回避するために、デバイス優先度が変更されるときに、端末またはコアネットワークのいずれかから基地局に変更が指示される。デバイス優先度は、デバイス毎の全体的優先度として、または、そのデバイスに対して構成されているベアラ毎の優先度として指示される。【選択図】図２

Description

本発明は、セルラ通信に関し、特に、アドミッション制御および輻輳制御の両方を含むネットワーク負荷制御の分野に関する。
第３世代パートナーシッププロジェクト（３ＧＰＰ）団体では、グローバル移動体通信システム（ＧＳＭ（登録商標））、およびユニバーサル移動体通信システム（ＵＭＴＳ）のようなモバイルセルラネットワークのアーキテクチャの仕様を定めている。ＵＭＴＳなどの、ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく、第３世代モバイルシステムが、世界中に大規模展開されている。この技術の高度化または発展の第一歩は、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および、高速アップリンクパケットアクセス（ＨＳＵＰＡ）とも称されるエンハンストアップリンクの導入であった。しかし、より長期的な観点では、利用者需要のさらなる増大に備え、新しい無線アクセスに対する競争力をつける必要がある。この難題に応えるために、３ＧＰＰは、発展型パケット・システム（ＥＰＳ）という名称でも知られている、発展型３ＧＰＰパケット交換ドメインに至るスタディ・アイテムの検討を開始した。ＥＰＳは、発展型ユニバーサル無線アクセス・ネットワーク（Ｅ−ＵＴＲＡＮ）と称される新世代のアクセスネットワーク技術、さらにはユニバーサル無線アクセスネットワーク（ＵＴＲＡＮ）と称されるＥ−ＵＴＲＡＮの１世代前の技術を接続することができる発展型パケットコア（ＥＰＣ）ネットワークを組み合わせたものである。Ｅ−ＵＴＲＡＮ（および同じ意味を持つ）に広く使用されている別の用語は、ロングタームエボリューション（ＬＴＥ）である。ＬＴＥは、高速データおよびメディアトランスポートさらには次の１０年に向けての大容量音声サポートに対する、加入者およびネットワーク通信事業者のニーズに応えるように設計されている。ＥＰＳのより詳細な説明は、参照により本明細書に組み込まれている、３ＧＰＰのウェブサイトを通じて無料で入手できる、非特許文献１に記載されている。
ネットワークエンティティ、およびこれらの間のインターフェースを含むＬＴＥネットワークアーキテクチャは、図１に例示されている。図１からわかるように、ＬＴＥアーキテクチャでは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）を介してＥＰＣに接続される、ＵＴＲＡＮまたはＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ無線アクセスネットワーク）などの異なる無線アクセスネットワーク同士の相互接続をサポートする。これらのエンティティおよびインターフェースのいくつかについて以下で説明して、本発明の例示的な実施形態を理解する助けとする。
３ＧＰＰモバイルネットワークでは、モバイル端末１１０（ユーザ装置、ＵＥ、またはデバイスと称される）は、ＵＴＲＡＮではノードＢ１２０（ＮＢ）を介して、Ｅ−ＵＴＲＡＮアクセスでは発展型ノードＢ（ｅＮＢ）を介してアクセスネットワークにアタッチされる。ＮＢおよびｅＮＢ１２０エンティティは、他のモバイルネットワークでは基地局として知られる。ＵＭＴＳおよびＬＴＥにおけるＮＢおよびｅＮＢ１２０も、基地局の機能を遂行する、すなわち、セルラ無線端末の無線アクセスインターフェースを実現する。ＵＥモビリティをサポートするためにＥＰＳに２つのデータパケットゲートウェイ−サービングゲートウェイ（ＳＧＷ）１３０とパケットデータネットワークゲートウェイ１６０（ＰＤＮ−ＧＷまたは略してＰＧＷ）−が配置される。ＳＧＷは、無線アクセスネットワーク、例えば、ＵＴＲＡＮまたはＥ−ＵＴＲＡＮに向かうインターフェースの終端である。１つの無線アクセスネットワーク（ＵＴＲＡＮまたはＥ−ＵＴＲＡＮ）内のモビリティは、アクセスに特有のものである。ＥＰＣ内のモビリティは、ＰＧＷによって管理される。ＰＧＷとＳＧＷとの間のＥＰＣにおけるモビリティは、プロキシＭＩＰｖ６（ＰＭＩＰ）プロトコルまたはＧＰＲＳトンネリングプロトコル（ＧＴＰ）のいずれかに基づき管理される。ＳＧＷとＰＧＷとの間のインターフェースは、Ｓ５と称され、ＧＴＰまたはＰＭＩＰｖ６プロトコルのいずれかに基づく。ＰＧＷは、ＵＥのトラフィックを適切なサービス品質（ＱｏＳ）レベルにマップするためにＵＥへのＩＰアドレス割り当て、およびパケット・フィルタリング（例えば、ディープパケットインスペクション、パケットスクリーニング）をさらに実行する。
Ｅ−ＵＴＲＡＮアクセスを仮定すると、ｅＮＢエンティティ１２０は有線回線を通じて、Ｓ１−Ｕインターフェース（「Ｕ」は「ユーザプレーン」を意味する）を介して１つまたは複数のＳＧＷに、Ｓ１−ＭＭＥインターフェースを介してモビリティ管理エンティティ１４０（ＭＭＥ）に接続されるものとしてよい。Ｓ１−Ｕインターフェースは、ＧＴＰプロトコルに基づき、Ｓ１−ＭＭＥインターフェースは、Ｓ１−ＡＰプロトコルに基づく。後者は、参照により本明細書に組み込まれている、３ＧＰＰのウェブサイトを通じて無料で入手可能である、非特許文献２において指定されている。
ＳＧＳＮ１５０およびＭＭＥ１４０は、サービングコアネットワーク（ＣＮ）ノードとも称される。これらのネットワークノードは、ネットワーク内のＵＥのコンテキストを維持するが、コンテキストは、セキュリティパラメータ、モビリティ管理に使用されるパラメータ（例えば、ＵＥが到達可能である場合に、どのセルにＵＥがキャンピングしているか）、および通信セッションを記述するＱｏＳパラメータなどのセッション管理（ＳＭ）に使用されるパラメータを意味している。
ＳＧＷ１３０は、ｅＮｏｄｅＢ間ハンドオーバ中のユーザプレーンのモビリティアンカーとして、またＬＴＥと他の３ＧＰＰ技術との間のモビリティアンカーとしても動作しつつ、ユーザデータパケットをルーティングし、転送する（Ｓ４インターフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラフィックを中継する）。アイドル状態のユーザ装置では、ＳＧＷはダウンリンクデータ経路を終端し、ユーザ装置に対してダウンリンクデータが到着したときにページングをトリガする。これは、ユーザ装置コンテキスト、例えば、ＩＰベアラサービス、ネットワーク内部ルーティング情報のパラメータを管理し、格納する。また、合法的な傍受の場合にユーザトラフィックの複製も実行する。
ＭＭＥ１４０は、ＬＴＥアクセスネットワークに対するキー制御ノードである。これは、再送を含むアイドルノードユーザ装置トラッキングおよびページング手順を実行する役割を有する。これは、ベアラアクティベーション／デアクティベーションプロセスに関与し、また、初期アタッチのとき、およびコアネットワーク（ＣＮ）ノード再配置を伴うＬＴＥ内ハンドオーバの際にユーザ装置に対してＳＧＷを選択する役割も有する。これは、ユーザを（ＨＳＳとインタラクティブにやり取りすることによって）認証する役割も有する。ノンアクセスストラタム（ＮＡＳ）シグナリングは、ＭＭＥで終端し、これも、ユーザ装置への一時的識別子の生成および割り当てを受け持つ。これは、ユーザ装置がサービスプロバイダの公衆陸上移動ネットワーク（ＰＬＭＮ）にキャンプオンする権限をチェックし、ユーザ装置のローミング制限を実行する。ＭＭＥ１４０は、ＮＡＳシグナリングに対する暗号化／完全性保護のためのネットワーク内の終端点であり、セキュリティキー管理を取り扱う。シグナリングの合法的な傍受も、ＭＭＥによってサポートされている。ＭＭＥは、Ｓ３インターフェースがＳＧＳＮ１５０からＭＭＥ１４０で終端するＬＴＥと２Ｇ／３Ｇアクセスネットワークとの間のモビリティに対する制御プレーン機能も備える。ＭＭＥは、ユーザ装置のローミングのためにホーム加入者サーバ（ＨＳＳ）に向かうＳ６ａインターフェースの終端ともなる。
Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢを備え、パケット・データ制御プロトコル（ＰＤＣＰ）、無線リンク制御（ＲＬＣ）、媒体アクセス制御（ＭＡＣ）、および物理層プロトコル（ＰＨＹ）を使ってＥ−ＵＴＲＡユーザプレーンを、さらにはＵＥに向かう無線リソース制御（ＲＲＣ）プロトコル終端を使って制御プレーンを実現する。ｅＮｏｄｅＢ（ｅＮＢ）は、ユーザプレーンヘッダ圧縮および暗号化の機能を含むＰＨＹ、ＭＡＣ、ＲＬＣ、およびＰＤＣＰ層をホストする。ＵＥとｅＮｏｄｅＢとの間の制御プレーンにおいてＲＬＣ層が提供するサービスは、シグナリング無線ベアラ（ＳＲＢ）と称される。ユーザプレーンにおいて、ＵＥとｅＮｏｄｅＢとの間でＲＬＣ層によって提供されるサービスは、無線ベアラ（ＲＢ）またはデータ無線ベアラ（ＤＲＢ）と称される。ｅＮＢは、制御プレーンに対応するＲＲＣ機能も提供する。これは、無線リソース管理、アドミッション制御、スケジューリング、ネゴシエートされたアップリンクＱｏＳの実行、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／暗号解読、およびダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／展開を含む多数の機能を実行する。Ｘ２インターフェースを使ってｅＮｏｄｅＢ同士が相互接続される。
とりわけ、上位層、すなわち、ノンアクセスストラタム（ＮＡＳ）のメッセージは、ＵＥとｅＮｏｄｅＢとの間でＲＲＣメッセージによって（例えば、ＲＲＣ直接情報転送メッセージを使用して）搬送される。ノンアクセスストラタムは、ＵＥとコアネットワーク（ＣＮ）との間で実行され、ＲＲＣの上に配置される機能層である。さらに、ＮＡＳは、回線交換型音声およびデータに対する呼制御（ＣＣ）、パケット交換データおよびモビリティ管理（ＭＭ）に対するセッション管理（ＳＭ）、ならびにパケット交換および回線交換ドメインに対するショートメッセージサービス（ＳＭＳ）向けのプロトコルの機能群である。ＮＡＳ層で生成される制御メッセージは、ＮＡＳメッセージと称される。そのようなメッセージは、例えば、モビリティ管理、セッション管理、ＳＭＳトランスポート、および呼管理を制御するために使用される。ＮＡＳメッセージは、ＮＡＳトランスポートをサポートするための機能およびプロトコルを含むアクセスストラタム層（層３−２−１、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹ）を通じて透過的にトランスポートされる。初期ノンアクセスストラタムメッセージを送信するために、ユーザ装置は、最初に、エアーインターフェース（Ｕｕインターフェース）上でｅＮｏｄｅＢとの無線リソース制御（ＲＲＣ）接続を確立する。ＲＲＣ接続確立時に、ユーザ装置およびｅＮｏｄｅＢは、同期を取り、ノンアクセスストラタムメッセージのトランスポートに使用することができるシグナリング無線ベアラ（ＳＲＢ）を確立する。
アクセスストラタムは、アクセス技術に特有のプロトコルの機能群、この場合は、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、およびＰＨＹである。これは、無線関係情報の転送をサポートする、ＵＥとアクセスネットワークとの間の無線リソースの使用を調整する、およびサービングネットワークからアクセスネットワークによって提供されるリソースへのアクセスをサポートするためのプロトコルを含む。アクセスストラタムは、サービスアクセスポイント（ＳＡＰ）を通じてサービスをノンアクセスストラタム（ＣＮ関係のシグナリングおよびサービス）に提供する、すなわち、１つまたは複数の独立した同時ＵＥコアネットワーク無線アクセスベアラサービスからなる、ＵＥとコアネットワークとの間のアクセスリンク、およびＵＥの上位層エンティティとコアネットワークとの間の唯一のシグナリング接続を提供する。
ＵＥがスイッチオフされるか、またはモバイルネットワークにアタッチされていないときに、ＵＥは、ＤＥＲＥＧＩＳＴＥＲＥＤ状態にある。ＤＥＲＥＧＩＳＴＥＲＥＤ状態では、ＥＰＳモビリティ管理（ＥＭＭ）コンテキストは存在せず、ＵＥロケーションはＭＭＥに知られず、したがって、ＭＭＥからは到達不可能である。
モバイル端末（またはユーザ装置、ＵＥ）が、ネットワークにアタッチされたときに、ＵＥは、いわゆるＲＥＧＩＳＴＥＲＥＤ状態にある、つまり、ＥＰＳモビリティ管理コンテキストが確立され、既定のＥＰＳベアラコンテキストがネットワーク内で、またＵＥにおいてアクティベートされている。ＵＥがモバイルネットワークに対してＲＥＧＩＳＴＥＲＥＤ状態にある場合、ＵＥは、２つの異なる接続管理状態、ＩＤＬＥ状態およびＣＯＮＮＥＣＴＥＤ状態に入っているものとしてよい。
ＵＥは、送信のデータがなく、無線リソースが解放されているときにＩＤＬＥ状態にあるが、ＵＥは、それでも、有効なＩＰ構成を有している。ＩＤＬＥ状態にあるＵＥは、ｅＮＢとの無線関連付け（すなわち、無線リソース制御接続、ＲＲＣ）を有さず、したがって、確立されたシグナリングおよびデータ無線ベアラはない。さらに、ＵＥとネットワークとの間に（例えば、ＭＭＥへの）ノンアクセスストラタム（ＮＡＳ）シグナリング接続はなく、また、ｅＮＢとＳＧＷとの間にもＳ１−Ｕ接続はない。
ＵＥがＣＯＮＮＥＣＴＥＤ状態にあり、ネットワーク（通常は、ｅＮＢ）が、ＵＥが特定の期間の間にデータを送信／受信していないことを検出した場合、ネットワーク（通常はｅＮＢ）は、無線リソースおよびＳ１接続を解放することを決定する。その結果、ＵＥは、ＣＯＮＮＥＣＴＥＤ状態からＩＤＬＥ状態に遷移する。また、ＭＭＥは、ＵＥに対する内部状態をＩＤＬＥに変更し、ＳＧＷに、ｅＮＢへのＳ１−Ｕ接続を解放するよう通知する。
ＵＥがＩＤＬＥ状態にあり、アップリンクもしくはダウンリンクデータまたはシグナリング（例えば、ＴＡＵ手順による、ＮＡＳシグナリング）がＵＥとネットワークとの間で交換される必要がある場合、ＵＥおよびＭＭＥは、ＣＯＮＮＥＣＴＥＤ状態に入るものとする。それを行うために、ＵＥは、最初に、Ｕｕインターフェース上でｅＮＢへの無線リソース制御（ＲＲＣ）接続を確立する必要がある。ＲＲＣ接続確立時に、ＵＥ１１０およびｅＮＢ１２０は、同期を取り、ＮＡＳメッセージのトランスポートに使用することができるシグナリング無線ベアラ（ＳＲＢ）を確立する。ＲＲＣ層は、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、および物理層を追加的に含むいわゆるアクセスストラタム（ＡＳ）の一部である。
上述のＩＤＬＥおよびＣＯＮＮＥＣＴＥＤ状態は、ＮＡＳ層状態図に関係付けられる。他方、ＡＳ層では、ＩＤＬＥおよびＣＯＮＮＥＣＴＥＤ状態も定義される。ＡＳ ＩＤＬＥおよびＣＯＮＮＥＣＴＥＤ状態は類似しているが、ＮＡＳ ＩＤＬＥおよびＣＯＮＮＥＣＴＥＤ状態に完全に類似しているわけではない、すなわち、ＲＲＣ接続が確立された場合、ＡＳ状態はＣＯＮＮＥＣＴＥＤであり、そうでなく、ＲＲＣ接続が解放されている場合、ＡＳ状態はＩＤＬＥである。常にではないがＡＳ状態がＣＯＮＮＥＣＴＥＤの場合、ＮＡＳ状態もＣＯＮＮＥＣＴＥＤである（例えば、アクティブフラグが立っていないＴＡＵ手順に対して）。ＲＲＣ接続の確立、したがって、ＡＳ ＣＯＮＮＥＣＴＥＤ状態への遷移は、ＵＥによって開始され、ＵＥのみが「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ」メッセージを送信することができる。ＵＥは、アップリンクデータまたはアップリンクシグナリングの利用可能性、またはダウンリンクデータもしくはダウンリンクシグナリングを受信するためにネットワークからのページングのいずれかにより、ＲＲＣ接続確立を開始する。
例えば、ＵＥに、送信すべきアップリンクデータまたはアップリンクＮＡＳシグナリングがある場合、ＵＥは、ＮＡＳサービス要求手順（上で引用されている非特許文献１で説明されている）を開始する。ＵＥは、「サービス要求（Service Request）」メッセージを生成して、対応するＲＲＣ接続を確立するようにＡＳをトリガする。「ＲＲＣ接続要求（RRC Connection Request）」メッセージでｅＮＢに送信されたＲＲＣの確立原因は、「ｍｏ−Ｄａｔａ」（モバイル発信データ、ＵＥがアップリンクデータを送信したがっていることを意味する）、「ｍｏ−Ｓｉｇｎａｌｉｎｇ」（モバイル発信シグナリング、ＵＥがアップリンクシグナリングを送信したがっていることを意味する）、またはセッション（接続）確立をトリガしたアプリケーションが遅延耐性アプリケーションであるときに使用される特別な値「遅延耐性アクセス（delay tolerant access）」に設定される。
他方で、ネットワーク（コアネットワーク）が、ＵＥに対するダウンリンクデータまたはダウンリンクＮＡＳシグナリングを有している場合、ネットワークは、ページング手順を開始する。
最近、３ＧＰＰが、マシンタイプコミュニケーション（ＭＴＣ）のネットワーク改善に関する活動を開始した。これらのサービス要件は、３ＧＰＰのウェブサイトから無料で入手可能である、非特許文献３で説明されているが、使用可能なアーキテクチャ・ソリューションの研究成果は、３ＧＰＰのウェブサイトから無料で入手可能である、非特許文献４に記載されている。ＭＴＣ端末またはＭＴＣデバイスは、これらが通常、人間によって操作されないことを特徴とする。むしろ、通信相手は、いわゆるＭＴＣサーバまたは別のＭＴＣ端末（複数可）などの別のマシンである。ＭＴＣデバイスは、３ＧＰＰによって指定されているようなモバイル端末であってもよいので、「ＵＥ」などのより一般的な通知も、この説明全体を通して使用され、ＭＴＣデバイス、端末、またはＵＥは、入れ替えて使用することができる。
ＭＴＣは、通常人間対人間の通信と異なる特定のいくつかの特徴を有する。３ＧＰＰは、ネットワーク運用を最適化するためにこれらの特定の特徴を識別することを試みている。これらの仕様は、「ＭＴＣフィーチャー」と称される。例えば、ＭＴＣデバイスは、典型的には、より少ない量のデータを送信または受信する。ＭＴＣデバイスおよび３ＧＰＰコアネットワーク（ＣＮ）の別の特徴は、外部サーバ（ＭＴＣサーバ）がＭＴＣサーバとの通信を開始するようにＭＴＣデバイスをトリガすることを可能にする能力であるものとする。これは、いわゆる「デバイストリガリング」によって有効化される。デバイストリガリングは、ＭＴＣサーバによって開始され、異なる手段によって実行され得る。
ＭＴＣデバイスは、ネットワーク内の輻輳／過負荷の発生源となり得る。したがって、ネットワークには効率的な無線リソース管理（ＲＲＭ）が必要であり、特に、無線アクセスネットワークには必要である。上で説明されているように、端末（ＵＥ）がネットワークにサービスを要求するときに、端末はかなり大量のシグナリングを発生する。ＭＴＣデバイス（非特許文献１、Section 4.3.17.2, "Overview of protection from Potential MTC Related Overload"を参照）の場合のように端末の量が多い場合、ネットワークは、適切なアドミッション（アクセス）制御が適用され得る前にたちまち過負荷（輻輳）状態になるおそれがある。
過負荷は、多数の端末からのシグナリングの総量が以下の少なくとも２つの例示的な状況において問題となる（問題となりえる）ことから生じる可能性がある。
− アプリケーション（多くのＵＥで動作している）が、多数のＵＥに、「何か」を同時に実行するよう要求するとき、および／または、
− 多くのＵＥがローミングサービス利用者であるときに、サービングネットワークに障害が生じた場合、これらはローカルの競合ネットワークに移動することを試みる可能性があるものとする。これは、潜在的に、障害を（まだ）生じていないネットワーク（複数可）には過剰な負担となる可能性がある。
一般に、３ＧＰＰ標準化のリリース１０（Ｒｅｌ−１０）では、ネットワーク内の輻輳制御メカニズムは、ＮＡＳレベル輻輳制御により拡張された。ＮＡＳレベル輻輳制御の導入は、ネットワークへのマシンタイプコミュニケーションの影響について３ＧＰＰで実施した調査の結果であった。同時に動作する多くのＭＴＣデバイスが、ネットワークに対し輻輳または過負荷を引き起こすおそれがあるという結論が得られた。そのような過負荷に対抗するために、３ＧＰＰでは、以下のいくつかの対策を仕様化した。
ａ）該当する場合、ＵＥは、この後の項目において説明されているように機能強化に合わせて構成することができる。製造後構成は、リモートで実行することができる。
ｂ）モバイル発信サービスについては、低いアクセス優先度に構成されているＵＥは、Ｅ−ＵＴＲＡＮにＲＲＣ接続確立がＥ−ＵＴＲＡＮへの接続を確立するときに低いアクセス優先度に構成されているＵＥからであることを示す情報を提供する。
ｃ）ＲＲＣシグナリングでは、低いアクセス優先度に構成されているＵＥからのメッセージを拒否したときに「延長待ち時間タイマ」を用意することができる。
ｄ）ＭＭＥは、ＵＥのいくつかのサブカテゴリに対してＥ−ＵＴＲＡＮにおけるＲＲＣ接続確立の拒否を開始することができる。それに加えて、ＭＭＥシグナリングまたは運用管理（Ｏ＆Ｍ）シグナリングは、ＵＥのいくつかのサブカテゴリに対して拡張アクセス禁止を開始するようにＥ−ＵＴＲＡＮをトリガすることができる。
ｅ）ＭＭＥからＥーＵＴＲＡＮへの過負荷メッセージは、上記の項目ｂ）、ｃ）、およびｄ）における機能を実行するＥ−ＵＴＲＡＮを補助するために拡張される。
ｆ）長い最小周期ＰＬＭＮ探索制限時間（long minimum periodic PLMN search time limit）（上述の非特許文献４を参照）で構成されたＵＥでは、より好ましいＰＬＭＮに対して探索と探索との間の最短時間が長くなる。
ＮＡＳレベルモビリティ管理制御は、サービングＣＮノード（ＭＭＥ／ＳＧＳＮ）における輻輳を引き起こす可能性のある、多くのＵＥがネットワークアクセス試行をほとんど同時に開始する状況に適用可能である。
セッション管理（ＳＭ）およびモビリティ管理（ＭＭ）は両方とも、ＵＥおよびＭＭＥ／ＳＧＳＮにおけるＮＡＳ（ノンアクセスストラタム）層の輻輳と考えられる。通常、ＭＭＥ／ＳＧＳＮおよびＵＥは、個別のＭＭおよびＳＭコンテキストを格納する。さらに、ＳＭコンテキストは、ＰＤＰ（パケットデータプロトコル）またはＰＤＮ（パケットデータネットワーク）接続毎にある。
二重優先度デバイスは、低優先度アプリケーション（遅延耐性アプリケーション）、通常優先度アプリケーション、または両方の種類のアプリケーションを同時に動作させる（実行する）ことができるデバイスである。
二重優先度デバイスは、したがって、代替的に、または同時に、異なる優先度のアプリケーションを実行することができる、すなわち、遅延耐性特性を有するサービス（例えば、ＭＴＣアプリケーション）、または通常サービス（例えば、電話、ストリーミング、またはインターネットアクセス）にアクセスすることができる。アプリケーション、したがって、サービスの要件（およびその優先度）も、接続時に変化し得る。しかし、無線アクセスネットワークおよび特に基地局は、初期ネットワークアクセスのときにデバイス優先度に関して通知を受けるだけである。したがって、基地局は、輻輳またはアクセス（アドミッション）制御などの無線リソース管理タスクを適切に実行することができない。端末の実デバイス優先度と基地局によって中継されるデバイス優先度との間に不一致があると、輻輳の状況において誤った決定に至る可能性がある。例えば、基地局は、端末が低優先度ＭＴＣアプリケーションを実行しているネットワークに最初にアクセスしたときに通常優先度端末の無線リソースを解放することを決定することができる。または、他方で、基地局は、端末が通常端末アプリケーションを実行しているネットワークに最初にアクセスしたときに低優先度端末にリソースを割り当てることを決定することができる。
3GPP Technical Specification (TS) 23.401; "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"; v. 10.2.1 of January 2011 3GPP Technical Specification (TS) 36.413; "S1 Application Protocol (S1AP)"; v. 10.0.1, January 2011 3GPP TS 22.368, v.11.3.0, Oct. 2011, "Service requirements for Machine-Type Communications (MTC)" 3GPP TS 23.888, v.1.5.0, Oct. 2011, "System Improvements for Machine-Type Communications (MTC)" the RRC protocol specification 3GPP TS 36.331 by 3GPP RAN2 CR # R2-123045 3GPP TS 36.413, v. 10.5.0, "S1 Application Protocol (S1AP)" 3GPP TS 22.011, "Service Accessibility". 10.3.0, Section 4.3.1
アプリケーション遅延耐性、すなわち優先度の観点から、遅延耐性および非遅延耐性の少なくとも２種類のデバイスがある。同じデバイスが、いくつかが遅延耐性であるが、それ以外は遅延耐性でない（以下では「通常アプリケーション」とも称する）アプリケーションを実行することもできる。これらのデバイスは、二重優先度デバイスまたは端末またはＵＥと称される。本発明に内在する問題は、二重優先度デバイスについて、基地局は端末接続の状態と矛盾する情報を使用することができるので無線リソース管理機能が不正確に実行され得るという観察結果に基づく。
発明の目的は、端末、無線アクセスネットワーク、およびコアネットワークが矛盾なく動作するように無線リソース管理処理を改善することである。
これは、独立請求項の特徴によって達成される。
有利な実施形態は、従属請求項の主題である。
本発明の特定のアプローチは、基地局で過負荷状況の制御に関する正しい決定を実行することを可能にすることである。基地局が過負荷制御の決定を効率よく下すことができるように、基地局は、コアネットワーク（例えば、モビリティ管理エンティティ）から、または端末から、端末に関係する優先度または優先度の変更に関する情報を取得する。
本発明を使用すると、無線ネットワークはネットワーク過負荷の制御を正しく実行することを可能にすることによって無線リソース管理機能を効率よく実行することができる。過負荷は、コアネットワークまたは無線ネットワークにおいて発生する可能性がある。本発明を使用すると、ネットワークは輻輳発生時に通常優先度ＵＥからリソースを取り上げることを回避することができ、また輻輳発生時に無線リソースが低優先度ＵＥに割り当てられないようにすることが可能になる。
本発明の一態様によれば、基地局および端末を含む通信システムにおいて無線リソース管理を実行するために、前記基地局で実行するための方法が提供される。この方法は、前記端末にサービスを提供するモビリティ管理ノードから優先度のインジケータを受信するステップであって、前記優先度は、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す、ステップと、前記受信されたインジケータに基づいて、輻輳またはアドミッション制御を含む無線リソース管理タスクを実行するステップと、を含む。
本発明の別の態様によれば、基地局および端末を含む通信システムにおいて無線リソース管理を実行するために、前記基地局で実行するための方法が提供される。この方法は、前記端末から新しい優先度のインジケータまたはベアラ毎の優先度のインジケータを受信するステップであって、前記優先度は、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す、ステップと、前記受信されたインジケータに基づいて、輻輳またはアドミッション制御を含む無線リソース管理タスクを実行するステップと、を含む。
上記方法の無線管理タスクを実行する前記ステップは、好ましくは、前記通信システムに輻輳が生じた場合において、前記対応する受信したインジケータが遅延耐性優先度を示しているときに、端末トラフィックを搬送するベアラおよび／または前記対応するＲＲＣ接続を削除するステップと、前記輻輳状態に応じて、前記対応する受信したインジケータが遅延耐性優先度を示していないときに、端末トラフィックを搬送するベアラおよび／または前記対応するＲＲＣ接続を削除するか否かを決定するステップと、を含む。
前記決定するステップは、通常優先度のベアラを自動的に削除しないようにも構成され得る。
本発明の別の態様によれば、基地局および端末を含む通信システムにおいて無線リソース管理を実行するために、ネットワークノードで実行されるための方法が提供される。この方法は、端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す優先度を決定するステップと、前記基地局に前記決定した優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにするステップと、を含む。
好ましくは、前記インジケータは、前記端末にサービスを提供する前記モビリティ管理ノードから前記基地局へのＳ１−ＡＰプロトコルのメッセージに含まれる。
例えば、前記Ｓ１−ＡＰメッセージは、初期コンテキストセットアップ要求（Initial Context Setup Request）、Ｅ−ＲＡＢセットアップ要求（E-RAB Setup Request）、およびＥ−ＲＡＢ修正要求（E-RAB Modify Request）のうちの少なくとも１つである。しかし、本発明は、これら既存のメッセージに限定されず、Ｓ１−ＡＰメッセージは、新規メッセージであってもよく、これはその優先度または新しい優先度を搬送するように指定されたメッセージを意味する。基地局は、ネットワークノードまたは端末のいずれかから送信されるメッセージ内の変更フラグの設定によって優先度の変更について通知を受けることができることに留意されたい。
コンテキストセットアップ要求（Context Setup Request）、Ｅ−ＲＡＢセットアップ要求、またはＥ−ＲＡＢ修正要求などの前記Ｓ１−ＡＰメッセージは、スケジューリングを目的とする割り当て／保持優先度を搬送する情報要素（information element）を含むことができ、この情報要素は、所定の範囲の値から１つの値を取るように構成される。有利には、前記端末のトラフィックが遅延耐性であるか否かを示す前記優先度の値は、前記所定の範囲からの１つ以上の前記値が、前記端末トラフィックが遅延耐性であることを示し、前記所定の範囲からの別の１つ以上の前記値が、前記端末トラフィックが遅延耐性でないことを示すように、前記所定の範囲の値にマッピングされる。
例えば、前記マッピングは、前記基地局、または、前記端末にサービスを提供する前記モビリティ管理ノードによって構成され、前記基地局、または、前記端末にサービスを提供するモビリティ管理ノードは、前記構成されたマッピングを、前記端末にサービスを提供する前記モビリティ管理ノード、または、前記基地局に、それぞれ送信する。
本発明のさらに別の態様によれば、基地局および端末を含む通信システムにおいて無線リソース管理を実行するために、前記端末で実行するための方法が提供される。この方法は、各端末ベアラに関係し、当該ベアラのトラフィックが遅延耐性であるか否かを示す優先度を設定するステップと、前記基地局にその優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにするステップと、を含む。
本発明の別の態様によれば、基地局および端末を含む通信システムにおいて無線リソース管理を実行するために、前記端末で実行するための方法が提供される。この方法は、優先度の変更後の端末に関係し、当該端末のトラフィックが遅延耐性であるか否かを示す新しい優先度を設定するステップと、前記基地局にその優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにするステップと、を含む。
好ましくは、前記端末トラフィックの優先度が変更され、この方法は、前記インジケータが送信される無線リソース制御、ＲＲＣ、プロトコルメッセージを生成するステップをさらに含む。しかし、本発明は、それらに限定されず、別のＲＲＣメッセージまたは新規指定されたＲＲＣメッセージまたは他のメッセージも使用され得る。
例えば、前記ＲＲＣプロトコルメッセージは、ＲＲＣ接続要求またはＲＲＣ接続再確立（RRC Connection Reestablishment）のいずれかである。
有利には、前記インジケータは、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す前記優先度が、前記基地局に知られている値から新しい値に変更された場合に送信される。好ましくは、前記優先度の値は、前記端末のＵＳＩＭの内容および／または前記端末のサービス品質であるＱｏＳに関するベアラ特性に依存する。
例えば、前記インジケータは、すべての構成されたベアラを含む前記端末の全体的優先度であるデバイス優先度を示し、前記端末の前記全体的優先度は、前記端末の構成されたベアラの前記優先度の最大値である。あるいは、前記インジケータは、ベアラ毎のデバイス優先度を示す。
本発明の一態様によれば、基地局および端末を含む通信システムにおいて無線リソース管理を実行することができる前記基地局が提供される。この基地局は、前記端末にサービスを提供するモビリティ管理ノードから優先度のインジケータを受信し、または、前記端末から新しい優先度もしくは特定のベアラに対する優先度のインジケータを受信する受信ユニットであって、前記優先度は、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す、受信ユニットと、前記受信されたインジケータに基づいて、輻輳またはアドミッション制御を含む無線リソース管理タスクを実行する無線リソース管理部と、を備える。
本発明の一態様によれば、ネットワークノード、基地局、および端末を含む通信システムにおける前記ネットワークノードが提供される。このネットワークノードは、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す優先度を決定する優先度決定ユニットと、前記基地局に前記決定された優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにする送信ユニットと、を備える。
本発明の一態様によれば、端末および基地局を含む通信システムにおいて動作する前記端末が提供される。この端末は、当該端末に関係し、当該端末のトラフィックが遅延耐性であるか否かを示す優先度を設定するための優先度決定ユニットと、前記基地局に前記優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにする送信ユニットと、を備える。
過負荷状況またはシナリオは、ネットワークが通信しているすべてのエンティティに対して十分なリソースを提供していないため輻輳および／またはアドミッション制御が実行されなければならない状況である。このコンテキストにおける過負荷制御は、端末または基地局などのエンティティが、通信のため接続（アドミッション制御）を確立するように、または通信のためのリソースを獲得するように有効化されるか否かを決定することに関係する。過負荷は、コアネットワークまたは無線アクセスネットワークにおいて発生し得る。
この優先度の目的は、例えば、ＭＴＣデバイス（端末）を他の端末（通常デバイス）から区別することにある。この区別では、典型的にＭＴＣ端末が直ちに配信することが必要ではない遅延耐性トラフィックの伝送を行うことを仮定する。一方、他の種類の端末は、通常、音声または任意のオーディオおよび／もしくはビデオストリームの伝送を含み得る、通話またはストリーミングなどの、遅延要求の厳しいサービスを送受信することができる。
本発明の別の態様によれば、コンピュータ可読プログラムコードが具現化されているコンピュータ可読媒体を備えるコンピュータプログラム製品が実現され、プログラムコードは本発明を実施するように適合されている。
本発明のさらに別の態様によれば、上で説明されているような装置を具現化する集積回路が、実現される。
本発明の上記および他の目的および特徴は、以下の説明、および添付図面と併せて与えられている好ましい実施形態から、より明らかになるであろう。
マシンタイプコミュニケーションに対する現在の３ＧＰＰアーキテクチャを例示するブロック図である。 本発明の一実施形態による基地局の例示的処理を示すフローチャートである。 本発明の別の実施形態による基地局の例示的処理を示すフローチャートである。 既存のＳ１−ＡＰメッセージ内の新しい情報要素を使用するＭＭＥからｅＮＢへのデバイス優先度のシグナリングを示すメッセージフローチャートである。 新しいＳ１−ＡＰメッセージを使用するＭＭＥからｅＮＢへのデバイス優先度のシグナリングを示すメッセージフローチャートである。 既存のＳ１−ＡＰメッセージ内の利用可能な情報要素を再利用するＭＭＥからｅＮＢへのデバイス優先度のシグナリングを示すメッセージフローチャートである。 ＭＭＥからｅＮＢへの全体的デバイス優先度のシグナリングを示すメッセージフローチャートである。 既存のＲＲＣ接続要求メッセージを使用する端末からｅＮＢへのデバイス優先度のシグナリングを示すメッセージフローチャートである。 既存のＲＲＣ接続再確立メッセージを使用する端末からｅＮＢへのデバイス優先度のシグナリングを示すメッセージフローチャートである。 通常使用され、またデバイス優先度のシグナリングに使用されるＲＲＣ接続要求手順を示す概略メッセージフローチャートである。 新しいＲＲＣメッセージを使用する端末からｅＮＢへのデバイス優先度のシグナリングを示すメッセージフローチャートである。 デバイス優先度の一般的なシグナリングを示すメッセージフローチャートである。 端末、基地局、およびネットワークノードの機能構造を示すブロック図である。
背景技術の節に概要が述べられているように、二重優先度デバイス（端末）は、ネットワークに接続しているときにデバイス優先度を変更することができる。この場合に、デバイスに割り当てられ、コアネットワークに知られている優先度、また無線アクセスネットワークに知られている優先度の間に矛盾が生じ得る。
この問題を解消するために、本発明の一実施形態により、コアネットワーク（例えば、ＭＭＥ）または端末は、無線アクセスネットワーク（例えば、端末にサービスを提供する基地局、ＬＴＥではｅＮＢ）に、変更されたデバイス優先度を指示する。したがって、基地局は、ネットワーク輻輳が発生した場合に適切な無線リソース管理決定を下すことができる。
さらなる問題が、端末によって実行されるアプリケーションを区別することなく、したがって各アプリケーションに対するネットワークサービスに関する要件を区別することなく、したがってまたアプリケーションの通信を搬送するための各ベアラの「デバイス優先度」を区別することなく、初期アクセスで有効であり、シグナリングされるデバイス優先度は「全体的」デバイス優先度であるという事実から生じ得る。特に、低優先度アプリケーション（遅延耐性アプリケーション）および通常優先度アプリケーションを同時に実行する二重優先度デバイスは、基地局によって実行される無線リソース管理によって不適切に取り扱われ得る。言い換えると、ネットワークの観点からは、デバイス優先度は「ＵＥ毎」である、すなわち、無線ネットワークは、ネットワークにどのようにアクセスしたかに応じてＵＥを低優先度ＵＥまたは通常優先度ＵＥのいずれかとみなす。アクセスの方法は、ＲＲＣ接続要求でシグナリングされる確立原因値によって与えられる。これは、ＵＥを保持する、またはＵＥを解放する決定は、ＵＥのＲＲＣ接続全体に対して下されることを意味する。
この問題を解決するために、本発明の一実施形態は、以下で詳しく説明されるように、ネットワーク接続全体を解放するのではなくて、低優先度アプリケーションに対するベアラのみを解放する可能性をもたらす。
デバイスの優先度（「デバイス優先度」）を区別する、特に、遅延耐性と、他の（「通常」）端末および／または端末のベアラとを区別することは、どの端末または端末のアプリケーションが輻輳状況、すなわち、利用可能なリソースよりも要求されたリソースが多い状況においてリソースを割り当てられるか、またはアクセスを認められるかを決定するための基準を無線アクセスネットワークに与えるために重要である。
デバイス優先度（以下では、「デバイス優先度」という用語は、デバイス優先度がベアラ固有である場合についても使用されるものとする）は、一般に、動作中の（実行されている）アプリケーションおよび／または汎用加入者識別モジュール（ＵＳＩＭ）の構成に依存する。ＵＳＩＭは、ＳＩＭとともに、異なるモバイルデバイス間で転送され得る、取り外し可能なＳＩＭカード内に埋め込まれた集積回路である。ＳＩＭカードは、その固有シリアル番号（ＩＣＣＩＤ）、国際移動電話加入者識別番号（ＩＭＳＩ）、セキュリティ認証および暗号化情報、ローカルネットワークに関係する一時的情報、ユーザがアクセスを有するサービスのリスト、および２つのパスワード、通常使用の暗証番号（ＰＩＮ）とＰＩＮロック解除のためのＰＩＮブロック解除コード（ＰＵＫ）を格納している。ＳＩＭ（ＧＳＭとＧＰＲＳで使用される）とＵＳＩＭの違いは、ＵＳＩＭがＵＭＴＳに対して導入され、相互認証、より長い暗号鍵、および改善された電話帳などのいくつかのセキュリティの改善点を伴う点である。
輻輳状況（ネットワークが輻輳しているとき）において、低優先度端末は、さまざまなアクセス禁止の制御を受け、またＣＯＮＮＥＣＴＥＤ状態からＩＤＬＥ状態に移動される端末のうちの最初の端末とすることができる。したがって、基地局によって知られている優先度と端末の実際の優先度−変更後の通常優先度である−との間に矛盾がある場合、通常優先度アプリケーションは、基地局によって決定される輻輳制御対策で問題を生じる可能性がある。
本明細書では、「ネットワークノード」などの用語で、通信ネットワーク内の物理的エンティティを表す。１つのノードは、複数の機能エンティティを有することができる。機能エンティティは、所定の機能セットをノードまたはネットワークの他の機能エンティティに実装し、および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信する際に使用することができる通信設備または媒体にノードをアタッチする１つまたは複数のインターフェースを有することができる。同様に、ネットワークエンティティは、他の機能エンティティまたは対応するノードと通信するために使用できる通信設備または媒体に機能エンティティをアタッチする論理インターフェースを有することができる。
「サーバ」または「トリガサーバ」は、本明細書では、ネットワーク内、または外部ネットワークもしくは外部ノード内にあり得るエンティティを指す。これは、例えば、データを、（ＭＴＣ）端末または複数の端末から自動的に収集し、端末にトリガ要求を送信することができるサーバとすることができる。トリガ要求は、端末に伝達され、測定データ、サーバに送信されるべきデータ、またはその識別を示すための、または実際のデータが本発明によって提示されているように送信されるか、送信されないか、または遅延ありで送信されることを示すための単なるシグナリング・データなどのデータをネットワークおよび／またはサーバに提供するようにネットワークおよび／またはサーバへの接続を端末がセットアップすべきであることを示すメッセージまたはインジケータである。サーバは、別の端末によっても実装され得ることに留意されたい。例えば、第１の端末は、第２の端末をトリガするように構成され得る。そのような構成は、例えば、（場合によってユーザ操作）端末が別のＭＴＣ端末からデータを収集するときに有利であり得る。上の背景技術の節で説明されているように、端末は、ＬＴＥ、ＵＭＴＳ、またはＧＳＭ／ＧＰＲＳ／ＥＤＧＥ端末であってよい。
典型的にはＭＴＣ端末によって提供される少量のデータは、小さなデータチャンクと理解することができ、これは小さなＩＰパケット、ＳＭＳ、または他の何らかのアプリケーション固有のデータであり得る。データの量は、例えばそれがＳＭＳに収まるよう十分に小さいと考えられ得る。したがって、小さなデータ量は、１４０バイト未満とすることが可能であり、これはＳＭＳの現在のペイロードサイズである。
ユーザプレーンと制御プレーンとを区別することに関して、データベアラは、ユーザプレーンに関連付けられ、その一部である。これらは、ユーザデータをトランスポートするように確立される。対照的に、制御プレーンおよびシグナリングベアラは、一般に、制御シグナリングのトランスポート用である。
基地局は、ＲＲＣ接続確立メッセージに基づき、特に「確立原因」を見ることによって、端末の初期アクセス優先度を知ることができる。確立原因は、遅延耐性デバイス優先度に対応し得る、例えば「遅延耐性アクセス」を示すことができるインジケータ（情報要素、すなわち、対応するプロトコル、この場合にはＲＲＣプロトコル、の構文要素）である。この指示に基づき、基地局は、端末がＭＴＣ端末であると仮定することができる。そうでない場合、確立原因が「遅延耐性アクセス」でないときに、基地局は、端末が、通常端末、例えば、非ＭＴＣ端末であると仮定することができる。しかし、後でＵＥ接続中に、端末のデバイス優先度（端末のアクセス優先度）が変わってもよい。したがって、本発明では、端末から基地局への変更されたデバイス優先度のシグナリングを企図している。代替的に、またはそれに加えて、デバイス優先度および／またはその変更は、ＭＭＥから基地局にシグナリングされ得る。
任意のＵＥは、遅延耐性デバイスとして構成することも可能である。遅延耐性ＵＥは、遅延耐性アプリケーション／サービス／ベアラが動作しているＵＥである。ＵＥの優先度は、Initial Connection Establishment（ＲＲＣ接続要求中の「Ｅｓｔａｂｌｉｓｈｍｅｎｔ ｃａｕｓｅ」）から利用可能である。RRC Connectionにおいて、ＵＥが、それが遅延耐性であると指示した場合、ネットワークは、ネットワーク側に輻輳が生じていた場合にConnection Requestを拒否することもあり得る。遅延耐性ＵＥは、ＩＤＬＥモードに入っている間に何らかの特別なシステム情報を維持するべきである。そのような情報は、例えば、３ＧＰＰのウェブサイトを介して無料で入手可能な、非特許文献５の５.２.２.３節に組み込まれる、「Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ Ｔｙｐｅ １４ ｉｎ ＬＴＥ」である。これらの（遅延耐性）ＵＥは、ネットワークにアクセスする（ＲＲＣ接続確立（RRC Connection Establishment）を開始する）ことを試みることを、特定のＵＥのアクセスクラスに対する特別なシステム情報によって指示されるようにこれらのＵＥがその試みを禁止されていない場合にのみ行うことができる。ＵＥ ＮＡＳは、いつ遅延耐性アクセスについて構成されるかをＵＥ ＲＲＣに通知する。
本発明の一実施形態によれば、ＵＥ ＮＡＳは、遅延耐性アクセスにもはや構成されていないときにそのことをＵＥ ＲＲＣにも指示する（これは、ＵＳＩＭ構成が変更されたか、またはＮＡＳに維持されているベアラコンテキスト上のいくつかの変更が遅延耐性アクセスにもはや構成されていないことを示唆する場合であってよい）。この指示を受け取った後、ＵＥは、ＵＥ ＮＡＳからさらに通知（さらなる通知は遅延耐性構成が再び適用された場合に続き得る）が届くまで特別なシステム情報を維持するのを停止する。この挙動により端末の電池の節電が可能になるが、それは、もはや特別なＳＩＢ（システム情報ブロック）を不必要に維持する必要がなくなるからである。ＵＥ ＮＡＳは、ＮＡＳプロトコルスタック上で、すなわちｅＮＢに透過的にコアネットワークと通信する端末の機能部分である。ＵＥ ＲＲＣは、ＲＲＣプロトコルを含むＲＡＮプロトコルスタック上で、無線アクセスネットワークと、すなわちｅＮＢと通信する端末の機能部分である。
このアプローチは、低優先度アプリケーション、通常優先度アプリケーション、または両方の種類を同時に動作させることができる、いわゆる二重優先度デバイスについて特に関連性がある。例えば、携帯電話は、通常の携帯電話であるものとしてよく、それに加えて、ＭＴＣ機能を実装することができる。デバイス優先度の変更は、例えば、新しいアプリケーションを端末上で動作させることによって、引き起こされ得る。
ＭＴＣアプリケーションは、遅延耐性（すなわち、低優先度）であってよいが、必要というわけではない。ＭＴＣデバイスは、一般的に、遅延耐性アプリケーションを動作させている可能性があるが、以下において、ＭＴＣ関連の例がいくつか与えられたときでも必ずしも常にそうであるとは限らない。一方、通常の端末は、遅延耐性アプリケーションを動作させるように構成され得る。
ＬＴＥ標準では、例えば、いわゆる割り当ておよび保持優先度（ＡＲＰ）を定義しているが、ただし異なる目的に使用される。特に、割り当ておよび保持優先度は、所定の範囲の値を有するＳ１−ＡＰプロトコルの情報要素であり、その意味は携帯電話会社によって構成可能であり、スケジューラに対する追加の情報を提供することを目的としている。割り当ておよび保持優先度は、遅延耐性に関してデバイスを特徴付けないという点、および輻輳制御およびアドミッション制御などの、無線リソース管理機能に使用されないという点で、上で定義されているデバイス優先度と異なる。
デバイス優先度は、端末および／またはＵＳＩＭ構成上で動作するアプリケーションによって与えられる。例えば、デバイス優先度は、端末に対して構成されているベアラのサービス品質（ＱｏＳ）特性によって定義され得る。ＵＳＩＭ構成に関して、これは、端末がＭＴＣであるか通常端末であるかを指定することができる。低優先度端末は、異なるアクセス禁止の制限を受け、またネットワークに輻輳が生じたときにＣＯＮＮＥＣＴＥＤ状態からＩＤＬＥ状態に移動される最初の端末とすることができる。
端末の優先度は、ＵＳＩＭおよび特に管理オブジェクトとも称される以下の４つのパラメータを変更することによって構成し、再構成することができる。
− NAS_SignalingPriority
− ExtendedAccessBarring
− Override_NAS_SignalingLowPriority
− Override_ExtendedAccessBarring
これら４つのパラメータもしくはそのサブセットおよび／またはアプリケーションタイプは、端末の優先度に影響を及ぼすものとしてよい。この優先度は、ＮＡＳレベルで、初期セットアップ後に、および／またはさらなる修正後に、ＭＭＥに伝達される。優先度は、好ましくは、ＵＥ特性に関係する情報要素内で伝達される。しかし、デバイスに対して構成されているベアラの特性に関する情報要素（複数可）によっても搬送され得る。
ＬＴＥシステムに関して、標準化における現在の状態の問題を以下にまとめた。端末が、ノンアクセスストラタム（ＮＡＳ）によって指示されるような低優先度アクセスがあったためＲＲＣ接続を開始している場合、および後の段階で、アプリケーションが同じＲＲＣ接続で通常優先度アクセスに対してセットアップされているベアラをトリガした場合、無線アクセスネットワーク（基地局）は、その状況の更新、すなわち、優先度変更指示を取得しないであろう。この結果、ネットワーク内に輻輳が生じているときに、通常優先度アプリケーションが端末で動作していたとしても、ＲＲＣ接続を解放する可能性がある。同様に、端末が、ＮＡＳによって指示される通常優先度アクセスがあるためＲＲＣ接続を開始している場合、およびその後で、アプリケーションが同じＲＲＣ接続において低優先度アクセスに対してセットアップされているベアラをトリガした場合、無線アクセスネットワークには、この優先度変更に関する情報はない。これにより、無線アクセスネットワーク内に輻輳が生じている場合に、通常優先度アプリケーションが現在動作していないとしても、ＲＲＣ接続を解放しない可能性がある。これは、アプリケーションにマイナスの影響を及ぼすことなく必要ならば低優先度デバイスのＲＲＣ接続が解放され得るような仕方で低優先度端末を定義する元々の意図に反する。
この問題の１つの解決策は、結果として優先度の変更を引き起こす新しいアプリケーションの開始後（またはベアラが古いためＰＤＮ接続の修正が行われた後）、端末は、ＲＲＣ接続の解放を自律的にトリガし、その後、通常（遅延耐性でない）優先度アクセスで新しいＲＲＣ接続をさらに確立することができる。
しかし、ＬＴＥでは「上位層によって要求されたＲＲＣ接続解放」を除き、端末からの自律的解放は指定された手順ではなく、これにより現在のセルは禁止されているものとして取り扱われる。例えばＮＡＳから引き起こされた新しい解放により、端末が現在のセルを禁止されているものとして取り扱わなかった場合でも、ＲＲＣ接続の自律的解放は、ＵＭＴＳの経験に基づく３ＧＰＰによって回避される可能性の高い手段であり、電力のある程度の節約のためにのみ端末実装でＲＲＣ接続の解放がトリガされる可能性がある。さらに、ＲＲＣ接続解放とそのすぐ後のＲＲＣ接続確立は、端末の古いコンテキスト作成と新しいコンテキスト作成に関してネットワーク内に混乱をもたらす可能性がある。その後の接続確立がすぐでない場合、これは、ある程度の遅延およびシグナリングオーバーヘッドを呼確立において引き起こす可能性もあり、これは特に通常ベアラには不利である。
本発明によれば、端末のノンアクセスストラタムは、新しいＰＤＮ接続を確立するためセッション管理シグナリングをトリガする新しいアプリケーションのアプリケーションタイプに基づき、オーバーライディングリーブ（overriding leaves）が構成されているか否かなどのＵＳＩＭ情報に基づき、かつ／またはデバイスの現在優先度レベルに基づきデバイスの新しい優先度を決定すべきである。次いで、決定された優先度は、端末またはＭＭＥのいずれかから基地局にシグナリングされる。ＭＭＥは、ＵＥからこの優先度を受け取るので、優先度を知っている。
本発明の一実施形態に従う基地局による輻輳の処理は、図２に示されている。
特に、図２は、基地局で実行されるための方法を示すフローチャートである。この方法は、基地局、端末にサービスを提供するモビリティ管理ノードなどのネットワークノード、および端末を含む通信システム内の輻輳またはアドミッション制御を含む無線リソース管理タスクを実行することを可能にする。この方法は、端末にサービスを提供するモビリティ管理ノードから優先度のインジケータを、または優先度が変更されたときに端末から新しい優先度のインジケータを受信するステップ２１０であって、優先度は端末に関係し端末のトラフィックが遅延耐性であるか否かを示す、ステップ２１０を含む。受信された優先度は、基地局に格納され得る。ネットワークに輻輳が生じていない場合、優先度は使用しなくてもよい。しかし、ネットワークに輻輳が生じている場合（２２０）、基地局は、受信された優先度インジケータに基づき無線リソース管理２３０を実行する。
ネットワークに輻輳が生じている場合（ステップ２２０で「はい」）、無線リソース管理ステップ２３０は、対応する受信したインジケータが遅延耐性優先度を示しているとき（ステップ２４０で「はい」）に端末トラフィックを搬送するベアラおよび／または対応するＲＲＣ接続２５０を削除するステップをさらに含み得る。さらに、無線リソース管理ステップ２３０は、輻輳状態に従って、対応する受信したインジケータが遅延耐性優先度を示していない（ステップ２４０で「いいえ」）ときに端末トラフィックを搬送するベアラおよび／または対応するＲＲＣ接続を削除するかしないか（２８０）を決定する（２７０）ステップをさらに含み得る。
一般に、輻輳の状態は、利用可能なリソースまたは他の基準と要求されたリソースまたは他の基準との間の配分を反映するものとしてよい。図２は、ステップ２７０における、低優先度ベアラ／端末接続の解放の後に輻輳がまだ重大であるか否かの決定を示す。デバイス優先度がベアラ毎に利用可能である場合、ステップ２６０が存在し、これに従って、二重優先度デバイスに対してまだ何らかの通常優先度ベアラがある（ステップ２６０で「はい」）場合に、ステップ２７０において、これらが、低優先度ベアラを解放した後の輻輳状態に応じて、すなわち、輻輳のレベルに従って、解放されるべきか否かが決定される。
図３は、ベアラ毎にデバイス優先度が与えられる場合にＬＴＥ基地局によって適用される無線リソース管理アプローチを個別に示している。特に、図３は、ベアラ毎のデバイス優先度（「ＭＴＣ優先度」）の受信３２０を含むＲＲＣ接続セットアップ手順３１０（以下で説明されるようにデバイス優先度の変更をシグナリングするためにも使用され得る）を使ったＵＥ初期ネットワークアクセスを示す。ネットワークに輻輳が生じているときに受信されたデバイス優先度に基づき、端末または複数の端末の低優先度ベアラが解放される（３３０）。低優先度ベアラのみを有するデバイスについては、これは、デバイス接続の解放、すなわち、ＣＯＮＮＥＣＴＥ状態からＩＤＬＥ状態へのデバイス（端末）の状態の変更も意味する。特に、解放３３０は、以下のように動作し得る。ＣＯＮＮＥＣＴＥＤモードのそれぞれのＵＥ（デバイス）について、そのベアラの種類が評価される（３４０）。ＵＥが通常優先度ベアラしか有していない場合、他のＲＲＭアプローチが使用される（３５）。可能ならば、通常優先度ベアラは解放されない。他のＲＲＭアプローチは、例えば、接続が異なるシステムにリダイレクトされるか、またはこのＵＥのハンドリングを別のセル／システムなどに渡すように異なる原因値で接続を解放することであってよい。ＵＥが低優先度の１つまたは複数のベアラ、および通常優先度の１つまたは複数のベアラを有する場合、低優先度ベアラのみが解放される（３６０）。ＵＥが低優先度のベアラしか有していない場合、ＲＲＣ接続解放が開始される（３７０）。
したがって、基地局は、ベアラの優先度を「見て」、輻輳が生じているときに必要ならば、低優先度ベアラのみのベアラ解放を開始する。こうして、ＲＲＣ接続は、必ずしも解放される必要はない。ＲＲＣ接続は、輻輳が生じている場合に必要ならば、「ｅｘｔｅｎｄｅｄＷａｉｔＴｉｍｅ」をＲＲＣ接続解放（RRC Connection release）メッセージで設定して残りのベアラのみが低優先度ベアラである場合にのみ解放される。タイマの設定は、このタイマによって指示される時間内にＵＥが再び接続を試みることを許さない効果を有する。
ＲＲＣ接続は、残りのベアラのみが通常優先度ベアラである場合に、解放されない。
基地局は、コアネットワークまたは端末からデバイス優先度に関する、またはデバイス優先度の変更に関する情報を取得することができる。以下では、第１のオプション、すなわち、コアネットワークから基地局にデバイス優先度指示情報を送信することについて説明する。
図４は、ＵＥにサービスを提供するＭＭＥがｅＮＢに対して利用可能なＳ１−ＡＰメッセージ（複数可）内の新しい情報要素（ＩＥ）を使用して新しい、または修正されたベアラのデバイス優先度を指示する本発明の一実施形態を例示している。
特に、端末にサービスを提供するモビリティ管理ノードなどのネットワークノード（コアネットワーク内のノード）において実行するための対応する方法は、端末に関係し端末のトラフィックが遅延耐性であるか否かを示す優先度を決定するステップを含む。図４の実施例では、優先度はベアラ毎に決定される。この決定は、ストレージから優先度を取り出すことによって、および／またはそれを、例えば「Ｄｅｖｉｃｅ Ｐｒｏｐｅｒｔｙ」と称されるＩＥを使用することによって新しいセッションを確立するときに端末から受信することによって実行され得る。
ネットワークノードによって実行されるこの方法は、基地局に、決定された優先度のインジケータを送信し、基地局が優先度に基づき輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにすることをさらに含む。
インジケータは、ネットワークノードから基地局へのＳ１−ＡＰプロトコル（３ＧＰＰによって定義されている）のメッセージに含まれ得る。Ｓ１−ＡＰメッセージは、ＬＴＥにおいてＵＥベアラの追加または修正または削除のためにＭＭＥとｅＮＢとの間で使用される。例えば、以下の既存のメッセージのうちの１つまたは複数が使用され得る。
− 初期コンテキスト・セットアップ要求（Initial Context Setup Request）
− Ｅ−ＲＡＢセットアップ要求（E-RAB Setup Request）
− Ｅ−ＲＡＢ修正要求（E-RAB Modify Request）
図４に示されているように（「アプリケーションに対するデバイス優先度」を参照）、これらのＮＡＳメッセージのそれぞれは、有利には、特定のベアラのデバイス優先度がどのようなものかをｅＮＢに指示する新しいＩＥを含むべきである。輻輳が生じた後、ｅＮＢは、どのベアラが遅延耐性を有し、上で示されているように削除／解放され得るかを決定すべきである。そのようなベアラについて、ｅＮＢは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥに送信して、対応する無線ベアラを削除することができる（「Ｒｅｌｅａｓｅ ＲＢ Ｙ」を参照）。必要ならば、同じことがｅＮＢによってＭＭＥに伝達される。特に、ｅＮＢは、ｅＮＢが無線ベアラを解放するときにベアラ解放の指示をＭＭＥに送信する。この指示は、ベアラ解放要求（Bearer Release Request）（EPS Bearer Identity）メッセージでＭＭＥに送信されるか、あるいは初期コンテキストセットアップ完了（Initial Context Setup Complete）、ハンドオーバ要求ＡＣＫおよびＵＥコンテキスト応答（Handover Request Ack and UE Context Response）、パートスイッチ要求（Part Switch Request）、または他のメッセージで送信され得る。通常優先度ベアラ（ＲＢ「Ｘ」、ベアラ「Ｘ」を参照）は、構成されたままである。
図５は、新しいＳ１−ＡＰメッセージを使用してＭＭＥからＵＥにベアラ毎のデバイス優先度がシグナリングされる本発明の例示的な一実施形態を示している。これは、利用可能な（既存の）Ｓ１−ＡＰはどれも使用されていないが、むしろ、新しいＳ１−ＡＰメッセージがＳ１−ＡＰプロトコルにおいて定義されていることを意味する。新しいメッセージは、有利には、構成されたベアラのそれぞれが低優先度ベアラであるか、通常優先度ベアラであるかをシグナリングするための情報要素を有する。これからわかるように、図５は、新しいＳ１−ＡＰメッセージ「Ｎｅｗ Ｓ１ ＡＰ ｍｅｓｓａｇｅ ｃｏｎｔａｉｎｉｎｇ ｄｅｖｉｃｅ ｐｒｉｏｒｉｔｙ ｏｆ ｔｈｅ ａｐｐｌｉｃａｔｉｏｎ」（新しいＳ１ーＡＰメッセージがアプリケーションのデバイス優先度を含む）がＭＭＥからｅＮＢに送信されるという点で図４と異なっている。
図６は、ＭＭＥがｅＮＢに対してすでに利用可能なＳ１−ＡＰメッセージ内のすでに利用可能なＩＥを再利用することによって新しい、または修正されたベアラのデバイス優先度を指示する本発明の別の実施形態を示している。例えば、ＩＥは、割り当ておよび保持優先度（ＡＲＰ）であってよい。
この実施形態では、したがって、デバイス優先度インジケータをシグナリングするためのＳ１−ＡＰメッセージは、スケジューリングを目的として割り当て／保持優先度を搬送する情報要素を含み、この情報要素は所定の範囲の値から１つの値を取るように構成される。端末のトラフィックが遅延耐性であるか否かを示す優先度の値は、所定の範囲からの１つ以上の値が、端末トラフィックが遅延耐性であることを示し、所定の範囲からの別の１つ以上の値が、端末トラフィックが遅延耐性でないことを示すように、前記所定の範囲の値にマッピングされる。マッピングは、基地局、または、端末にサービスを提供するモビリティ管理ノードによって構成され得る。基地局、または、端末にサービスを提供するモビリティ管理ノードは、構成されたマッピングを互いにそれぞれ送信することができる。
上ですでに説明されているように、何らかの情報が、新しい、または修正されたベアラ（複数可）のＱｏＳ特性を指示するために、ＭＭＥによってｅＮＢにシグナリングされる。この情報は、３ＧＰＰのウェブサイト上で無料で入手可能な、非特許文献６の９.２.１.６０節で指定されているようなＱｏＳクラス識別子（ＱＣＩ）値または割り当ておよび保持優先度（ＡＲＰ）とすることも可能である。ＡＲＰは、ベアラセットアップおよびベアラ修正時にＭＭＥによってｅＮＢに送信される。
第１の可能性は、新しい要素「ＭＴＣ優先度」を搬送するように拡張することによって「優先度レベル」、「プリエンプション能力」、「プリエンプション脆弱性」要素を含むＡＲＰ情報要素を使用することである。ＡＲＰは、ベアラセットアップおよびベアラ修正時にＭＭＥによってｅＮＢに送信される。ｅＮＢは、ＭＴＣ優先度から、確立されているベアラが低または通常優先度ベアラ（または他のもの）であると結論することが可能である。例えば、通常優先度アクセスは、既存のアクセス識別子を含まないアクセス、すなわち、「低優先度」（遅延耐性）として識別され得る。「特別なアクセスクラス１１−１５」または「緊急通話」などの「他の」何らかの既定のアクセス、すなわち、非特許文献７のアクセス禁止を目的とするクラスなどの、既存の既定のアクセスもあり得る。
以下の表は、新規に追加された（下線付きで示されている）「ＭＴＣ優先度」のＡＲＰの対応する修正された情報要素を示している。
Figure 2015525041
別の可能性は、ＡＲＰにおいて要素「優先度レベル」を再利用することである。例えば、ＡＲＰの内側の「優先度レベル」を再利用して、（新しい／修正された）アプリケーションのデバイス優先度を示すことが可能である。
これは、すでに利用可能なＩＥの値のサブセットに対して新しい意味を指定することによって、例えば、既存の「優先度レベル」値を新しいデバイス（ＭＴＣ）優先度にマッピングする、すなわち、少なくともレベル「遅延耐性」または「通常」を「優先度レベル」値にマッピングすることによって達成され得る。
可能な一例は以下のとおりとすることができる。
− 優先度レベル０から５：低優先度（例えば、ＭＴＣデバイスまたはＭＴＣアプリケーションを実行するベアラ）
− 優先度レベル６から１５：通常優先度（例えば、非ＭＴＣデバイスまたは通常の非ＭＴＣアプリケーションを実行するベアラ）
これは、一例にすぎず、優先度レベルの割り当ては、別の方法で選択することができることに留意されたい。例えば、ｍを０からＭ−１までの整数として（Ｍは最大値、この例ではＭ＝１５）、優先度レベル０からｍは、低優先度を指示し、残りのｍ＋１からＭ個の値は通常優先度を指示する。あるいは、「その他」などのデバイス優先度の別のレベル（複数可）または既定のアクセスクラスに対応する特定の優先度レベルを定義することができる。
ＡＲＰの「優先度レベル」ＩＥへのデバイス優先度のマッピングは、標準で定義済みであるものとしてよい。しかし、これも構成可能であり得る。これは、ＭＭＥとｅＮＢとの間で、すでに利用可能なＩＥの値のサブセットに対する新しい意味を構成することによって達成され得る（例えば、上記の例における優先度レベル）。
これは、図６に示されており、Ｓ１セットアップ時に、優先度レベルとデバイス優先度構成との間の可能なマッピングが、ｅＮＢとＭＭＥとの間で行われる。これは、矩形「Ｓ１ ＡＰセットアップ：優先度レベルおよびデバイス優先度のマッピング／構成」によって例示されている。この交換は、ｅＮＢからＭＭＥへの方向（ｅＮＢがマッピングを構成し、それをＭＭＥに送信する）またはその逆の方向（ＭＭＥがマッピングを構成し、それをｅＮＢに送信する）で行うことができる。
その後、ｅＮＢは、優先度レベルの値を解釈して、新しい、または修正されたアプリケーションもしくはベアラが遅延耐性もしくは通常（または場合によっては、他の所定のレベル）であるかを調べる。これは、ｅＮＢ側の機能ボックス「ＡＲＰの優先度レベルフィールドからデバイス優先度をマッピングする」によって示されている。解釈に従って、輻輳が生じている場合に、低優先度ベアラが解放され得る。そのような低優先度ベアラ（図中で、ベアラ「Ｙ」）について、ｅＮＢは、ＲＲＣ接続再構成をＵＥに送信して、対応する無線ベアラ（ＲＢ）を削除する。必要ならば、同じことがｅＮＢによってＭＭＥに通知される。
上記の説明において、デバイス優先度は、ベアラ毎の、すなわち、ベアラによって搬送されるアプリケーショントラフィック毎の、デバイス優先度を示すものとして図示されている。しかし、本発明は、それに限定されない。本発明の別の実施形態によれば、（優先度）インジケータは、すべての構成されているベアラを含む端末の全体的優先度であるデバイス優先度を示す。好ましくは、端末の全体的優先度は、端末の構成済みベアラ（実行されているアプリケーション）の優先度の最大値として定義される。
図７は、ＭＭＥから全体的優先度の基地局へのシグナリングを示している。
代替的形態の一部として、ＭＭＥからｅＮＢへの上記の指示（デバイス優先度に関する）は、「ＵＥ毎の」デバイス優先度が変更されたときにのみ存在する。アプリケーション／ベアラに適用されたときの「デバイス優先度」という用語は、アプリケーション／ベアラが遅延耐性であるかないかを示す。アプリケーション／ベアラが、遅延耐性である場合、これは、輻輳が生じたときにｅＮＢによって削除される可能性がある。アプリケーションは遅延耐性を有しているため、ある程度の遅延に耐えることができ（ネットワークサービスを受ける際に）、したがって、取り除いた後、ＵＥは、指定された時間の間に、そのようなアプリケーションによるネットワークへの接続要求を開始すべきでない（例えば、「ＥｘｔｅｎｄｅｄＡｃｃｅｓｓＢａｒｒｉｎｇタイマ」によるＬＴＥ ＲＲＣ指定を仮定する）。
デバイスに適用されたときの「デバイス優先度」という用語は、デバイスの「全体的」遅延耐性を意味する。複数のアプリケーション／ベアラがアクティブである場合、デバイスの「全体的」遅延耐性は、最小遅延耐性アプリケーション／ベアラの遅延耐性に等しいものとする。例えば、ＵＥにおいて２つのアプリケーション／ベアラがアクティブであり、その一方が遅延耐性を有し、他方は遅延耐性を有していない場合、デバイスに適用されたときの「デバイス優先度」は、デバイスの「全体的」優先度（遅延耐性）が「通常」であることを意味することになる。
この観点から、デバイス優先度の「ＵＥ毎の」指示は、デバイスの「全体的」優先度（遅延耐性）を指す。上で示されているように、Ｓ１−ＡＰメッセージは、新しい、または既存のＳ１−ＡＰメッセージを使用して（現在の）優先度または優先度の変更を示すべきである。
したがって、ネットワークの観点からは、優先度は「ＵＥ毎」の優先度である、すなわち、無線ネットワーク側では、ＵＥ（ＲＲＣ接続要求の確立原因値、または別の実施形態について以下で説明されているように）またはＭＭＥ（上記の実施形態で説明されているように）のいずれかから利用可能な最近の情報に基づきＵＥを低優先度ＵＥまたは通常優先度ＵＥのいずれかとみなす。ＵＥは、ＲＲＣ接続確立メッセージにおいてモバイル発信（ＭＯ）呼に対して低優先度アクセスを指示し（「ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ」を「ｄｅｌａｙＴｏｌｅｒａｎｔＡｃｃｅｓｓ」として設定することによって）、したがって、無線ネットワーク側ではこのＵＥを低優先度ＵＥとして分類し、そうでない場合（他の「ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ」により）ＵＥは通常優先度ＵＥとみなされる。
これは、ＵＥを保持する、またはＵＥを解放する決定は、ＵＥのＲＲＣ接続に対して全体として下されることを意味し、（例えば）低優先度アプリケーションに対するベアラのみを解放するのではない。
図７は、デバイス優先度が端末のアプリケーション／ベアラではなく端末に割り当てられた全体的優先度であると仮定したメッセージの流れの一例を示している。
この例は、ＵＥが低優先度（遅延耐性）アプリケーションでネットワークにアクセスしている状況を示している。したがって、ＵＥは、ＲＲＣ接続要求を原因「遅延耐性アクセス」でｅＮＢに送信する。次いで、ＵＥは、通常優先度を有するアプリケーションを追加し、そこでベアラ修正手順が開始され、新しい通常優先度ベアラが追加される。上で説明されているように、この実施形態では、デバイス優先度は、ＵＥに割り当てられ、その特定のベアラには割り当てられない。ＭＭＥは、ＵＥによって実行されるアプリケーションの優先度に関して通知を受ける。特に、ＵＥは、低優先度アプリケーションを実行しただけなので、低優先度ＵＥとして起動される。次いで、通常優先度アプリケーションが追加されており、その結果、ＵＥの全体的優先度は通常優先度に変更される。
より高い（最高の）優先度を取ることには、輻輳が生じた場合に、通常のアプリケーションのリソースが、同じ端末で低優先度アプリケーションも動作しているという理由だけで不足してしまうことがないという利点がある。
図７からわかるように、変更された−現在通常の−優先度は、Ｓ１−ＡＰメッセージ内でＭＭＥからＵＥにシグナリングされる。Ｓ１−ＡＰメッセージは、図４から６を参照しつつ説明されている上記の実施形態に示されているように既存の、または新しいＳ１−ＡＰメッセージであるものとしてよい。これは、図７において、「新しいＳ１ ＡＰメッセージが全体的デバイスに対して現在のデバイス優先度を含む」によって例示されている。この例の現在のデバイス優先度は、非遅延耐性デバイス（端末）であることを示す通常デバイス優先度である。したがって、ネットワークに輻輳が生じている場合、ＲＲＣ接続は解放されず、この実施形態ではデバイス優先度はＵＥ毎に適用可能であり、この例ではデバイス優先度は遅延耐性であるアプリケーションが少なくとも１つあるので「通常」であるため、低デバイス優先度ベアラですら維持される。一般に、「ｎ」個のアプリケーション／ベアラが一度にアクティブである場合、ＵＥ毎に適用可能なデバイス優先度は、遅延耐性を有するアプリケーション／ベアラが少なくとも１つある限り「通常」である。
これは、一例にすぎず、可能な例示的な実施形態はさらにあることに留意されたい。例えば、全体的デバイス優先度は、複数の低優先度アプリケーションが動作していて、高々１つが通常アプリケーションであるなどの場合に低であると判定され得る。一般に、全体的デバイス優先度では、２つより多いレベル（通常、低）を区別することができる。したがって、この区別は、低優先度アプリケーションの数と動作している通常優先度アプリケーションの数とに基づき実行され得る。例えば、動作している低優先度アプリケーションと高優先度アプリケーションとの比を使用して、優先度レベルを判定することができる。特に、デバイス優先度を既存のＡＲＰ優先度レベルにマッピングする場合、この区別は、シグナリングのオーバーヘッドを増やすことなく容易に実装可能である。
上記の実施形態では、デバイス優先度は、ＭＭＥから基地局に指示されている。以下の実施形態において、ベアラ毎もしくは端末毎のデバイス優先度の変更について、またはベアラ毎の現在の優先度について基地局に通知するのは端末である。
本発明の例示的な一実施形態によれば、アプリケーション（ベアラ）の追加または削除は、端末が疑似命令を使って説明されている以下の手順を実行するトリガとなる。
RECEIVE (new_event);
If (new_event != NULL)
If （優先度の変更がUSIM構成から許される)
If addition_of_new_application
If this_app_priority > current_priority
current_priority = new_app_priority;
SEND current_priority to eNB;
Else (既存のAppの解放)
temp_priority = max(remaining app priority);
if this_app_priority > temp_priority
current_priority = temp_priority;
SEND current_priority to eNB;
}
}
} (優先度の変更が許されていない場合には何もしない)
}
ここで、「ｃｕｒｒｅｎｔ＿ｐｒｉｏｒｉｔｙ」は、ｅＮＢに最後にシグナリングされたデバイス優先度を表し、「ｔｈｉｓ＿ａｐｐ＿ｐｒｉｏｒｉｔｙ」は、注目しているアプリケーション／ベアラの優先度を表す。
特に、「ｎｅｗ＿ｅｖｅｎｔ」は、新しいアプリケーションに対するベアラの修正または追加である。デバイスが二重優先度デバイスである場合、すなわち、優先度の変更が許されているときに、新しいアプリケーションが現在の優先度より高い優先度で追加された場合、現在の優先度はより高い優先度に変わる。そうでない場合（「ｅｌｓｅ」）、すなわち、ベアラ／アプリケーションが削除されたとき（「既存のａｐｐの解放」）、デバイス優先度は、残りのアプリケーションの優先度の最大数として判定される。判定されたデバイス優先度は、基地局に送信される。したがって、ｅＮＢは、新しいデバイス優先度を構成された優先度の最大（追加の場合には現在＋新、または削除の場合には残り）として計算し、新しいデバイス優先度に基づきＲＲＣ接続を取り扱う。ｅＮＢは、それぞれのベアラの優先度を別々に知るので、これは、必要ならば個別のベアラ（ＲＲＣ接続全体の代わりに）−上記の実施形態においてすでに説明されているように、特に図２および３を参照しつつ説明されているもの−を解放することを決定することができる。
ＵＥは、前の実施形態で説明されているＭＭＥと同様に、全体的優先度、または−代替的に−アプリケーション毎の（ベアラ毎の）デバイス優先度のいずれかをシグナリングすることもできることに留意されたい。したがって、ＵＥは、ｅＮＢに対してそれぞれの新しいアプリケーションまたはベアラのデバイス優先度（通常／遅延耐性）を指示することができる。次いで、ｅＮＢは、受け取ったデバイス優先度を無線ベアラとＥＰＳベアラの両方のベアラ識別子（ＩＤ）にマッピングする。無線ベアラは、無線アクセスネットワークのベアラであるが、ＥＰＳベアラは、コアネットワークのベアラである。
さらに、本文書では、「ベアラ」という用語は一般的用語であり、データベアラおよび／またはシグナリングベアラを指すことに留意されたい。さらに、これは、無線ベアラも、またＥＰＳベアラも指す。特に、「ベアラ」という用語は、対応するアプリケーションに必要な通信手段およびトラフィック特性を含む。
新しいデバイス優先度の指示は、ＵＥによって、既存メッセージを使用するか、または新しいメッセージを指定することによって送信され得る。指示は、好ましくは、ＲＲＣプロトコルを使用して送信される。
図８は、新しいデバイス優先度（「初期アクセスの後に変更される」という意味で新しい）が、ＲＲＣ接続要求メッセージに含まれる一例を示している。ＲＲＣ接続確立の後に、端末のＮＡＳがデバイス優先度変更のイベントを検出した場合、これは、新しい優先度を示す原因とともにＲＲＣ接続要求を発行する。次いで、ｅＮＢは、輻輳状態にあるときに、図２および３に示され、上で説明されているように決定を実行することができる。特に、ｅＮＢは、低優先度（ＬＰ）デバイスまたは無線ベアラについてそれぞれ、「ＲＲＣ接続解放」を使って接続を解放するか、または「無線ベアラ解放（Radio Bearer Release）」を使って無線ベアラを解放することを決定することができる。したがって、無線ベアラの解放は、ＭＭＥに指示される。
図９は、新しいデバイス優先度をシグナリングするためにＲＲＣ接続要求を利用せず、むしろＲＲＣ接続再確立を利用するという点で図８の例と異なる、別の例を示している。
ＲＲＣ接続要求または再確立要求の送信は、通常、これらの初期メッセージとは別に、ＵＥとｅＮＢとの間のメッセージのさらなる交換を含む各接続セットアップ（Connection Setup）手順および接続再確立（Connection Reestablishment）手順で接続される。
図１０は、左側部分に、この実施形態による新しい優先度を指示するために使用される典型的なＲＲＣ接続再確立手順を例示している。ＵＥは、ｅＮＢに、「ＲＲＣ接続再確立要求（RRC Connection Reestablishment Request）」を−例えば、ここでは、この実施形態による原因「優先度の変更」で−送信し、ｅＮＢは、「ＲＲＣ接続再確立」で応答して要求された再確立を実行するようにＵＥに指令し、最終的に、ＵＥは、「ＲＲＣ接続再確立完了（RRC Connection reestablishment Complete）」メッセージで応答して再確立が完了したことを指示する。
しかし、ＲＲＣ接続再確立手順全体が、必ずしも実行される必要はない。ＲＬＦ／Ｔ３１０／Ｔ３１１フェーズは必要なく、ＵＥは、セル選択を実行する必要がない。また、ｅＮＢからの「ＲＲＣ接続再確立」メッセージおよびＵＥ側からの「ＲＲＣ接続再確立完了」は、必ずしもこの実施形態の目的に必要でない。ｅＮＢによる新しい優先度の指示の受信を確認するために、レイヤ２（Ｌ２）応答で十分であり得る。したがって、本実施形態は、以下の再確立手順ステップがない場合のみ「ＲＲＣ接続再確立要求」によって実装され得る。これには、必要なシグナリングの量を減らし、手順の遅延を短縮するという利点がある。
同様に、既存のＲＲＣ接続セットアップ手順は不要なものが削られ、したがって、この実施形態において効率よく使用することができる。例えば、ネットワークからの対応する応答メッセージは、本発明の目的には、すなわち、ｅＮＢへの新しいデバイス優先度の指示にはもはや必要ない。しかし、ネットワーク側では、再利用されるメッセージを処理／破棄するかを決定することができる必要があり、いくつかの変更が手順に導入されるものとしてよい。
ＭＭＥは、例えば、初期コンテキストセットアップ要求において、ＵＥのＤＰＡ（二重優先度アプリケーション）能力を送信する。ｅＮＢは、ＤＰＡ対応ＵＥのテーブルを維持し、これらのＵＥのＣＲＮＴＩを関連付ける。ＵＥは、ＲＲＣ接続要求をＳＲＢ１（ＤＣＣＨ）でのみ送信して、確立原因をしかるべく設定することによってデバイス優先度を遅延耐性から通常またはその逆に変更する。ネットワーク（基地局）は、接続モードのＵＥからＲＲＣ接続要求を受信した後に、ＤＰＡ対応テーブル内でそのエントリが利用可能であるか否かを調べる。利用可能であれば、メッセージを処理し、「確立原因」に基づきＭＴＣ優先度変更を記録するものとする。利用可能でなければ、ＲＲＣ接続要求メッセージを破棄すべきである。
次いで、ＵＥは、ＲＲＣ接続要求のみを送信して、確立原因をしかるべく設定することによってデバイス優先度を遅延耐性から通常またはその逆に変更する。ネットワーク（ｅＮＢ）は、接続モードのＵＥからＲＲＣ接続要求を受信した後に、これが「確立原因」を調べた後に再確認するデバイス優先度を変更するために送信されたと仮定するものとする。したがって、ネットワークは、さらなるメッセージ、特にＲＲＣ接続セットアップ（RRC Connection Setup）またはＲＲＣ接続再確立メッセージを送信せず、またセットアップまたは再確立の完了に関して端末からさらなる確認を予期しない。
したがって、図１０の右側部分は、既存の「ＲＲＣ接続要求」を使って接続モードのＵＥからｅＮＢにデバイス優先度を指示するための縮小された手順を示している。同様に、「ＲＲＣ接続再確立」を使用する手順も縮小できる。
デバイス優先度インジケータをシグナリングする別の可能性は、新しいＲＲＣメッセージをこの目的のために指定することである。図１１は、このアプローチを示している。図１１は、異なる目的で既存のＲＲＣメッセージを再利用するのではなく優先度の変更を指示する「新しいＲＲＣメッセージ」を示すことによって図９および１０と異なる。これと、さらには図９および１０の前の例では、デバイス優先度は、アプリケーション毎に（ベアラ毎に）または端末毎に、すなわち、すべての端末のベアラについて１つ、シグナリングされ得る。
図１２は、発明の一実施形態による全体的動作をまとめたものであり、異なるネットワークノードに対する手順の影響を示している。特に、ＵＥ側で実行されるステップ０は、ＵＥによるデバイス優先度の判定（確立）を指し、これは、例えばアプリケーション（バリア）の追加または削除によってトリガされ得る。本発明により、基地局は、端末またはネットワークノード（ＵＥ、ＭＭＥ）のいずれかから現在の、または新しい優先度に関して通知を受ける。したがって、ネットワークに輻輳が生じた場合、上で説明されているように、ステップ２が基地局で実行される、すなわち、基地局は、ＲＲＣ接続および／または特定のバリアを解放するか、または維持するかの決定を下す。基地局が、ＲＲＣ接続または無線バリアを解放すると決定した場合、ＲＲＣ接続解放またはＲＲＣ無線バリア解放手順が開始され、解放されるべきと決定された低優先度バリアに対してＵＥとｅＮＢとの間で実行される。さらに、無線バリアの解放、または接続は、ネットワーク、すなわち、端末およびＳ−ＧＵＵにサービスを提供するＭＭＥを含むコアネットワークに指示される。
上記の説明および図からわかるように、本発明は、端末、基地局、またはネットワークノードによって実装される。したがって、これらの通信デバイスは、図１３に示されている機能構造を有する。特に、基地局１３１０は、無線リソース管理を適切に実行できるように、端末に関係するデバイス優先度のインジケータを受信し、端末のトラフィックが遅延耐性であるか否かを指示するための受信ユニット１３１２を備える。上で説明されているように、端末１３３１のトラフィックは、対応する特定のデバイス優先度が与えられる特定のバリアのトラフィックであるか、または全体的デバイス優先度を１つ有する端末全体のトラフィックであってもよい。受信ユニットは、ネットワークノード１３２０から現在の優先度のインジケータを受信するか、またはネットワークノード１３２０もしくは端末１３３０のいずれかから新しい優先度のインジケータを受信する。基地局は、受信されたインジケータに基づき輻輳またはアドミッション制御を含む無線リソース管理タスクを実行するための無線リソース管理ユニット１３１５をさらに備える。特に、無線リソース管理ユニットは、ネットワークに輻輳が生じた場合に低優先度バリアを解放するか、またはＵＥ接続を解放するかを決定することができる。同様に、デバイス優先度は、端末の新しいアプリケーション（バリア）を認めるか、または認めないかを決定するために利用され得る。
端末１３３０にサービスを提供するＬＴＥにおけるＭＭＥなどのネットワークノードは、端末に関係する優先度を決定し、端末のトラフィックが遅延耐性であるか否か（すなわち、デバイス優先度）を指示するための優先度決定ユニット１３２５を備えることができる。これは、基地局１３１０に、決定された優先度のインジケータを送信し、基地局１３１０が指示された優先度に基づき無線リソース管理タスクを実行できるようにするための送信ユニット１３２２をさらに備えることができる。ネットワークノード１３２０、端末１３３０、および基地局１３１０は、１つの通信システムを形成する。端末は、端末にサービスを提供する基地局１３１０上で、また端末１３３０にサービスを提供するネットワークノード１３２０上で通信する。
同様に、本発明の一実施形態による、通信システム内で動作することができる、端末１３３０は、端末に関係する優先度を決定し、端末のトラフィックが遅延耐性であるか否かを指示するための優先度決定ユニット１３３５を備える。これは、基地局に、優先度のインジケータを送信し、基地局が指示された優先度に基づき輻輳およびアドミッション制御を含む無線リソース管理タスクを実行できるようにするための送信ユニット１３３２をさらに備える。
上記の背景技術の節で述べた説明は、本明細書で説明されている特定の例示的な実施形態をよりよく理解できるようにすることを意図されており／よりよい理解を求めるためのものであり、本発明を３ＧＰＰ標準に準拠するネットワークなどの移動体通信網におけるプロセスおよび機能の説明されている特定の実装に制限するものとして理解されるべきでない。しかしながら、本明細書で提案されている改善は、背景技術の節で説明されているアーキテクチャ／システムに容易に適用することができ、また本発明のいくつかの実施形態では、これらのアーキテクチャ／システムの標準のおよび改善された手順を使用することもできる。当業者であれば、広い意味で説明されているように本発明の精神または範囲から逸脱することなく特定の実施形態において示されているようなさまざまな変更形態および／または修正形態が本発明に加えられ得ることを理解するであろう。
本発明の別の実施形態は、ハードウェアおよびソフトウェアを使用する上述のさまざまな実施形態の実装に関係する。本発明のさまざまな実施形態は、コンピューティング・デバイス（プロセッサ）を使用して実装されるか、または実行され得ることは理解される。コンピューティング・デバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラム可能な論理デバイスなどとすることができる。本発明のさまざまな実施形態は、これらのデバイスを組み合わせて実行または具現化することもできる。
さらに、本発明のさまざまな実施形態は、プロセッサによって、またはハードウェアで直接的に、実行される、ソフトウェアモジュールを使って実装することもできる。また、ソフトウェアモジュールとハードウェア実装との組み合わせも可能であるものとしてよい。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。
要約すると、本発明は、少なくとも１つの基地局と１つの端末とを含む通信システム内で無線リソース管理タスクを実行することに関係する。遅延耐性アプリケーションと通常アプリケーションとを同時に動作させることができる、二重優先度デバイスに対する無線リソース管理タスクを実行する際の矛盾を回避するために、デバイス優先度が変更されるときに、端末またはコアネットワークのいずれかから基地局に変更が指示される。デバイス優先度は、デバイス毎の全体的優先度として、またはそのデバイスに対して構成されているベアラ毎の優先度として指示される。

Claims (15)

  1. 基地局および端末を含む通信システムにおいて無線リソース管理を実行するための方法であって、前記方法は、前記基地局において実行され、
    前記端末にサービスを提供するモビリティ管理ノードから優先度のインジケータを受信し、または、前記端末から新しい優先度のインジケータを受信するステップであって、前記優先度は、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す、ステップと、
    前記受信したインジケータに基づいて、輻輳またはアドミッション制御を含む無線リソース管理タスクを実行するステップと、
    を含む、前記方法。
  2. 前記通信システムに輻輳が生じた場合に、無線管理タスクを実行する前記ステップは、
    前記対応する受信したインジケータが遅延耐性優先度を示している場合に、端末トラフィックを搬送するベアラおよび／または前記対応するＲＲＣ接続を削除するステップと、
    前記輻輳状態に応じて、前記対応する受信したインジケータが遅延耐性優先度を示していない場合に、端末トラフィックを搬送するベアラおよび／または前記対応するＲＲＣ接続を削除するか否かを決定するステップと、
    を含む、請求項１に記載の方法。
  3. 基地局および端末を含む通信システムにおいて無線リソース管理を実行するための方法であって、前記方法は、前記端末にサービスを提供するモビリティ管理ノードにおいて実行され、
    前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す優先度を決定するステップと、
    前記基地局に前記決定した優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにするステップと、
    を含む、前記方法。
  4. 前記インジケータは、前記端末にサービスを提供する前記モビリティ管理ノードから前記基地局へのＳ１−ＡＰプロトコルのメッセージに含まれる、
    請求項１〜３のいずれか一項に記載の方法。
  5. 前記Ｓ１−ＡＰメッセージは、初期コンテキストセットアップ要求、Ｅ−ＲＡＢセットアップ要求、およびＥ−ＲＡＢ修正要求のうちの少なくとも１つである、
    請求項４に記載の方法。
  6. 前記Ｓ１−ＡＰメッセージは、スケジューリングを目的とする割り当て／保持優先度を搬送する情報要素を含み、前記情報要素は、所定の範囲の値から１つの値を取るように構成され、
    前記端末のトラフィックが遅延耐性であるか否かを示す前記優先度の値は、前記所定の範囲からの１つ以上の前記値が、前記端末トラフィックが遅延耐性であることを示し、前記所定の範囲からの別の１つ以上の前記値が、前記端末トラフィックが遅延耐性でないことを示すように、前記所定の範囲の値にマッピングされる、
    請求項４または５に記載の方法。
  7. 前記マッピングは、前記基地局、または、前記端末にサービスを提供する前記モビリティ管理ノードによって構成され、
    前記基地局、または、前記端末にサービスを提供する前記モビリティ管理ノードは、前記構成されたマッピングを、前記端末にサービスを提供する前記モビリティ管理ノード、または、前記基地局に、それぞれ送信する、
    請求項６に記載の方法。
  8. 基地局および端末を含む通信システムにおいて無線リソース管理を実行するための方法であって、前記方法は、前記端末において実行され、
    前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す優先度を設定するステップと、
    前記基地局に前記優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにするステップと、
    を含む、前記方法。
  9. 前記端末トラフィックの前記優先度が変更される場合に、
    前記インジケータが送信される無線リソース制御、ＲＲＣ、プロトコルメッセージを生成するステップ、
    をさらに含む、請求項８に記載の方法。
  10. 前記ＲＲＣプロトコルメッセージは、ＲＲＣ接続要求またはＲＲＣ接続再確立のいずれかである、
    請求項９に記載の方法。
  11. 前記インジケータは、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す前記優先度が、前記基地局に知られている値から新しい値に変更された場合に送信され、
    前記優先度の値は、前記端末のＵＳＩＭの内容および／または前記端末のサービス品質であるＱｏＳに関するベアラ特性に依存する、
    請求項１〜１０のいずれか一項に記載の方法。
  12. 前記インジケータは、すべての構成されたベアラを含む前記端末の前記全体的優先度であるデバイス優先度を示し、前記端末の前記全体的優先度は、前記端末の構成されたベアラの前記優先度の最大値である、
    請求項１〜１１のいずれか一項に記載の方法。
  13. 基地局および端末を含む通信システムにおいて無線リソース管理を実行することができる前記基地局であって、
    前記端末にサービスを提供するモビリティ管理ノードから優先度のインジケータを受信し、または、前記端末から新しい優先度のインジケータを受信する受信ユニットであって、前記優先度は、前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す、受信ユニットと、
    前記受信されたインジケータに基づいて、輻輳またはアドミッション制御を含む無線リソース管理タスクを実行する無線リソース管理部と、
    を備える、前記基地局。
  14. ネットワークノード、基地局、および端末を含む通信システムにおいて前記端末にサービスを提供する前記ネットワークノードであって、
    前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す優先度を決定する優先度決定ユニットと、
    前記基地局に前記決定された優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにする送信ユニットと、
    を備える、前記ネットワークノード。
  15. 端末および基地局を含む通信システムにおいて動作する前記端末であって、
    前記端末に関係し、前記端末のトラフィックが遅延耐性であるか否かを示す優先度を設定する優先度決定ユニットと、
    前記基地局に前記優先度のインジケータを送信して、前記基地局が前記優先度に基づいて輻輳またはアドミッション制御を含む無線リソース管理タスクを実行できるようにする送信ユニットと、
    を備える、前記端末。
JP2015524795A 2012-08-03 2013-08-01 二重優先度アクセスのための無線リソース管理 Expired - Fee Related JP6211081B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP12179278.2A EP2693800A1 (en) 2012-08-03 2012-08-03 Radio Resource Managment for Dual Priority Access
EP12179278.2 2012-08-03
PCT/EP2013/066232 WO2014020128A1 (en) 2012-08-03 2013-08-01 Radio resource management for dual priority access

Publications (2)

Publication Number Publication Date
JP2015525041A true JP2015525041A (ja) 2015-08-27
JP6211081B2 JP6211081B2 (ja) 2017-10-11

Family

ID=48914306

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015524795A Expired - Fee Related JP6211081B2 (ja) 2012-08-03 2013-08-01 二重優先度アクセスのための無線リソース管理

Country Status (4)

Country Link
US (1) US9420589B2 (ja)
EP (2) EP2693800A1 (ja)
JP (1) JP6211081B2 (ja)
WO (1) WO2014020128A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190005990A (ko) * 2016-05-12 2019-01-16 후아웨이 테크놀러지 컴퍼니 리미티드 데이터 전송 방법, 장치, 및 시스템

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6239280B2 (ja) * 2013-06-27 2017-11-29 京セラ株式会社 ユーザ端末、プロセッサ及び移動通信システム
UA116025C2 (uk) * 2013-07-04 2018-01-25 Нек Корпорейшн Система, спосіб і пристрій зв'язку
KR102170503B1 (ko) * 2014-01-13 2020-10-28 삼성전자주식회사 이동통신시스템에서의 호출장치 및 방법
US9648658B2 (en) * 2014-02-28 2017-05-09 Verizon Patent And Licensing Inc. Managing radio resource control (RRC) connections based on radio bearer attributes
US10194303B2 (en) * 2014-03-14 2019-01-29 Qualcomm Incorporated Packet filter based access control
US9906977B2 (en) 2014-04-18 2018-02-27 Apple Inc. Deterministic RRC connections
US10375646B2 (en) 2014-04-18 2019-08-06 Apple Inc. Coordination between application and baseband layer operation
US9497771B2 (en) 2014-04-18 2016-11-15 Apple Inc. Deterministic RRC connections
WO2015176268A1 (zh) * 2014-05-22 2015-11-26 华为技术有限公司 一种用户设备节约电量的方法和设备
EP3155860B1 (en) * 2014-06-16 2021-02-24 Telefonaktiebolaget LM Ericsson (publ) Configuration of a service at a base station
WO2015193751A1 (en) * 2014-06-16 2015-12-23 Telefonaktiebolaget L M Ericsson (Publ) Service aware admission control of radio bearers
WO2016004102A2 (en) 2014-07-02 2016-01-07 Intel IP Corporation Apparatuses, systems, and methods for paging enhancements for low complexity user equipment
US9516652B2 (en) 2014-08-11 2016-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Pre-emption and resource allocation prioritization for D2D communications
US20160100353A1 (en) * 2014-10-01 2016-04-07 Industrial Technology Research Institute Method of dynamic admission control applicable to prose server and user equipment and related apparatuses using the same
US20170318512A1 (en) * 2014-11-21 2017-11-02 Nec Corporation Communication device, communication method, communication system, and storage medium
US10440626B2 (en) * 2015-03-20 2019-10-08 Parallel Wireless, Inc. Content-aware inter-RAT RAB steering
US10382904B2 (en) 2015-06-29 2019-08-13 Samsung Electronics Co., Ltd. Method and apparatus for providing service in a wireless communication system
US10362011B2 (en) 2015-07-12 2019-07-23 Qualcomm Incorporated Network security architecture
EP3509337B1 (en) 2015-08-14 2021-06-02 Telefonaktiebolaget LM Ericsson (publ) A node and method for managing a packet data network connection
US20190082350A1 (en) * 2015-09-24 2019-03-14 Lg Electronics Inc. Method and device by which prioritized service is transmitted
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
JP2019068111A (ja) * 2016-02-09 2019-04-25 株式会社Ｎｔｔドコモ ユーザ装置及び通信方法
US10757749B2 (en) * 2016-04-01 2020-08-25 Telefonakiebolaget Lm Ericsson (Publ) Methods, apparatuses and computer readable media for optimizing radio resource control RRC connectivity
US10154512B2 (en) * 2016-06-10 2018-12-11 Alcatel Lucent System and methods for MAC layer scheduling in wireless communication networks
WO2018027995A1 (zh) * 2016-08-12 2018-02-15 华为技术有限公司 一种寻呼方法和寻呼设备
JP6623996B2 (ja) * 2016-09-26 2019-12-25 横河電機株式会社 処理装置、ネットワーク装置、処理装置の制御方法、ネットワーク装置の制御方法、処理装置の制御プログラム、ネットワーク装置の制御プログラム及び記録媒体
CN108289065B (zh) 2017-01-10 2022-01-14 华为技术有限公司 数据处理方法、装置和系统
KR20180082912A (ko) 2017-01-11 2018-07-19 삼성전자주식회사 무선 통신 시스템에서 트래픽을 제어하기 위한 장치 및 방법
US11064556B2 (en) * 2018-05-09 2021-07-13 Nokia Solutions And Networks Oy Configuring radio resource control connections
WO2020029674A1 (en) * 2018-08-10 2020-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for improving data management service in interworking networks
CN109195224B (zh) * 2018-10-12 2023-05-02 南方电网科学研究院有限责任公司 一种智能配用电业务的无线通信资源分配系统及方法
CN112889322A (zh) * 2018-12-20 2021-06-01 Oppo广东移动通信有限公司 一种资源调度方法、终端设备及网络设备
WO2024088528A1 (en) * 2022-10-26 2024-05-02 Nokia Technologies Oy Enhanced radio resource control re-establishment procedure for cellular communication networks

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110287765A1 (en) * 2010-05-04 2011-11-24 Vodafone Ip Licensing Limited Operation of machine-type communication devices
WO2012063039A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Infrastructure equipment and method
WO2012063041A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Infrastructure equipment and method
WO2012063037A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Infrastructure equipment and method for determining a congestion state
WO2012063040A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Mobile communications network, infrastructure equipment, mobile communications device and method
WO2012063038A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Mobile communications device and method
WO2012063042A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Mobile communications network, infrastructure equipment, mobile communications device and method
JP2012114857A (ja) * 2010-11-26 2012-06-14 Ntt Docomo Inc 通信制御システム及び通信制御方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050107107A1 (en) * 2003-11-19 2005-05-19 Reza Shahidi Dynamic voice over data prioritization for wireless communication networks
JP4927940B2 (ja) * 2006-04-19 2012-05-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） セルラ・アクセス・システムにおける改良されたデータ通信のための方法および装置
WO2010121204A1 (en) * 2009-04-17 2010-10-21 Research In Motion Limited Mechanisms for evolved packet system quality of service class identifier extension
US8554216B2 (en) * 2010-04-30 2013-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Devices for congestion control
US9295088B2 (en) * 2010-11-08 2016-03-22 Lg Electronics Inc. RRC connection method and device therefor in wireless communication system
US9532278B2 (en) * 2011-09-28 2016-12-27 Lg Electronics Inc. Method and apparatus for transmitting establishment cause value in wireless communication system
TWI653872B (zh) * 2011-12-14 2019-03-11 內數位專利控股公司 觸發類型通訊應用方法及裝置
JP2013258525A (ja) * 2012-06-12 2013-12-26 Hitachi Ltd 無線通信システム、ゲートウェイ装置、及びデータ配信方法
US9585054B2 (en) * 2012-07-19 2017-02-28 Interdigital Patent Holdings, Inc. Method and apparatus for detecting and managing user plane congestion
WO2014013661A1 (ja) * 2012-07-20 2014-01-23 日本電気株式会社 コアネットワークノード、無線端末、輻輳制御のための方法、及び非一時的なコンピュータ可読媒体
WO2015117652A1 (en) * 2014-02-06 2015-08-13 Telefonaktiebolaget L M Ericsson (Publ) Multi-bearer connection control

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110287765A1 (en) * 2010-05-04 2011-11-24 Vodafone Ip Licensing Limited Operation of machine-type communication devices
WO2012063039A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Infrastructure equipment and method
WO2012063041A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Infrastructure equipment and method
WO2012063037A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Infrastructure equipment and method for determining a congestion state
WO2012063040A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Mobile communications network, infrastructure equipment, mobile communications device and method
WO2012063038A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Mobile communications device and method
WO2012063042A1 (en) * 2010-11-08 2012-05-18 Wireless Technology Solutions Llc Mobile communications network, infrastructure equipment, mobile communications device and method
JP2012114857A (ja) * 2010-11-26 2012-06-14 Ntt Docomo Inc 通信制御システム及び通信制御方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190005990A (ko) * 2016-05-12 2019-01-16 후아웨이 테크놀러지 컴퍼니 리미티드 데이터 전송 방법, 장치, 및 시스템
JP2019515595A (ja) * 2016-05-12 2019-06-06 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． データ伝送方法、装置、及びシステム
US10945143B2 (en) 2016-05-12 2021-03-09 Huawei Technologies Co., Ltd. Data transmission method, apparatus, and system
KR102248452B1 (ko) 2016-05-12 2021-05-04 후아웨이 테크놀러지 컴퍼니 리미티드 데이터 전송 방법, 장치, 및 시스템

Also Published As

Publication number Publication date
EP2880903B1 (en) 2019-07-24
US9420589B2 (en) 2016-08-16
JP6211081B2 (ja) 2017-10-11
US20150141030A1 (en) 2015-05-21
EP2693800A1 (en) 2014-02-05
WO2014020128A1 (en) 2014-02-06
EP2880903A1 (en) 2015-06-10

Similar Documents

Publication Publication Date Title
JP6211081B2 (ja) 二重優先度アクセスのための無線リソース管理
EP3606115B1 (en) Method for interaction between layers in wireless communication system and apparatus therefor
US11700667B2 (en) Control plane cellular internet-of-things (IOT) optimization indication
US11606734B2 (en) Handover method in wireless communication system and apparatus therefor
US12082284B2 (en) Method for registering terminal in wireless communication system and apparatus therefor
EP3713370A1 (en) Wireless communications for communication setup/response
KR102047708B1 (ko) 요청에 대한 응답 방법 및 네트워크 장치
KR102241996B1 (ko) 무선 통신 시스템에서 네트워크간 상호연동 방법 및 이를 위한 장치
KR102201279B1 (ko) 무선 통신 시스템에서의 등록 해제 방법 및 이를 위한 장치
CN109155909B (zh) 无线通信系统中用于更新ue配置的方法及其装置
KR102047058B1 (ko) 무선 통신 시스템에서의 반영형 서비스 퀼리티 적용 방법 및 이를 위한 장치
JP6696580B2 (ja) データ伝送のための制御プレーンおよびユーザプレーンの選択
US20200413241A1 (en) Method for terminal setting update in wireless communication system and apparatus therefor
CN107211345B (zh) 用于高优先级应用的接入控制
US20200053803A1 (en) Method for selecting session and service continuity mode in wireless communication system and device therefor
CN110999522A (zh) 用于无线设备的服务间隙控制
US20180160331A1 (en) Method and terminal for transmitting data traffic in wireless communication system
JP2022524165A (ja) Ｒａｎページング処理
US10880714B2 (en) Access control and scheduling mechanism for MTC devices
CN103428888B (zh) 一种直通隧道建立方法及系统

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160614

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170515

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170523

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170814

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170905

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170912

R150 Certificate of patent or registration of utility model

Ref document number: 6211081

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees