JP7008700B2 - 通信ネットワークにおけるネットワークノード、無線デバイス、およびその中における方法 - Google Patents

Description

本開示は、一般に、ネットワークノードによって送信された設定情報を、無線デバイスがマルチキャスト制御チャネルから取得することを可能にするための、ネットワークノード、無線デバイス、およびその中における方法に関する。

典型的な無線通信ネットワークでは、無線通信デバイス、移動局、局（ＳＴＡ）、および／または、ユーザ機器（ＵＥ）としても知られている無線デバイスは、無線アクセスネットワーク（ＲＡＮ）を介して、無線ネットワークの１つまたは複数のコアネットワーク（ＣＮ）と通信する。ＲＡＮは、サービスエリアまたはセルエリアに分割される地理的エリアをカバーし、これらはビームまたはビームグループとも称され、各サービスエリアまたはセルエリアは、たとえば、Ｗｉ－Ｆｉアクセスポイントまたは無線基地局（ＲＢＳ）のように、いくつかのネットワークでは、たとえば、「ＮｏｄｅＢ」または「ｅＮｏｄｅＢ」とも表され得る、無線アクセスノードのような無線ネットワークノードによってサーブされる。サービスエリアまたはセルエリアは、無線カバレッジが無線ネットワークノードによって提供される地理的エリアである。無線ネットワークノードは、無線ネットワークノードの範囲内の無線デバイスと無線周波数で動作するエアインターフェースを介して通信する。

本開示では、「無線デバイス」という用語は、無線信号を送受信することによって、ＲＡＮのような無線ネットワークと無線通信することができる任意の通信エンティティを表すために使用される。たとえば、本明細書に記載の無線デバイスは、モバイル電話、タブレット、ラップトップコンピュータ、および／または、マシン型通信（ＭＴＣ）デバイスとしても知られるマシンツーマシン（Ｍ２Ｍ）デバイスであり得る。この分野における別の一般的な用語は「ユーザ機器（ＵＥ）」であり、これは本明細書では無線デバイスの同義語として頻繁に使用されている。

さらに、「ネットワークノード」という用語は、無線インターフェースを介して無線デバイスと通信し、様々なチャネルで情報を送信するために動作可能な、ＲＡＮのような無線ネットワークの任意のノードを表すために本明細書で使用される。本開示におけるネットワークノードは、無線信号を無線デバイスと通信する基地局、無線ノード、ＮｏｄｅＢ、基地トランシーバ局、アクセスポイント等を称し得る。

Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）は、第２世代（２Ｇ）グローバル移動体通信システム（ＧＳＭ）から発展した第３世代（３Ｇ）通信ネットワークである。ＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）は、本質的に、ユーザ機器のために広帯域符号分割多元接続（ＷＣＤＭＡ）および／または高速パケットアクセス（ＨＳＰＡ）を使用するＲＡＮである。第３世代パートナーシッププロジェクト（３ＧＰＰ）として知られるフォーラムでは、電気通信供給業者は、第３世代ネットワークの規格を提案し合意し、向上したデータレートおよび無線容量を調査する。一部のＲＡＮでは、ＵＭＴＳにおけるように、いくつかの無線ネットワークノードは、接続されている複数の無線ネットワークノードの様々なアクティビティを監督および調整する、無線ネットワークコントローラ（ＲＮＣ）または基地局コントローラ（ＢＳＣ）のようなコントローラノードに、たとえば固定電話またはマイクロ波によって、接続され得る。このタイプの接続は、時に、バックホール接続とも称される。ＲＮＣおよびＢＳＣは通常、１つまたは複数のコアネットワークに接続されている。

第４世代（４Ｇ）ネットワークとも呼ばれるエボルブドパケットシステム（ＥＰＳ）の仕様は、第３世代パートナーシッププロジェクト（３ＧＰＰ）内で完了しており、この作業は、たとえば第５世代（５Ｇ）ネットワークを規定するために、今後の３ＧＰＰリリースでも継続する。ＥＰＳは、ロングタームエボリューション（ＬＴＥ）無線アクセスネットワークとしても知られる拡張ユニバーサル地上無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ）、およびシステムアーキテクチャエボリューション（ＳＡＥ）コアネットワークとしても知られるエボルブドパケットコア（ＥＰＣ）を備える。Ｅ－ＵＴＲＡＮ／ＬＴＥは、３ＧＰＰ無線アクセスネットワークの変形であり、無線ネットワークノードは、ＲＮＣにではなくＥＰＣコアネットワークにダイレクトに接続されている。一般に、Ｅ－ＵＴＲＡＮ／ＬＴＥでは、ＲＮＣの機能は、たとえばＬＴＥにおけるｅＮｏｄｅＢのような無線ネットワークノードと、コアネットワークとの間に分散される。このため、ＥＰＳのＲＡＮは、１つまたは複数のコアネットワークにダイレクトに接続された、すなわち、ＲＮＣに接続されていない、無線ネットワークノードを備えた本質的に「フラット」なアーキテクチャを有している。上記を補償するために、Ｅ－ＵＴＲＡＮ仕様は、無線ネットワークノード間の直接インターフェースを定義し、このインターフェースはＸ２インターフェースと表される。ＥＰＳは、エボルブド３ＧＰＰパケット交換ドメインを表す。

３ＧＰＰでは、最近、マシンツーマシン（Ｍ２Ｍ）および／またはモノのインターネット（ＩｏＴ）関連の使用事例を取り扱い、サポートするための技術を指定することに関して多くの作業が行われてきた。３ＧＰＰリリース１３に関する最新の作業は、最大６つの物理リソースブロック（ＰＲＢ）からなる低域帯域幅をサポートする、新たなＵＥカテゴリであるＭ１（Ｃａｔ－Ｍ１）を備えたマシン型通信（ＭＴＣ）をサポートするための強化と、新たな無線インターフェース（およびＵＥカテゴリＮＢ１（Ｃａｔ－ＮＢ１））を指定する狭帯域ＩｏＴ（ＮＢ－ＩｏＴ）作業項目とを含む。

ＭＴＣのための３ＧＰＰリリース１３で導入されたＬＴＥ強化は、ここでは、「ｅＭＴＣ」と称され、限定されないが、帯域制限されたＵＥ（Ｃａｔ－Ｍ１）のサポート、およびカバレッジ強化のサポートを含む。サポートされている特徴は一般的なレベルで類似しているが、これはＮＢ－ＩｏＴからの議論を分けるためである。

「レガシー」ＬＴＥと、ＮＢ－ＩｏＴの場合と同様に、ｅＭＴＣ手順のために規定された手順およびチャネルとの間には多くの相違点がある。いくつかの重要な相違点は、ｅＭＴＣで使用される場合はＭＰＤＣＣＨ、ＮＢ－ＩｏＴで使用される場合はＮＰＤＣＣＨと呼ばれる、新たな物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を含む。したがって、「レガシーＬＴＥ」という用語は、基本的に、上述したＬＴＥ強化およびｅＭＴＣ手順が導入される前に開発されたＬＴＥ技術を示す。

ＬＴＥ仕様では、マルチキャストおよびブロードキャストサービスは、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）の下で指定されており、指定されたエリア内の多数のＵＥへの同じコンテンツの同時の送信を可能にしている。

Ｃａｔ－Ｍ１のＵＥもＮＢ－ＩｏＴのＵＥも、現時点ではＭＢＭＳをサポートしておらず、３ＧＰＰ Ｒｅｌ－１４では、マルチキャストサービスが現在標準化されている。これは、多くのＩｏＴ使用事例では、マルチキャストサポートは、適用するために役立つ特徴であるからである。使用事例の例には、ファームウェアの更新版の、多数のセンサまたは他のデバイスへの送信、あるいは特定のコマンドを多数のアクチュエータに同時に送信することを含み得る。現在、このような送信および／またはコマンドは、ユニキャストを使用して別々に各受信側ＵＥに送信される必要があるだろう。しかしながら、単一の送信で同じ送信および／またはコマンドを多数のＵＥに送信するためにマルチキャストを使用することは、メッセージを配信するのに必要な時間および必要な無線リソースを減少させ、したがってスペクトル効率を高める。マルチキャストサービスは、２つの異なる送信方式、ＭＢＭＳ単一周波数ネットワーク（ＭＢＳＦＮ）、および単一セルポイントツーマルチポイント（ＳＣ－ＰＴＭ）を使用して実現され得る。

設定および制御のＳＣ－ＰＴＭ部分では、情報は、シングルセルマルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）論理チャネルを介して送信される。３ＧＰＰ ＴＳ ３６．３２１、「Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ｖ１３．１．０、２０１６年３月版を参照されたい。ＵＥはこのチャネルを継続的に監視することは期待されていないが、この情報への変化を示すインジケーションが、監視するようにＵＥが期待されているＳＣ－Ｎ－ＲＮＴＩと表される無線ネットワーク一時識別子を使用して示される。３ＧＰＰ ＴＳ ３６．３３１、「Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ）ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ｖ１３．１．０、２０１６年３月版を参照されたい。

ＳＣ－ＭＣＣＨは、ＭＡＣ仕様ＴＳ ３６．３２１に規定されている論理チャネルである。これは、ＤＬ－ＳＣＨトランスポートチャネルを介して送信され、レガシーＬＴＥではＰＤＣＣＨおよびＰＤＳＣＨ物理チャネルを使用して送信される。ｅＭＴＣの場合、対応する物理制御チャネルはＭＰＤＣＣＨであり、ＮＢ－ＩｏＴの場合、対応する物理チャネルは、ＮＰＤＣＣＨおよびＮＰＤＳＣＨとなるであろう。

ＳＣ－ＭＣＣＨは、ＳＣＰＴＭＣｏｎｆｉｇｕｒａｔｉｏｎ ＲＲＣメッセージを搬送し、ＴＳ ３６．３３１を参照されたい。これは、ＳＣＴ－ＭＴＣＨ論理チャネルを使用してＭＢＭＳサービスを受信するために、ＵＥのための設定情報を含んでいる。

設定および制御のＭＢＳＦＮ部分では、情報はマルチキャスト制御チャネル（ＭＣＣＨ）を介して送信される。この事例では、変化はＭ－ＲＮＴＩを使用して示される。

３ＧＰＰ ＲＡＮ＃７０ミーティングで、狭帯域ＩｏＴ（ＮＢ－ＩｏＴ）という新たな作業項目が承認された。この作業項目における目的は、室内カバレッジの向上、および大量の低スループットデバイスのサポートに取り組み、遅延の影響を受けず、超低デバイスコスト、低デバイス消費電力、および（最適化された）ネットワークアーキテクチャを可能にする、セルラのモノのインターネット（ＩｏＴ）用の無線アクセスを指定することである。

ＮＢ－ＩｏＴの場合、３つの異なる運用モード、すなわち、スタンドアロン、保護帯域、および帯域内が規定されている。スタンドアロンモードでは、ＮＢ－ＩｏＴシステムは、専用の周波数帯域で運用される。帯域内運用の場合、ＮＢ－ＩｏＴシステムは、現在のＬＴＥシステムによって使用されている周波数帯域の内側に配置できるが、保護帯域モードでは、ＮＢ－ＩｏＴシステムは現在の（レガシー）ＬＴＥシステムによって使用されている保護帯域で運用され得る。ＮＢ－ＩｏＴは、１８０ｋＨｚのシステム帯域幅で運用できる。多数のキャリアが設定されている場合は、Ｒ１－１６１５４８、「ＲＡＮ１ ａｇｒｅｅｍｅｎｔｓ ｆｏｒ Ｒｅｌ－１３ ＮＢ－ＩｏＴ」、情報源ＷＩ報告担当者（エリクソン）、３ＧＰＰ ＴＳＧ－ＲＡＮ ＷＧ１ミーティング＃８４、セントジュリアン、マルタ島、２０１６年２月１５日～１９日を参照されたい。たとえば、システム容量の増大、セル間干渉調整、負荷分散等のために、いくつかの１８０ｋＨｚのキャリアが使用され得る。

たとえば、ＮＢ－ＩｏＴデバイスのソフトウェアまたはファームウェアのアップグレードなど、通常よりも大きな容量を必要とする特定の使用事例を可能にするために、マルチキャリア運用を使用することができる。たとえば、Ｒ１－１６１５４８を参照されたい。ＮＢ－ＩｏＴデバイスは、その後、アンカキャリア上のシステム情報を傍受することができるが、通信を受信するためのデータがあるときには、二次キャリアに移動することができる。

現在のＳＣ－ＰＴＭ送信モードでは、ＳＣ－ＭＣＣＨを読み取った後に、ＵＥはＳＣ－ＭＣＣＨを継続的に監視することは期待されていない。ＳＣ－ＭＣＣＨを介して送信されたＳＣＰＴＭＣｏｎｆｉｇｕｒａｔｉｏｎ ＲＲＣメッセージが変化した場合、ＳＣ－ＭＣＣＨへの変化を示すインジケーションは、ＵＥが監視することを期待されているＳＣ－Ｎ－ＲＮＴＩを使用して示される。ＳＣ－ＭＣＣＨの変化は、ＳＣ－ＭＣＣＨ修正期間の開始時においてのみ起こり得る。ＳＣ－ＭＣＣＨの変化は、現在設定されているＳＣ－ＭＣＣＨにおける変化、または新たなＳＣ－ＭＣＣＨの追加が原因で起こり得る。ＵＥがＳＣ－ＭＣＣＨの変化を検出した場合、およびＳＣ－ＭＣＣＨによって設定されたマルチキャストサービスを受信することに関心がある場合、ＵＥはＳＣ－ＭＣＣＨ全体を再度読み取る必要がある。

ＬＴＥシステムは比較的広い帯域幅を使用し、ＵＥは比較的短時間内にＳＣ－ＭＣＣＨを受信することができるので、上述の手法はＬＴＥにおいてＳＣ－ＭＣＣＨの変化を示すのにうまく機能する。また、ＬＴＥのＵＥは通常、同時にいくつかのチャネルを監視することができる。しかし、たとえばｅＭＴＣまたはＮＢ－ＩｏＴのようなシステムでは、カバレッジ拡大および低域帯域幅のために、特にｅＭＴＣまたはＮＢ－ＩｏＴのＵＥが、貧弱なカバレッジに位置するとき、ＵＥが同じ量の情報を受信するのに通常、比較的長い時間がかかる。また、ｅＭＴＣおよびＮＢ－ＩｏＴのＵＥは、通常、複雑度が低く設計されているので、いくつかのチャネルを同時に復号する能力は非常に限られている。これは、ＳＣ－ＭＣＣＨの変化を示す上記の手法にとって問題となる。

より具体的には、ｅＭＴＣまたはＮＢ－ＩｏＴのＵＥが、進行中のＳＣ－ＭＴＣＨ送信を用いてＳＣ－ＭＣＣＨによって設定されている場合、従来の手順に従って、ＳＣ－ＭＣＣＨが変化されたことに気付いた場合、ＵＥは、自身のＳＣ－ＭＴＣＨ設定が変化されていなくても、ＳＣ－ＭＣＣＨ全体を再び読み取る必要がある。上記の理由により、ＳＣ－ＭＣＣＨの読み取りに時間がかかる場合がある。ＵＥについてＳＣ－ＭＴＣＨ設定が変化されない場合、この運用はとにかく実行されるので、これによってエネルギーを無駄に消費する。１つのＳＣ－ＭＣＣＨがセル内でいくつかのＳＣ－ＭＴＣＨを設定し得ることに留意されたい。

Ｒ１－１６１０９６８、「ＷＦ ｏｎ ｓｅａｒｃｈ ｓｐａｃｅ ｆｏｒ ＮＢ－ＩｏＴ ＳＣ－ＰＴＭ」、情報源Ｈｕａｗｅｉ、ＨｉＳｉｌｉｃｏｎ、ＺＴＥ、３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１ミーティング＃８６ｂｉｓ、ポルトガル、リスボン、２０１６年１０月１０日～１４日に記載された手順では、ＳＣ－ＭＣＣＨ変化通知は、ダウンリンク制御情報（ＤＣＩ）スケジューリングＳＣ－ＭＣＣＨおよび／またはＤＣＩスケジューリングＳＣ－ＭＴＣＨに示され得、その詳細が示され、さらに手法が言及されている。ＵＥは、依然として、このような各通知後に、ＳＣ－ＭＣＣＨ全体を読み取ることによって、これらの変化をチェックアウトする必要がある。

本明細書に記載の実施形態および例の目的は、上記で概説した問題および論点の少なくともいくつかに対処することである。添付の独立請求項に規定されるように、ネットワークノード、無線デバイス、およびその中の方法を使用することによって、この目的および他の目的を達成することが可能である。

一態様によれば、方法は、ネットワークノードによって送信された設定情報を、無線デバイスがマルチキャスト制御チャネル、たとえば上述したＳＣ－ＭＣＣＨから取得することを可能にするために、無線ネットワーク内のネットワークノードによって実行される。この方法では、ネットワークノードは、マルチキャスト制御チャネルの変化を示すインジケーションを送信し、このインジケーションはさらに、無線デバイスが変化による影響を受けておりマルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。ネットワークノードはさらに、上記インジケーションに従って変化したマルチキャスト制御チャネルを送信する。

別の態様によれば、ネットワークノードは、ネットワークノードによって送信された設定情報を、無線デバイスがマルチキャスト制御チャネル、たとえば上述したＳＣ－ＭＣＣＨから取得することを可能にするように構成される。ネットワークノードは、マルチキャスト制御チャネルの変化を示すインジケーションを送信するように設定され、このインジケーションはさらに、無線デバイスが変化による影響を受けておりマルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。上記の送信機能は、ネットワークノード内の第１の送信モジュールによって実現され得る。ネットワークノードはさらに、上記インジケーションに従って変化したマルチキャスト制御チャネルを送信するように設定され、この機能は、ネットワークノード内の第２の送信モジュールによって実現され得る。

別の態様によれば、方法は、無線ネットワークにおけるネットワークノードによって送信された設定情報を、マルチキャスト制御チャネル、たとえば上述したＳＣ－ＭＣＣＨから取得するために無線デバイスによって実行される。この方法では、無線デバイスは、マルチキャスト制御チャネルの変化を示すインジケーションを受信し、このインジケーションはさらに、無線デバイスが変化による影響を受けており無線デバイスがマルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。無線デバイスは、その後、無線デバイスが変化による影響を受けていることを上記インジケーションが示すとき、マルチキャスト制御チャネルを獲得または取得する。

他の態様によれば、無線デバイスは、無線ネットワークにおけるネットワークノードによって送信された設定情報を、マルチキャスト制御チャネル、たとえば上述したＳＣ－ＭＣＣＨから取得するように構成される。無線デバイスは、マルチキャスト制御チャネルの変化を示すインジケーションを受信するように設定され、このインジケーションはさらに、無線デバイスが変化による影響を受けており無線デバイスがマルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。この機能は、無線デバイス内の受信モジュールによって実現され得る。無線デバイスはまた、無線デバイスが変化による影響を受けていることを上記インジケーションが示すときに、マルチキャスト制御チャネルを獲得または取得するようにも動作可能である。後者の機能は、無線デバイス内の獲得モジュールまたは取得モジュールによって実現され得る。

上記のネットワークノード、無線デバイス、および方法を実施するときに達成され得る利点は、無線デバイスが変化による影響を受けることをインジケーションが示す場合に、無線デバイスがマルチキャスト制御チャネルを獲得または取得するだけでよいことを含む。これにより、無線デバイスは、上述した既知の手順と比較して、マルチキャスト制御チャネルを監視するために、少ないエネルギーしか消費しないであろう。

上記のネットワークノード、無線デバイス、および方法は、以下に説明されるように、さらなる特徴および利点を達成するために、異なる任意の実施形態による設定され実施され得る。

少なくとも１つのプロセッサにおいて実行されると、少なくとも１つのプロセッサに対して、上記の方法のいずれかを実行させる命令を備えたコンピュータプログラムも提供される。上記のコンピュータプログラムを含むプログラムキャリアがさらに提供され、ここでプログラムキャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

例示的な実施形態を用いて、添付の図面を参照しながら解決策をより詳細に説明する。

本明細書の実施形態が適用され得る無線ネットワークを例示する通信シナリオを示す図である。 レガシーＬＴＥネットワークにおける無線通信に関して異なるチャネルパラメータがどのように示され得るかを例示する図である。 さらなる可能な実施形態による、ネットワークノードにおける手順を例示するフローチャートである。 さらなる可能な実施形態による、無線デバイスにおける手順を例示するフローチャートである。 さらなる可能な実施形態による、ネットワークノードがどのように構造化され得るかの例を例示するブロック図である。 さらなる可能な実施形態による、無線デバイスがどのように構造化され得るかの例を例示するブロック図である。 通常すなわち従来の手順が適用されたときに無線デバイスおよびネットワークノードがどのように動作し得るかの例を例示するシグナリング図である。 本明細書の実施形態のうちの少なくともいくつかが適用されたときに無線デバイスおよびネットワークノードがどのように動作し得るかの例を例示するシグナリング図である。 本明細書の実施形態のうちの少なくともいくつかが適用されたときに、無線デバイスおよびネットワークノードがどのように動作し得るかの別の例を例示するシグナリング図である。

本明細書におけるいくつかの実施形態は、たとえば、マシン型通信、ｅＭＴＣ、ＮＢ－ＩｏＴ、マルチキャスト、ネットワーク社会、フィードバック、カバレッジ強化、ＭＡＣ、ＲＲＣに関連する通信のために、シングルポイントツーマルチポイントまたはマルチキャストのためのエンハンストＳＣ－ＭＣＣＨ変化通知を提供するために使用され得る。

本明細書の実施形態は、ＳＣ－ＭＣＣＨの変化がその現在のＳＣ－ＭＴＣＨの設定のように、無線デバイスに影響を与えるか否かを無線デバイスに通知するためのより効率的な手法を提供する。無線デバイスが、この変化によって影響を受けるまで、たとえば、興味のあるＳＣ－ＭＴＣＨの設定が変化したときまで、無線デバイスは、ＳＣ－ＭＣＣＨを再び読み取る必要はない。

たとえば、実施形態は、ＳＣ－ＭＣＣＨにおける変化が、その現在のＳＣ－ＭＴＣＨ設定に影響を与えない場合、無線デバイスは、ＳＣ－ＭＣＣＨの獲得を控えることを可能にする。たとえば、変化が１つまたは複数のＭＢＭＳサービスに影響を与えない場合、無線デバイスは、ＳＣ－ＭＴＣＨによって受信する。このようにして、無線デバイスの電力またはエネルギー消費量は、ＳＣ－ＭＣＣＨの不必要な獲得を回避することによって低減され得る。

本明細書における実施形態は、一般に無線ネットワークにおいて使用され得る。図１は、無線ネットワーク１００を描写する概略図である。無線ネットワーク１００は、１つまたは複数のＲＡＮと、１つまたは複数のＣＮとを備え得る。無線ネットワーク１００は、最大６つのＰＲＢからなる低域帯域幅をサポートする、新たなＵＥカテゴリであるＭ１（Ｃａｔ－Ｍ１）を備えたＭＴＣ、および、新たな無線インターフェースおよびＵＥカテゴリＮＢ１（Ｃａｔ－ＮＢ１）を指定するＮＢ－ＩｏＴのような、多くの異なる技術を使用し得る。

無線ネットワーク１００は、単にいくつかの可能な実施を述べると、Ｗｉ－Ｆｉ、Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、ＬＴＥ－Ａｄｖａｎｃｅｄ、５Ｇ、広帯域符号分割多元接続（ＷＣＤＭＡ）、グローバル移動体通信システム／ＧＳＭエボリューションのための拡張データレート（ＧＳＭ／ＥＤＧＥ）、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭａｘ）、またはウルトラモバイルブロードバンド（ＵＭＢ）のようなさらに多くの異なる技術を使用し得る。

本明細書における実施形態は、５Ｇのコンテキストにおいて特に関心のある最近の技術動向に関するものであり得るが、実施形態は、たとえばＷＣＤＭＡおよびＬＴＥのような既存の無線通信システムのさらなる開発にも適用可能である。

ネットワークノード１１０のようなネットワークノードは、無線ネットワーク１００において動作する。ネットワークノード１１０は、サービスエリアまたはセルまたはビームまたはビームグループと呼ばれ得る地理的エリア１１にわたって無線カバレッジを提供し、ビームのグループは、たとえば５Ｇ、ＬＴＥ、Ｗｉ－Ｆｉまたは同等の第１の無線アクセス技術（ＲＡＴ）のサービスエリアをカバーする。１２は、ネットワークノード１１０によって提供される無線カバレッジの別の地理的エリアを示す。

ネットワークノード１１０は、無線ローカルエリアネットワーク（ＷＬＡＮ）アクセスポイントまたはアクセスポイント局（ＡＰ ＳＴＡ）のように、たとえば無線アクセスネットワークノードである送信および受信ポイントや、アクセスコントローラや、ＢＳＳ、ＮｏｄｅＢ、エボルブドＮｏｄｅＢ（ｅＮＢ、ｅＮｏｄｅＢ）、基地トランシーバ局、無線リモートユニット、アクセスポイント基地局、基地局ルータ、無線基地局の送信構成、スタンドアロンアクセスポイントのように、たとえば無線基地局である基地局や、または、たとえば無線アクセス技術および使用されている用語に依存してそれぞれのネットワークノードによってサーブされるサービスエリア内の無線デバイスと通信することが可能な他の任意のネットワークユニットであり得る。

無線ネットワーク１００では、無線デバイス１２０のようなＵＥは、たとえばＲＡＮのような１つまたは複数のアクセスネットワーク（ＡＮ）を介して、１つまたは複数のコアネットワーク（ＣＮ）へ通信する。「無線デバイス」は、たとえば、任意のｅＭＴＣ ＵＥ、Ｃａｔ－Ｍ１ ＵＥ、ＮＢ－ＩｏＴ ＵＥ、端末、無線通信端末、ユーザ機器、マシン型通信（ＭＴＣ）デバイス、デバイスツーデバイス（Ｄ２Ｄ）端末、または、たとえばスマートフォン、ラップトップ、モバイル電話、センサ、リレー、モバイルタブレット、さらにはセル内で通信する小型基地局でさえもあるノードを意味する非限定的な用語であることを当業者は理解するはずである。

以下において、様々な実施形態が、いくつかの例示的であるが非限定的な例によって記載および説明される。これらの実施形態および例は相互に排他的ではなく、適切なときはいつでも組み合わせることができることに留意されたい。たとえば、一実施形態からの構成要素は、別の実施形態と組み合わせて適用可能であると暗黙のうちに仮定されてもよく、これらの構成要素が他の例示的な実施形態においてどのように使用され得るかが当業者にとって明らかである。

背景技術の項で述べたように、ＳＣ－ＰＴＭは２つの重要なチャネル、すなわちＳＣ－ＭＣＣＨおよびＳＣ－ＭＴＣＨを有する。図２は、レガシーＬＴＥ Ｒｅｌ－１３ ＳＣ－ＰＴＭ作業手順を図示している。図２から、セル内には、異なるマルチキャストサービスを提供するいくつかのＳＣ－ＭＴＣＨを設定する唯一のＳＣ－ＭＣＣＨがあることが分かる。ＳＣ－ＭＣＣＨおよびＳＣ－ＭＰＴＣＨのペイロードは、共有データチャネルによって搬送され、ダウンリンク制御情報（ＤＣＩ）を使用することによってスケジュールされる。現在、ｅＭＴＣの場合、ＤＣＩは上述のチャネルＭＰＤＣＣＨによって搬送され、ＮＢ－ＩｏＴの場合、ＤＣＩは上述のチャネルＮＰＤＣＣＨによって搬送される。ｅＭＴＣおよびＮＢ－ＩｏＴ ＳＣ－ＰＴＭのために使用されるＤＣＩフォーマットは、現在３ＧＰＰでは決定されていない。

ＬＴＥとｅＭＴＣ／ＮＢ－ＩｏＴシステムとの違いにより、「ＩｏＴ分科会からのドラフト報告、３ＧＰＰ ＲＡＮ２ミーティング＃９５ｂｉｓ、台湾、高雄、２０１６年１０月１０日～１４日」では、「ＲＡＮ２は、ＤＣＩにおいて情報を提供する直接インジケーションまたは類似のメカニズムが、ＳＣ－ＭＣＣＨ変化通知のために使用され得ると仮定する」ことが合意されている。したがって、ＳＣ－ＭＣＣＨ変化通知のレガシー手法、すなわちＲＥＬ－１３ ＳＣ－ＰＭＴが修正される。そして、この変化のために、ｅＭＴＣ／ＮＢ－ＩｏＴ ＵＥが、ＳＣ－ＭＣＣＨの変化を取得するためにレガシー手法を使用する場合、関連付けられたオーバヘッドがあるだろう。

本明細書の実施形態によれば、ＳＣ－ＭＣＣＨ設定における変化をよりよく示すために、ＤＣＩ内の１つまたはおそらく複数のフィールドを使用するいくつかの異なる手法が提供される。本明細書の実施形態によれば、ネットワークノード１１０のようなネットワークは、ＳＣ－ＭＣＣＨ変化通知とともにＤＣＩに追加情報を提供して、無線デバイス１２０のようなＵＥを支援して、変化通知が無線デバイス１２０に関連しているか否かを決定し、新たなＳＣ－ＭＣＣＨ全体を読み取るか否かを決定する。前述したＤＣＩは、ＳＣ－ＭＣＣＨ変化通知の直接インジケーションのために使用されるＤＣＩ、またはＳＣ－ＭＣＣＨおよび／またはＳＣ－ＭＴＣＨペイロードをスケジュールするＤＣＩを含み得る。

ネットワークノードがどのように動作し得るかの非限定的な例は、図１の通信シナリオに限定されることなく、図１をさらに参照して記載される図３のフローチャートによって例示される。したがって、図３は、ネットワークノードによって送信された設定情報を、無線デバイス１２０のような無線デバイスがマルチキャスト制御チャネル、たとえば上述したＳＣ－ＭＣＣＨから取得することを可能にするための、ネットワークノード１１０のようなネットワークノードにおける手順を例示する。

第１のアクション３０１は、ネットワークノード２００がマルチキャスト制御チャネルの変化を示すインジケーションを送信することを例示し、このインジケーションはさらに、無線デバイスが変化による影響を受けておりマルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。このインジケーションがどのように送信され得るかのいくつかの例が以下に提示される。アクション３０２において、ネットワークノードはさらに、上記インジケーションに従って変化したマルチキャスト制御チャネルを送信する。これにより、無線デバイスは、変化による影響を受けた場合にのみ、マルチキャスト制御チャネルを取得および獲得し、影響を受けない場合には控えるように決定できるという利点がある。これは上述したように、無線デバイスにおけるエネルギー消費量を低減する。

ネットワークノードにおける上記手順のいくつかの任意選択的かつ非限定的な実施形態がここに記載される。１つの例示的な実施形態では、インジケーションは、無線デバイスによって使用される、たとえば上述したＳＣ－ＭＴＣＨのようなマルチキャストトラフィックチャネルの設定が変化したか否かを示し得る。別の例示的な実施形態では、インジケーションは、無線ネットワーク一時識別子（ＲＮＴＩ）によって送信され得る。

別の例示的な実施形態では、インジケーションは、異なるマルチキャストトラフィックチャネル（ＳＣ－ＭＴＣＨ）をスケジュールするために使用される、ダウンリンク制御情報（ＤＣＩ）内の情報として送信され得、上記情報は、それぞれのマルチキャストトラフィックチャネルの設定が変化したか否かを示す。この実施形態がどのように適用され得るかの例は、図８を参照して後に記載される。この場合、別の例示的な実施形態は、上記情報が、新たなサービスが確立されたこと、または古い、すなわち現在のまたは既存のサービスがそれぞれのマルチキャストトラフィックチャネルについて変化したことを示すことであり得る。

別の例示的な実施形態では、インジケーションは、マルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）内のペイロードをスケジュールするために使用されるダウンリンク制御情報（ＤＣＩ）内の情報として送信され、上記情報は、マルチキャストトラフィックチャネルの設定が変化したか否かを示す。この実施形態がどのように適用され得るかの例はまた、図９を参照して後に記載される。

別の例示的な実施形態では、インジケーションは、直接インジケーションメッセージ内の情報として送信され得、上記情報は、どのマルチキャストトラフィックチャネル設定が変化されたかを示す。

さらなる例示的な実施形態では、インジケーションは、変化が、新たなマルチキャストトラフィックチャネル設定の確立と、古い、すなわち現在のまたは既存のマルチキャストトラフィックチャネル設定の更新とのうちの少なくとも１つを含むか否かを示し得る。

無線デバイス１２０のような無線デバイスが、どのように動作し得るかの別の非限定的な例は、図４のフローチャートによってさらに例示され、これは、図１をさらに参照して同様に記載される。したがって、図４は、無線ネットワーク内のネットワークノード（１１０）によって送信された設定情報をマルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）から取得するための無線デバイス１２０内の手順を例示している。

第１のアクション４０１は、無線デバイス１２０がネットワークノードから、マルチキャスト制御チャネルの変化を示すインジケーションを受信したことを例示し、このインジケーションはさらに、無線デバイスが変化によって影響を受け、無線デバイスがマルチキャスト制御チャネルを獲得または取得する必要があるか否かを例示する。この動作は上記のアクション３０１に対応する。次のアクション４０２において、無線デバイスが変化によって影響を受けていることを上記インジケーションが示す場合、無線デバイス１２０は、マルチキャスト制御チャネルを獲得または取得する。そうでない場合、無線デバイス１２０は、マルチキャスト制御チャネルを獲得または取得する必要がない。これは、デバイス内のエネルギー、すなわちバッテリを節約し、これは、上記で説明されているように、利点である。

ネットワークノードにおける上記手順のいくつかの任意選択的かつ非限定的な実施形態がここで記載される。１つの例示的な実施形態では、インジケーションは、無線デバイスによって使用されるマルチキャストトラフィックチャネル（ＳＣ－ＭＴＣＨ）の設定が変化したか否かを示し得る。別の例示的な実施形態では、インジケーションは、無線ネットワーク一時識別子（ＲＮＴＩ）によって受信され得る。

別の例示的な実施形態では、インジケーションは、異なるマルチキャストトラフィックチャネル（ＳＣ－ＭＴＣＨ）をスケジュールするために使用されるダウンリンク制御情報（ＤＣＩ）内の情報として受信され、上記情報は、それぞれのマルチキャストトラフィックチャネルの設定が変化したか否かを示す。別の例示的な実施形態では、上記情報は、その場合、新たなサービスが確立されたこと、または古い、すなわち現在のまたは既存のサービスがそれぞれのマルチキャストトラフィックチャネルについて変化されたことを示し得る。

別の例示的な実施形態では、インジケーションは、マルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）内のペイロードをスケジュールするために使用される、ダウンリンク制御情報（ＤＣＩ）内の情報として受信され得、上記情報は、マルチキャストトラフィックチャネルの設定が変化したか否かを示す。

別の例示的な実施形態では、インジケーションは直接インジケーションメッセージ内の情報として受信され得、上記情報は、どのマルチキャストトラフィックチャネル設定が変化したかを示す。

別の例示的な実施形態では、インジケーションは、変化が、新たなマルチキャストトラフィックチャネル設定の確立と、古い、すなわち現在のまたは既存のマルチキャストトラフィックチャネル設定の更新とのうちの少なくとも１つを含むか否かを示し得る。

図５および図６におけるブロック図は、ネットワークノード５００および無線デバイス６００がそれぞれ、上述の解決策およびその実施形態をもたらすためにどのように構造化され得るかを例示している。これらの図において、ネットワークノード５００および無線デバイス６００は、必要に応じて、特に図３および図４に関してそれぞれ上述した手法で、本明細書に記載の解決策を適用する例および実施形態のいずれかに従って動作するように設定され得る。ネットワークノード５００および無線デバイス６００のおのおのは、プロセッサおよびメモリを備えるように図示される。

ネットワークノード５００および無線デバイス６００のおのおのはさらに、実施に応じて通信に適したプロトコルを使用して互いの通信のために設定された機器を備える。しかしながら、解決策は、いかなる特定のタイプの無線信号またはプロトコルにも限定されない。

ネットワークノード５００は、たとえば、ユニット、モジュール等によって、以下のように、図３のフローチャートのアクションを実行するように設定または構成される。さらに、無線デバイス６００は、たとえば、ユニット、モジュール等によって、以下のように、図４のフローチャートのアクションを実行するように設定または構成される。

図５を参照すると、ネットワークノード５００は、無線デバイスが、ネットワークノード５００によって送信された設定情報を、マルチキャスト制御チャネル、たとえばＳＣ－ＭＣＣＨから取得することを可能にするように構成される。

ネットワークノード５００は、マルチキャスト制御チャネルの変化を示すインジケーションを送信するように設定され、インジケーションはさらに、無線デバイスが変化によって影響を受け、マルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。この動作は、ネットワークノード５００内の第１の送信モジュール５００Ａによって、アクション３０１に例示されるように実行され得る。ネットワークノード５００はまた、上記インジケーションに従って変化したマルチキャスト制御チャネルを送信するように設定されている。この動作は、ネットワークノード５００内の第２の送信モジュール５００Ｂによって、アクション３０２に示すように実行され得る。

図６を参照すると、無線デバイス６００は、無線ネットワーク内のネットワークノードにより送信された設定情報を、マルチキャスト制御チャネル、たとえばＳＣ－ＭＣＣＨから取得するように構成されている。

無線デバイス６００は、ネットワークノードから、マルチキャスト制御チャネルの変化を示すインジケーションを受信するように設定され、インジケーションはさらに、無線デバイスが変化によって影響を受け、無線デバイスがマルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す。この動作は、無線デバイス６００内の受信モジュール６００Ａによって、アクション４０１に例示されるように実行され得る。

無線デバイス６００はまた、上記インジケーションが、無線デバイスが変化によって影響を受けたことを示しているときに、マルチキャスト制御チャネルを獲得または取得するように設定されている。この動作は、無線デバイス６００内の獲得／取得モジュール６００Ｂによって、アクション４０２に例示されるように実行され得る。

図５および図６は、それぞれネットワークノード５００および無線デバイス６００内の様々な機能モジュールを例示しており、当業者は実際には適切なソフトウェアおよびハードウェア機器を使用して、これらの機能モジュールを実施できることに留意されたい。したがって、解決策は一般に、ネットワークノード５００および無線デバイス６００の図示された構造に限定されず、その中の機能モジュールは、必要に応じて、本開示で記載された特徴、例、および実施形態のうちのいずれかに従って動作するように設定され得る。

上述した機能モジュール５００Ａ～Ｂおよび６００Ａ～Ｂは、それぞれ、プロセッサＰによって実行されたときに、ネットワークノード５００および無線デバイス６００に対して、上述したアクションおよび手順を実行させるコード手段を備えたそれぞれのコンピュータプログラムのプログラムモジュールによって、ネットワークノード５００および無線デバイス６００において実施され得る。各プロセッサＰは、単一の中央処理装置（ＣＰＵ）を備え得るか、または２つ以上の処理装置を備えることができる。たとえば、各プロセッサＰは、汎用マイクロプロセッサ、命令セットプロセッサ、および／または、関連チップセット、および／または、特定用途向け集積回路（ＡＳＩＣ）のような専用マイクロプロセッサを含み得る。各プロセッサＰはまた、キャッシュ目的のための記憶装置を備え得る。

各コンピュータプログラムは、コンピュータ可読媒体を有し、プロセッサＰに接続されているメモリの形態で、ネットワークノード５００および無線デバイス６００のおのおの内のコンピュータプログラム製品によって搬送され得る。したがって、ネットワークノード５００および無線デバイス６００のおのおの内のコンピュータプログラム製品またはメモリＭは、コンピュータプログラムが、たとえば、コンピュータプログラムモジュール等の形態で記憶されるコンピュータ可読媒体を備える。たとえば、各ノードにおけるメモリＭは、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）、読出専用メモリ（ＲＯＭ）、または電気的消去可能プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）であり得、プログラムモジュールは代替実施形態において、それぞれのネットワークノード５００および無線デバイス６００内のメモリの形態で、異なるコンピュータプログラム製品上に分散され得る。

本明細書に記載の解決策は、少なくとも１つのプロセッサ上で実行されたとき、必要に応じて、少なくとも１つのプロセッサに対して、上記の実施形態および実施例のうちのいずれかに従ってアクションを実行させる命令を備えたコンピュータプログラムによって、ネットワークノード５００および無線デバイス６００のおのおのにおいて実施され得る。図面に図示されるように、解決策は、上記のコンピュータプログラムを含むキャリアで、ネットワークノード５００および無線デバイス６００のおのおのにおいて実施され得、キャリアは、電子信号、光信号、無線信号、またはコンピュータ可読記憶媒体のうちの１つである。

本明細書の実施形態がどのように実施され得るかのいくつかのさらなる例が、上述の実施形態のうちの少なくともいくつかに関連する４つの可能な実施１～４に関して記載される。以下の例で使用されるマルチキャスト制御チャネルは、ＳＣ－ＭＣＣＨを用いて例証されているが、他のタイプのマルチキャスト制御チャネルもまた、本明細書の実施形態において使用され得ることに留意されたい。さらに、以下の例で使用されるマルチキャストトラフィックチャネルは、ＳＣ－ＭＴＣＨを用いて例証されているが、他のタイプのマルチキャストトラフィックチャネルもまた、本明細書の実施形態において使用され得る。

第１の実施
この実施は、インジケーションが、たとえばＳＣ－ＭＴＣＨのような異なるマルチキャストトラフィックチャネルをスケジュールするために使用されるＤＣＩ内の情報として送信される上記の実施形態を称し、上記情報は、それぞれのマルチキャストトラフィックチャネルの設定が変化したか否かを示す。

「ＩｏＴ分科会からのドラフト報告、３ＧＰＰ ＲＡＮ２ミーティング＃９５ｂｉｓ、台湾、高雄、２０１６年１０月１０日～１４日」では、「ＲＡＮ２は、（ＤＣＩにおいて情報を提供する）直接インジケーションまたは類似のメカニズムが、ＳＣ－ＭＣＣＨ変化通知のために使用され得ると仮定する」ことが合意されている。したがって、ネットワークがＳＣ－ＭＣＣＨの変化を示す時点で、これはまた、異なるＳＣ－ＭＴＣＨをスケジュールする必要な情報をＤＣＩに含め、また特定のＳＣ－ＭＴＣＨの設定が変化したか否かを示す。

より詳細には、共通の共有データチャネル上の各ＳＣ－ＭＴＣＨペイロード送信は、ＤＣＩを搬送するＳＣ－ＭＴＣＨ制御チャネルによってスケジュールされる。上述のように、ｅＭＴＣの場合、ＤＣＩは、ＭＰＤＣＣＨによって搬送され、ＮＢ－ＩｏＴの場合、ＤＣＩは、ＮＰＤＣＣＨによって搬送される。したがって、ＳＣ－ＭＣＣＨ変化通知を受信または検出すると、ネットワークノード１１０は、ＳＣ－ＭＴＣＨ ＤＣＩ内で、対応するＳＣ－ＭＴＣＨの設定が変化されることになるか否かを示すことができる。このＳＣ－ＭＴＣＨの設定が変化されることになることをＤＣＩが示している場合、無線デバイス１２０のようなＵＥは、更新されたＳＣ－ＭＣＣＨを読みに行くであろう。そうでない場合、ＵＥは、依然として、以前の設定が有効であると仮定することができる。たとえば、図２を参照すると、ＳＣ－ＭＴＣＨ１のＤＣＩにおいて、このＤＣＩが、ＳＣ－ＭＴＣＨ１の設定が変化されていないことを示す場合、現在、ＳＣ－ＭＴＣＨ１を傍受している無線デバイス１２０のようなＵＥは、更新されたＳＣ－ＭＣＣＨを読む必要がなく、その逆もある。

さらに、ネットワークノード１１０は、ＳＣ－ＭＣＣＨの変化が、古いサービスの変化ではなく、新たなサービスをアドインすることを含むか否かをＤＣＩ内に示すことができる。ここで、ＤＣＩは、異なるＳＣ－ＭＴＣＨをスケジュールする異なるＤＣＩを意味する。この場合、新たなサービスに関心を持つ無線デバイス１２０のようなＵＥは、更新されたＳＣ－ＭＣＣＨを読みに行くことができ、関心がないものは、これらの現在のＳＣ－ＭＴＣＨの設定が変わっていないことを仮定することができる。

第１の実施が実際にどのように実現され得るかの例は、図８を参照して後で説明される。

第２の実施
この実施は、インジケーションが、たとえばＳＣ－ＭＣＣＨのようなマルチキャスト制御チャネルにおいてペイロードをスケジュールするために使用されるＤＣＩ内の情報として送信される上記の実施形態を称し、上記情報は、マルチキャストトラフィックチャネルの設定が変化したか否かを示す。これは第１の実施と同様であるが、異なるＳＣ－ＭＴＣＨをスケジュールするＤＣＩにおけるＳＣ－ＭＴＣＨの変化を示す代わりに、変化情報は、ＳＣ－ＭＣＣＨペイロードをスケジュールするＤＣＩにおいて提供され得る。

ＳＣ－ＭＣＣＨペイロードをスケジュールするＤＣＩは、ＳＣ－ＭＣＣＨの変化が、いくつかの特定のＳＣ－ＭＴＣＨの設定が変化したか否かに関連していることを示し得る。そして、たとえば、影響を受けた無線デバイス１２０のようなＵＥは、これによって、更新されたＳＣ－ＭＣＣＨを読み取ることに進む。

さらに、ＳＣ－ＭＣＣＨペイロードをスケジュールするＤＣＩにおいて、ネットワークノード１１０はまた、ＳＣ－ＭＣＣＨの変化が新たなサービス、たとえば新たなＳＣ－ＭＴＣＨ設定を追加することを含むか否か、またはこれが古いＳＣ－ＭＣＣＨ設定の更新であるか、またはその両方であるかを示し得る。そして、ＳＣ－ＭＣＣＨの変化がちょうど新たなサービスをアドインすることに関するものである場合、たとえば、無線デバイス１２０のようなＵＥは、その古いＳＣ－ＭＴＣＨ設定が変化していないと仮定し得る。この場合、新たに追加されたサービスに興味があるＵＥだけが、ＳＣ－ＭＣＣＨの変化を読みに行く。

第２の実施の一例では、ＤＣＩ内の長さＮのビットフィールドを使用して、たとえばビットマップを使用して、どの特定のＳＣ－ＭＴＣＨまたはＭＢＭＳサービスが変化したのかを示すことができる。たとえば、対応する変化されたＳＣ－ＭＴＣＨを傍受している無線デバイス１２０のようなＵＥは、ＳＣ－ＭＣＣＨを介して搬送されるＳＣＰＴＭＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを再獲得し得る。第２の実施の別の例では、たとえば、ＲＡＮ２が、たとえばＭＡＣ ＣＥを介して無線デバイス１２０のようなＵＥにその旨を示す手段を導入する場合、更新された設定メッセージにおいて、新たなサービス、または、停止したいくつかの既存のサービスがあるか否かを示すために使用できるＤＣＩ内のフィールドが存在し得る。第２の実施の上記２つの例を組み合わせて、新たなメッセージを示す１つのフィールドまたはフラグと、変化した特定の設定情報を示す別のフィールドとが存在するようにすることも可能である。

第２の実施が、実際にどのように実現され得るかの例は、図９に例示されるシグナリング手順を参照して後で説明される。

第３の実施
この実施は、インジケーションが、直接インジケーションメッセージ内の情報として送信される上記の実施形態を称し、上記情報は、どのマルチキャストトラフィックチャネル設定が変化したのかを示す。

「ＩｏＴ分科会からのドラフト報告、３ＧＰＰ ＲＡＮ２ミーティング＃９５ｂｉｓ、台湾、高雄、２０１６年１０月１０日～１４日」では、「ＲＡＮ２は、（ＤＣＩにおいて情報を提供する）直接インジケーションまたは類似のメカニズムが、ＳＣ－ＭＣＣＨ変化通知のために使用され得ると仮定する」ことが合意されている。したがって、直接インジケーションメッセージには、ＳＣ－ＭＣＣＨ設定が変化することを通知することに加えて、どのＳＣ－ＭＴＣＨまたはＭＢＭＳサービスが変化によって影響を受けるかに関する情報を含めることも可能である。このようにして、変化インジケーションを受信すると、たとえば無線デバイス１２０のようなＵＥは、ＳＣ－ＭＣＣＨを再獲得するか否かを決定し得る。

第４の実施
この実施は、インジケーションは、変化が、新たなマルチキャストトラフィックチャネル設定の確立、および、古い、すなわち現在のまたは既存のマルチキャストトラフィックチャネル設定の更新、のうちの少なくとも１つを含むか否かを示す上記の実施形態を称する。

いくつかの場合では、たとえば、異なるサービスを示すことは、インジケーションサイズを大きくしすぎることを意味し得るので、第３の実施は実用的ではない可能性がある。そうである場合、ＳＣ－ＭＣＣＨの変化が新たなサービス、たとえば新たなＳＣ－ＭＣＴＣＨ設定を追加することを含むこと、またはこれが古いＳＣ－ＭＴＣＨ設定の更新であること、またはその両方であることを単に示すために、第４の実施が使用され得る。そして、ＳＣ－ＭＣＣＨの変化がちょうど新たなサービスをアドインすることに関するものである場合、たとえば無線デバイス１２０のようなＵＥは、その古いＳＣ－ＭＴＣＨ設定が変化していないと仮定し得る。この場合、新たに追加されたサービスに関心がある、たとえば無線デバイス１２０のようなＵＥのみが、ＳＣ－ＭＣＣＨ変化を読みに行く。

新たなサービスの追加だけが示されている場合は、この新たなサービスの追加を示すために、１つの追加フィールドを使用すれば十分である。あるいは、いくつかのフィールドの組合せが、この目的のために使用され得る。

これに加えて、ＳＣ－ＭＣＣＨの変化が、１つまたはいくつかの進行中のサービスを削除することに関連している場合、この変化も、上記と同じ手法で反映され得る。進行中のＳＣ－ＭＴＣＨを有する可能性がある、たとえば無線デバイス１２０のようなＵＥは、変化を求めてＳＣ－ＭＣＣＨを読みに行くであろうが、いくつかのＳＣ－ＰＴＭサービスを監視しているだけで、進行中のＳＣ－ＭＴＣＨがない、たとえば無線デバイス１２０のようなＵＥは、ＳＣ－ＭＣＣＨの変化を読みに行く必要はない。

実際にどのように解決策が実現され得るかの２つの例が、図８および図９のシグナリング図を参照して以下に説明される。第１に、本発明のインジケーションが使用されていない従来の手順の一例を、比較として図７のシグナリング図を参照して記載する。この手順では、ネットワークノードは、マルチキャストトラフィックチャネル「ＳＣ－ＭＴＣＨ＃１」上でペイロードを送信することによって特定のサービスを提供し、無線デバイスは、ＳＣ－ＭＴＣＨ＃１を監視することによってサービスを適用するように設定されると仮定される。この手順は、次の一連のアクションを含む。

アクション７：１－ネットワークノードは、マルチキャスト制御チャネルＳＣ－ＭＣＣＨの設定を含む「ＳＩＢ２０」と呼ばれるシステム情報ブロックを定期的にブロードキャストする。

アクション７：２－無線デバイスは、ＳＩＢ２０を受信し、そこからＳＣ－ＭＣＣＨの設定を取得する。

アクション７：３－ネットワークノードは、ＰＤＣＣＨでＤＣＩを送信し、ＤＣＩは、ＳＣ－ＭＣＣＨのネットワークノードの送信をスケジュールする。このＤＣＩを受信することによって、無線デバイスは、ＳＣ－ＭＣＣＨをいつ受信し監視するかを知る。

アクション７：４－ネットワークノードは、アクション７：３のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＣＣＨを送信し、このＳＣ－ＭＣＣＨは、無線デバイスによって受信される。

アクション７：５－無線デバイスはＳＣ－ＭＣＣＨから、特定のＳＣ－ＭＴＣＨ＃１の設定を取得する。これは無線デバイスにとってサービスを適用するために関心がある。

アクション７：６－ネットワークノードは、ＰＤＣＣＨでＤＣＩを送信し、ＤＣＩは、ＳＣ－ＭＴＣＨ＃１のネットワークノードの送信をスケジュールする。これにより、無線デバイスは、ＳＣ－ＭＴＣＨ＃１をいつ受信すべきかを知る。

アクション７：７－ネットワークノードは、アクション７：６のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＴＣＨ＃１を送信し、ＳＣ－ＭＴＣＨ＃１は、無線デバイスによって受信される。

ＳＣ－ＭＴＣＨ＃１の設定に何らかの変化がある場合、無線デバイスは少なくともアクション７：３～７：５を繰り返すことによって、ＳＣ－ＭＣＣＨを監視し続ける必要があり、その結果、無線デバイスのバッテリを消耗させることに留意されたい。

図８におけるシグナリング図は、上述の「第１の実施」が実際にどのように実現され得るかの例を例示しており、これは、以下の一連のアクションに関して記載される。したがって、この実施では、マルチキャスト制御チャネルの変化を示すインジケーションは、異なるマルチキャストトラフィックチャネルまたはＳＣ－ＭＴＣＨをスケジュールするために使用されるＤＣＩ内の情報として送信され、上記情報は、それぞれのマルチキャストトラフィックチャネルの設定が変化したか否かを示す。

この手順では、ネットワークノードは、ＳＣ－ＭＴＣＨ＃１上でペイロードを送信することによって特定のサービスを提供し、無線デバイスは、サービスを適用するためにＳＣ－ＭＴＣＨ＃１を受信および監視するように設定されると再び仮定される。図７に関して上述したように、無線デバイスが、ＳＣ－ＭＴＣＨ＃１の設定を取得したと仮定される。図８の手順は以下の通りである。

アクション８：１－ネットワークノードは、ＰＤＣＣＨ上でＤＣＩを送信し、ＤＣＩは、ＳＣ－ＭＴＣＨ＃１のネットワークノードの送信をスケジュールする。これにより、無線デバイスは、ＳＣ－ＭＴＣＨ＃１をいつ受信すべきかを知る。

アクション８：２－ネットワークノードは、アクション８：１のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＴＣＨ＃１を送信し、ＳＣ－ＭＴＣＨ＃１は、無線デバイスによって受信される。これらの最初の２つのアクションは、次のアクションが起こるまで繰り返され得る上記の従来の手順におけるアクション７：６およびアクション７：７に対応する。

アクション８：３－ネットワークノードは、ＳＣ－ＭＴＣＨ＃１の設定が変化されることになることに気付き、これは、ＳＣ－ＭＣＣＨもこれに応じて変化されることになることを意味する。

アクション８：４－ネットワークノードは、ＰＤＣＣＨ上でＤＣＩを送信し、ＤＣＩはＳＣ－ＭＴＣＨ＃１のネットワークノードの送信をスケジュールする。この場合、ＤＣＩはまた、ＳＣ－ＭＣＣＨにおけるＳＣ－ＭＴＣＨ＃１の設定の変化を示すインジケーションを含み、この設定は、たとえば、このＳＣ－ＭＴＣＨ＃１のためにＤＣＩ内に変化インジケーションビットをセットすることによって、次に来る修正期間において有効になる。これによって、無線デバイスは、ＳＣ－ＭＣＣＨの変化によって影響を受け、したがって次の修正期間においてＳＣ－ＭＣＣＨを再び読み取る必要があることを知る。

アクション８：５－ネットワークノードは、まだ変化していないＳＣ－ＭＴＣＨ＃１の「古い」設定でＳＣ－ＭＴＣＨ＃１を送信し、これによって、無線デバイスは、古い設定でこのＳＣ－ＭＴＣＨ＃１送信を取得することができる。

アクション８：６－ネットワークノードは、ＳＣ－ＭＴＣＨ＃１の設定を変化させる。これは、ＳＣ－ＭＣＣＨもこれに応じて変化することを意味する。

アクション８：７－ネットワークノードは、ＰＤＣＣＨ上でＤＣＩを送信し、ＤＣＩは、アクション７：３と同様に、ＳＣ－ＭＣＣＨのネットワークノードの送信をスケジュールする。このＤＣＩを受信することによって、無線デバイスは、ＳＣ－ＭＣＣＨをいつ監視すべきかを知り、これによって、以下のようにＳＣ－ＭＴＣＨ＃１の変化された設定を取得することができる。

アクション８：８－ネットワークノードは、アクション８：７のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＣＣＨを送信し、ＳＣ－ＭＣＣＨは、アクション７：４におけるように無線デバイスによって受信される。

アクション８：９－無線デバイスは、ＳＣ－ＭＣＣＨから、ＳＣ－ＭＴＣＨ＃１の新たな、すなわち変化した設定を取得する。これにより、無線デバイスは、ネットワークノードから送信されたときにＳＣ－ＭＴＣＨ＃１を受信して使用することができる。

この場合、ＳＣ－ＭＴＣＨ＃１の設定の変化が、アクション８：４のＳＣ－ＭＴＣＨ＃１のＤＣＩに示されないのであれば、無線デバイスは、ＳＣ－ＭＣＣＨを監視する必要がなく、これにより、無線デバイスのエネルギー消費量を低減することに留意されたい。

図９のシグナリング図は、上述の「第２の実施」が実際にどのように実現され得るかの例を例示しており、これは、以下の一連のアクションに関して記載される。この実施では、マルチキャスト制御チャネルの変化を示すインジケーションは、マルチキャスト制御チャネルまたはＳＣ－ＭＣＣＨにおいてペイロードをスケジュールするために使用されるＤＣＩ内の情報として送信され、上記情報は、マルチキャストトラフィックチャネルの設定が変化したか否かを示す。

この手順が開始すると、ネットワークノードは、ＳＣ－ＭＴＣＨ＃１においてペイロードを送信することによってまだサービスを提供しておらず、無線デバイスは、ＳＣ－ＭＴＣＨ＃１を受信および監視し、利用可能になったらサービスを適用するように設定されると仮定される。図９の手順は以下の通りである。

アクション９：１－ネットワークノードは、マルチキャスト制御チャネルＳＣ－ＭＣＣＨの設定を含む「ＳＩＢ２０」と呼ばれるシステム情報ブロックを定期的にブロードキャストする。

アクション９：２－無線デバイスは、ＳＩＢ２０を受信し、そこからＳＣ－ＭＣＣＨの設定を取得する。

アクション９：３－ネットワークノードは、ＰＤＣＣＨ上でＤＣＩを送信し、ＤＣＩは、ＳＣ－ＭＣＣＨのネットワークノードの送信をスケジュールする。このＤＣＩを受信することによって、無線デバイスは、ＳＣ－ＭＣＣＨをいつ監視すべきかを知る。

アクション９：４－ネットワークノードは、アクション７：３のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＣＣＨを送信し、ＳＣ－ＭＣＣＨは無線デバイスによって受信される。これまでのところ、アクション９：１～９：４は、図７の従来の手順のアクション７：１～７：４に対応する。

アクション９：５－ネットワークノードは、サービスのためにＳＣ－ＭＴＣＨ＃１の設定が生成されたことに気付き、これは、ＳＣ－ＭＣＣＨもこれに応じて変化することを意味する。

アクション９：６－ネットワークノードはＰＤＣＣＨ上でＤＣＩを送信し、ＤＣＩは、ＳＣ－ＭＣＣＨのネットワークノードの送信をスケジュールする。この場合、ＤＣＩは、たとえば、そのＳＣ－ＭＴＣＨ＃１のためのＤＣＩ内に変化インジケーションビットを設定することによって、ＳＣ－ＭＣＣＨにおけるＳＣ－ＭＴＣＨ＃１の生成された設定を示すインジケーションを含む。これによって、無線デバイスは、ＳＣ－ＭＣＣＨ変化によって影響を受けることを知り、したがってＳＣ－ＭＴＣＨ＃１の設定を取得するために、ＳＣ－ＭＣＣＨを読み取る必要がある。

アクション９：７－ネットワークノードは、アクション９：６のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＣＣＨを送信し、ＳＣ－ＭＣＣＨは、無線デバイスによって受信される。

アクション９：８－無線デバイスは、ＳＣ－ＭＣＣＨからＳＣ－ＭＴＣＨ＃１の設定を取得する。これにより、無線デバイスは、ネットワークノードから送信されたときにＳＣ－ＭＴＣＨ＃１を受信して使用することができる。

アクション９：９－ネットワークノードはＰＤＣＣＨ上でＤＣＩを送信し、ＤＣＩはＳＣ－ＭＴＣＨ＃１のネットワークノードの送信をスケジュールする。これにより、無線デバイスは、ＳＣ－ＭＴＣＨ＃１をいつ受信すべきかを知る。

アクション９：１０－ネットワークノードは、アクション７：６のＤＣＩに示されたスケジューリングに従ってＳＣ－ＭＴＣＨ＃１を送信し、ＳＣ－ＭＴＣＨ＃１は、無線デバイスによって受信される。

この場合、アクション９：６のＳＣ－ＭＣＣＨのためのＤＣＩが、ＳＣ－ＭＴＣＨ＃１の設定が利用可能であることを示さないのであれば、無線デバイスは、ＳＣ－ＭＣＣＨを監視する必要がなく、これによって、無線デバイスのエネルギー消費量を低減することに留意されたい。

本明細書で使用されるとき、「処理モジュール」という用語は、処理回路、処理ユニット、プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等を称することができる。一例として、プロセッサ、ＡＳＩＣ、ＦＰＧＡ等は、１つまたは複数のプロセッサカーネルを備え得る。いくつかの例では、処理モジュールは、ソフトウェアモジュールまたはハードウェアモジュールによって具現化され得る。任意のそのようなモジュールは、本明細書に開示されるように、判定手段、推定手段、キャプチャ手段、関連付け手段、比較手段、識別手段、選択手段、受信手段、送信手段等であり得る。一例として、「手段」という表現は、判定モジュール、選択モジュール等のようなモジュールであり得る。

本明細書で使用されるとき、「ように設定された」という表現は、処理回路が、ソフトウェア設定および／またはハードウェア設定によって、本明細書に記載されたアクションのうちの１つまたは複数を実行するように設定または適合されることを意味し得る。

本明細書で使用されるとき、「メモリ」という用語は、ハードディスク、磁気記憶媒体、ポータブルコンピュータディスケットまたはディスク、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）等を称し得る。さらに、「メモリ」という用語は、プロセッサなどの内部レジスタメモリを称し得る。

本明細書で使用されるとき、「コンピュータ可読媒体」という用語は、ユニバーサルシリアルバス（ＵＳＢ）メモリ、ＤＶＤディスク、ブルーレイディスク、データのストリームとして受信されるソフトウェアモジュール、フラッシュメモリ、ハードドライブ、たとえばメモリスティックやマルチメディアカード（ＭＭＣ）のようなメモリカード等であり得る。

本明細書で使用されるとき、「コンピュータ可読コードユニット」という用語は、コンピュータプログラムのテキスト、コンパイルされたフォーマットでコンピュータプログラムを表すバイナリファイルの一部または全体、またはその間のいずれかであり得る。

本明細書で使用されるとき、「数」、「値」という用語は、二進数、実数、虚数、または有理数等の任意の種類の数字であり得る。さらに、「数」、「値」は、文字または文字列などの１つまたは複数の文字であり得る。「数」、「値」は、ビット列でも表され得る。

本明細書で使用されるとき、「いくつかの実施形態では」という表現は、記載された実施形態の特徴が、本明細書で開示された他の任意の実施形態と組み合わされ得ることを示すために使用されている。

「ｃｏｍｐｒｉｓｅ（備える、含む）」または「ｃｏｍｐｒｉｓｉｎｇ（備える、含む）」という用語を使用するとき、非限定的、すなわち、「少なくともからなる」を意味すると解釈されるべきである。

略語説明
ＤＣＩ ダウンリンク制御情報
ＮＢ 狭帯域
ＮＢ－ＩｏＴ 狭帯域モノのインターネット
ＭＴＣ マシン型通信
ＬＴＥ Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ
ＰＤＣＣＨ 物理データ制御チャネル
ＮＢ－ＰＢＣＨ ＮＢ－ＩｏＴ物理ブロードキャストチャネル
ＰＲＢ 物理リソースブロック
ＤＬ ダウンリンク
ＵＬ アップリンク
ＲＲＣ 無線リソース制御
ＳＣ－ＭＣＣＨ シングルセルマルチキャスト制御チャネル
ＳＣ－ＭＴＣＨ シングルセルマルチキャストトラフィックチャネル
ＲＮＴＩ 無線ネットワーク一時識別子
ＭＢＭＳ マルチメディアブロードキャストマルチキャストサービス
ＭＡＣ 媒体アクセス制御

解決策が特定の例示的な実施形態を参照して記載されてきたが、その記載は一般に発明的概念を例示することのみを意図されており、解決策の範囲を限定するものとして解釈されるべきではない。たとえば、「ネットワークノード」、「無線デバイス」、「変化を示すインジケーション」、「マルチキャスト制御チャネル」、および「マルチキャストトラフィックチャネル」という用語が、本開示を通して使用されているが、本明細書に記載されている特徴および特性を有する他の対応する任意のエンティティ、機能、および／または、パラメータを使用することもできる。この解決策は、図３および図４の対応するアクションならびに図５および図６の対応するモジュールへの参照を括弧内に含む添付の特許請求の範囲に従って実施され得る。

Claims (8)

1. ネットワークノード（１１０）によって送信された設定情報を、無線デバイスがマルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）から取得することを可能にするために、無線ネットワーク内の前記ネットワークノード（１１０）によって実行される方法であって、該方法は、
   前記マルチキャスト制御チャネルの変化を示すインジケーションを送信すること（３０１）であって、前記インジケーションはさらに、前記無線デバイスが前記変化による影響を受けており前記マルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す、送信すること（３０１）と、
   前記インジケーションに従って変化した前記マルチキャスト制御チャネルを送信すること（３０２）とを備え、
   前記インジケーションは、前記マルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）内のペイロードをスケジュールするために使用されるダウンリンク制御情報（ＤＣＩ）内の情報として送信され、前記情報は、マルチキャストトラフィックチャネルの設定が変化したか否かを示す、方法。
2. 前記インジケーションは、前記変化が、新たなマルチキャストトラフィックチャネル設定の確立と、古い、すなわち現在のまたは既存のマルチキャストトラフィックチャネル設定の更新とのうちの少なくとも１つを含むか否かを示す、請求項１に記載の方法。
3. 無線ネットワーク内のネットワークノード（１１０）によって送信された設定情報を、マルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）から取得するために、無線デバイス（１２０）によって実行される方法であって、該方法は、
   前記マルチキャスト制御チャネルの変化を示すインジケーションを受信すること（４０１）であって、前記インジケーションはさらに、前記無線デバイスが前記変化による影響を受けており前記無線デバイスが前記マルチキャスト制御チャネルを獲得または取得する必要があるか否かを示す、受信すること（４０１）と、
   前記無線デバイスが前記変化による影響を受けていることを前記インジケーションが示すとき、前記マルチキャスト制御チャネルを獲得または取得すること（４０２）とを備え、
   前記インジケーションは、前記マルチキャスト制御チャネル（ＳＣ－ＭＣＣＨ）内のペイロードをスケジュールするために使用されるダウンリンク制御情報（ＤＣＩ）内の情報として受信され、前記情報は、マルチキャストトラフィックチャネルの設定が変化したか否かを示す、方法。
4. 前記インジケーションは、前記変化が、新たなマルチキャストトラフィックチャネル設定の確立と、古い、すなわち現在のまたは既存のマルチキャストトラフィックチャネル設定の更新とのうちの少なくとも１つを含むか否かを示す、請求項３に記載の方法。
5. 少なくとも１つのプロセッサ上で実行された場合、前記少なくとも１つのプロセッサに対して、請求項１もしくは２に記載の方法、または、請求項３もしくは４に記載の方法を実行させる命令を備えた、コンピュータプログラム。
6. 請求項５に記載のコンピュータプログラムを含むコンピュータ可読記憶媒体。
7. 請求項１または２に記載の方法を実行するように設定されたネットワークノード（５００）。
8. 請求項３または４に記載の方法を実行するように設定された無線デバイス（６００）。

Images