(57)【特許請求の範囲】
【請求項１】
無線ネットワーク制御装置（１０９）における方法であって、前記方法は、
不連続受信（ＤＲＸ）モードで動作するユーザ機器（ＵＥ）（１０３）がランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行したことを検出する工程（２０１，３０１，６０１，８０１）と、
前記アップリンク送信を受信したノードＢ（１０１）に、前記ＵＥが前記アップリンク送信を実行したこととダウンリンク送信を引き続き監視していることを当該ノードＢに知らせる信号を送信する工程（２０３，３０３，６０３，８０３）とを有し、
前記信号は前記ＵＥを識別する情報を含み、
前記信号はさらに、
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報と、
前記ＵＥがＤＲＸモードに復帰する可能性のある最も早いインスタンスを示す情報との内の少なくとも１つを含むことを特徴とする方法。
【請求項２】
ノードＢ（１０１）における方法であって、前記方法は、
不連続受信（ＤＲＸ）モードで動作するユーザ機器（ＵＥ）（１０３）がランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行し、前記ＵＥがダウンリンク送信を引き続き監視していることを示す信号を無線ネットワーク制御装置（１０９）から受信する工程（２０３，３０３，６０３，８０３）を有し、
前記信号は前記ＵＥを識別する情報を含み、
前記信号はさらに、
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報と、
前記ＵＥがＤＲＸモードに復帰する可能性のある最も早いインスタンスを示す情報との内の少なくとも１つを含むことを特徴とする方法。
【請求項３】
無線ネットワーク制御装置（１０９）であって、
ＩｕｂインタフェースとＩｕｒインタフェースとの内の少なくともいずれかにより信号を受信したり送信するネットワークインタフェース（１３４）と、
前記ネットワークインタフェースに接続されて動作可能なコントローラ（１３１）とを有し、
前記コントローラは、
不連続受信（ＤＲＸ）モードで動作するユーザ機器（ＵＥ）がランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行したことを検出し、
該検出に応じて、前記アップリンク送信を受信したノードＢ（１０１）に、前記ＵＥが前記アップリンク送信を実行したことと前記ＵＥがダウンリンク送信を引き続き監視していることを示す信号を送信するように前記ネットワークインタフェースにトリガをかけるよう適合されており、
前記信号は、前記ＵＥを識別する情報を含み、
前記信号はさらに、
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報と、
前記ＵＥがＤＲＸモードに復帰する可能性のある最も早いインスタンスを示す情報との内の少なくとも１つを含むことを特徴とする無線ネットワーク制御装置。
【請求項４】
前記ＵＥを識別する情報は、前記ＵＥと関係する高速ダウンリンク共用チャネルの無線ネットワーク一時的識別子（Ｈ−ＲＮＴＩ）であることを特徴とする請求項３に記載の無線ネットワーク制御装置。
【請求項５】
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報は、前記ノードＢによる前記ＲＡＣＨでの前記アップリンク送信の受信に関係する接続フレーム番号（ＣＦＮ）であることを特徴とする請求項３に記載の無線ネットワーク制御装置。
【請求項６】
前記信号は、前記ノードＢに送信されるＩｕｂデータフレームであることを特徴とする請求項３乃至５のいずれか１項に記載の無線ネットワーク制御装置。
【請求項７】
前記信号は、別の無線ネットワーク制御装置を介して前記ノードＢに対して送信されるＩｕｒデータフレームであることを特徴とする請求項３乃至５のいずれか１項に記載の無線ネットワーク制御装置。
【請求項８】
ノードＢ（１０１）であって、
Ｉｕｂインタフェースにより信号を受信したり送信するネットワークインタフェース（１２４）と、
前記ネットワークインタフェースに接続されて動作可能なコントローラ（１２１）とを有し、
前記コントローラは、
前記ネットワークインタフェースを介して、不連続受信（ＤＲＸ）モードで動作するユーザ機器（ＵＥ）（１０３）がランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行し、前記ＵＥがダウンリンク送信を引き続き監視していることを示す信号を無線ネットワーク制御装置（ＲＮＣ）（１０９）から受信するよう適合されており、
前記信号は前記ＵＥを識別する情報を含み、
前記信号はさらに、
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報と、
前記ＵＥがＤＲＸモードに復帰する可能性のある最も早いインスタンスを示す情報との内の少なくとも１つを含むことを特徴とするノードＢ。
【請求項９】
前記ＵＥに対するダウンリンク送信のスケジューリングを行い、前記ＵＥがダウンリンク送信を引き続き監視していることが示されたことを考慮するために、前記ＵＥに対するダウンリンク送信のスケジューリングを調整するよう適合されているスケジューラ（１２６）をさらに有することを特徴とする請求項８に記載のノードＢ。
【請求項１０】
前記ＵＥを識別する情報は、前記ＵＥと関係する高速ダウンリンク共用チャネルの無線ネットワーク一時的識別子（Ｈ−ＲＮＴＩ）であることを特徴とする請求項８又は９に記載のノードＢ。
【請求項１１】
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報は、前記ノードＢによる前記ＲＡＣＨでの前記アップリンク送信の受信に関係する接続フレーム番号（ＣＦＮ）であることを特徴とする請求項８に記載のノードＢ。
【請求項１２】
前記信号は、前記ノードＢにより受信されるＩｕｂデータフレームであることを特徴とする請求項８乃至１１のいずれか１項に記載のノードＢ。
【請求項１３】
前記スケジューラは、前記示されたことがない場合よりも早くに前記ＵＥに対するダウンリンク送信をスケジューリングすることにより、前記示されたことを考慮することを特徴とする請求項９に記載のノードＢ。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示はセルラ無線ネットワークにおいて動作するユーザ機器（ＵＥ）の不連続受信に関係する方法及びデバイスを開示する。
【背景技術】
【０００２】
セルラ無線ネットワークは常に進化しつづけている。第３世代パートナーシッププロジェクト（３ＧＰＰ）は移動体通信についての標準化技術を設定する組織である。その標準化技術は複数のリリースとして構造化されている。新しいリリースが公開されるにつれ、新しい機能が標準化技術に取り入れられる。
【０００３】
３ＧＰＰリリース７、８では、数多くの機能追加がなされて、ランダムアクセスと短い送信についての無線資源制御（ＲＲＣ）状態である所謂、ＣＥＬＬ＿ＦＡＣＨ状態の性能を改善している。その機能追加は、
・リリース７：ＣＥＬＬ＿ＦＡＣＨ状態における
高速ダウンリンク共用チャネル（ＨＳ−ＤＳＣＨ）受信
・リリース８：ＣＥＬＬ＿ＦＡＣＨ状態におけるエンハンスドアップリンク
・リリース８：エンハンスドユーザ機器（ＵＥ）不連続受信（ＤＲＸ）
のようにリストできる。
【０００４】
上述の最初の２つの機能追加により、ＨＳ−ＤＳＣＨとエンハンスド専用チャネル（Ｅ−ＤＣＨ）がダウンリンクとアップリンクのトランスポートチャネルとして用いられることが可能になり、フォワードアクセスチャネル（ＦＡＣＨ）とランダムアクセスチャネル（ＲＡＣＨ）をそれぞれ置換している。
【０００５】
これら新しいトランスポートチャネルはＣＥＬＬ＿ＦＡＣＨ状態において複数のＵＥに対するはるかに広いバンド幅を提供している。
【０００６】
しかしながら、これらの機能をサポートするＵＥは、利用可能であるときには新しいトランスポートチャネルを用いなければならない。例えば、これらのチャネルに輻輳が生じている場合であっても、ＲＡＣＨとＦＡＣＨの内の少なくともいずれかにフォールバックする選択肢はない。ＵＥとネットワークの両方は、その送信が成功するまで試行を続けなければならない。
【０００７】
エンハンスドＵＥ  ＤＲＸは電池消費を低減するために導入された。リリース８に先立って、ＣＥＬＬ＿ＦＡＣＨ状態におけるＵＥは連続的にダウンリンク（ＤＬ）送信を監視することが要求されている。エンハンスドＵＥ  ＤＲＸを用いる場合、ＵＥは特定の期間のアップリンク又はダウンリンクの少なくともいずれかがインアクティブになった後に、不連続受信（ＤＲＸ）モードに移行することができる。このモードで動作中に、ＵＥは各ＤＲＸサイクルで一度だけの短い時間の間、ＤＬアクティビティを監視することが必要なだけである。残りの時間は、ＵＥは受信器をＯＦＦにして用いられる電力量を著しく低減することができる。
【０００８】
ダウンリンク送信は、そのようなモードが起動されたときにＵＥのＤＲＸパターンを観察しなければならない。ＵＥがネットワークを聴取しているとき、データは短い間隔で送信されるのみである。ダウンリンクデータを受信後にＵＥがＤＲＸモードを離脱するオプションも提供されている。エンハンスドＵＥ  ＤＲＸにとっての前提条件は、ダウンリンクトランスポートチャネルとしてＨＳ−ＤＳＣＨを使用することである。しかしながら、ＵＬでは、ＲＡＣＨ又はＥ−ＤＣＨが用いられるかもしれない。
【０００９】
３ＧＰＰ  ＴＳＧ  ＲＡＮミーティング＃５４では作業項目“ＣＥＬＬ＿ＦＡＣＨへの更なる機能追加”において、とりわけ、
・第２の、より長い、ＤＲＸサイクル
・Ｅ−ＤＣＨでのアクセス要求が拒絶された場合にＲＲＣシグナリングがＲＡＣＨへフォールバックする可能性
を導入することを同意した。
【００１０】
ＣＥＬＬ＿ＦＡＣＨにおいてＤＲＸモードで動作するＵＥの挙動は、アップリンクトランスポートチャネルとしてＥ−ＤＣＨが構成設定されるのか又はＲＡＣＨが構成設定されるのかに依存して異なる。Ｅ−ＤＣＨが構成設定されるとき、アップリンク送信後に、ＵＥは、ＤＲＸモードを離れ、即ち、イナクティビティタイマが時間切れにならない限り、ダウンリンク送信のために高速共用制御チャネル（ＨＳ−ＳＣＣＨ）を引き続いて監視／聴取することを開始しなければならない。その結果、ＵＥはＨＳ−ＤＳＣＨにアクセスするかもしれない。
【００１１】
しかしながら、アップリンクトランスポートチャネルとしてＲＡＣＨが構成設定されるとき、現在の３ＧＰＰの技術仕様ではＵＥがＤＲＸモードを離れることを許していない。その代わりに、アップリンク送信後、ＵＥはＤＲＸパターンに従って受信器をすぐさまＯＦＦにすることができる。ダウンリンクでの応答送信は、ＵＥがダウンリンク送信を聴取／監視している場合にはそのことを待ち合わせしなければならない。もし、アップリンクメッセージがシグナリングのため、例えば、時間要件の厳しいアプリケーションの設定又は制御のためであるなら、この待ち合わせは大きくかつ不要な遅延を引き起こすことになり得る。
【００１２】
リリース１１ではるかに長いＤＲＸサイクル（秒のオーダ）の導入があったので、この問題はあるかに深刻なものになっている。
【００１３】
リリース１１でＲＡＣＨへのフォールバックが導入されたが、この問題はＥ−ＤＣＨがアップリンクトランスポートチャネルとして構成設定される場合にさえも拡がっている。
【００１４】
セルラ無線システムにおいて現存するシステムを改善し、より効率的な通信を提供するという絶え間のない要求がある。それ故に、セルラ無線システムにおいて改善された通信を可能にする方法及び装置に対する要求がある。
【発明の概要】
【００１５】
セルラ無線システム、特に、ＤＲＸを採用するセルラ無線システムにおける改善された通信を可能にする方法及び装置を提供することが本発明の目的である。
【００１６】
この目的などは、添付の請求の範囲で説明された方法及び装置により達成される。
【００１７】
それ故、いくつかの実施例に従えば、無線ネットワーク制御装置（ＲＮＣ）における方法が提供される。その方法は、不連続受信（ＤＲＸ）モードで動作するユーザ機器（ＵＥ）がランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行したことを検出する工程を有する。無線ネットワーク制御装置はそれから、前記アップリンク送信を受信したノードＢに、前記ユーザ機器が前記アップリンク送信を実行したこととダウンリンク送信を引き続き監視していることを当該ノードＢに知らせる信号を送信する。ここで、前記信号は前記ユーザ機器を識別する情報を含む。これにより、ノードＢが前記ＵＥがいつＤＲＸモードではなくなったのかに注意が向けられるので、ダウンリンク送信のスケジューリングが容易になる。
【００１８】
いくつかの実施例に従えば、前記ＵＥを識別する情報は、前記ＵＥと関係する高速ダウンリンク共用チャネルの無線ネットワーク一時的識別子（Ｈ−ＲＮＴＩ）である。
【００１９】
いくつかの実施例に従えば、前記信号はさらに、
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報と、
前記ＵＥがＤＲＸモードに復帰する可能性のある最も早いインスタンスを示す情報との内の少なくとも１つを含むことができる。
【００２０】
いくつかの実施例に従えば、前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報は、前記ノードＢによる前記ＲＡＣＨでの前記アップリンク送信の受信に関係する接続フレーム番号（ＣＦＮ）である。
【００２１】
いくつかの実施例に従えば、前記ＵＥがいつＤＲＸモードに復帰する可能性があるのかを示す情報は、前記ＵＥがＤＲＸモードに復帰する可能性のある前記最も早いインスタンスを示すＣＦＮの形式で提供される。
【００２２】
いくつかの実施例に従えば、前記信号は、前記ノードＢに送信されるＩｕｂデータフレームである。前記信号はまた、別の無線ネットワーク制御装置を介して前記ノードＢに対して送信されるＩｕｒデータフレームであっても良い。
【００２３】
ここで説明される他の実施例に従えば、ノードＢにおける方法が提供される。その方法は、不連続受信（ＤＲＸ）モードで動作するユーザ機器（ＵＥ）がランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行し、前記ＵＥがダウンリンク送信を引き続き監視していることを示す信号を無線ネットワーク制御装置から受信する工程を有する。ここで、前記信号は前記ＵＥを識別する情報を含む。
【００２４】
いくつかの実施例に従えば、前記信号の受信により、前記ノードＢに対して、前記ＵＥがダウンリンク送信を引き続き監視していることが示されたことを考慮するために、前記ＵＥに対するダウンリンク送信のスケジューリングを調整するようトリガをかける。いくつかの実施例に従えば、前記示されたことを考慮するためにダウンリンク送信のスケジューリングを行うことは、前記示されたことがない場合よりも早くに前記ＵＥに対するダウンリンク送信をスケジューリングすることを含む。
【００２５】
いくつかの実施例に従えば、前記ＵＥを識別する情報は、前記ＵＥと関係する高速ダウンリンク共用チャネルの無線ネットワーク一時的識別子（Ｈ−ＲＮＴＩ）である。
【００２６】
いくつかの実施例に従えば、前記信号はさらに、
前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報と、
前記ＵＥがＤＲＸモードに復帰する可能性のある最も早いインスタンスを示す情報との内の少なくとも１つを含む。
【００２７】
いくつかの実施例に従えば、前記アップリンク送信がいつ実行されたのか、又は、前記ＵＥがいつダウンリンク送信を引き続き監視することを開始したのかを示す情報は、前記ノードＢによる前記ＲＡＣＨでの前記アップリンク送信の受信に関係する接続フレーム番号（ＣＦＮ）である。
【００２８】
いくつかの実施例に従えば、前記ＵＥがいつＤＲＸモードに復帰する可能性があるのかを示す情報は、前記ＵＥがＤＲＸモードに復帰する可能性のある前記最も早いインスタンスを示すＣＦＮの形式で提供される。
【００２９】
いくつかの実施例に従えば、前記信号は、前記ノードＢにより受信されるデータフレームである。前記信号はまた、前記ノードＢにより受信されるＩｕｂデータフレームであっても良い。
【００３０】
いくつかの他の実施例に従えば、不連続受信モード（ＤＲＸ）で動作するユーザ機器（ＵＥ）における方法が提供される。その方法は、ランダムアクセスチャネル（ＲＡＣＨ）でアップリンク送信を実行する工程と、前記アップリンク送信の実行に際して、引き続きダウンリンク送信の監視を行うことを開始する工程とを有する。
【００３１】
この開示はまた、機器、特に、セルラ無線システムにおいて用いられ、かつ、ここで説明される方法を実行するように適合された無線基地局（ノードＢ）、無線ネットワーク制御装置（ＲＮＣ）、及び、ユーザ機器へと拡張される。これらの機器には、上記処理を実行するコントローラ／コントローラ回路が備えられる。そのコントローラは適切なハードウェアとソフトウェアとの内の少なくともいずれかを用いて実現される。そのハードウェアは読出可能な記憶媒体に格納されたソフトウェアを実行するように構成された１つ以上のプロセッサを含む。そのプロセッサは、１個の専用プロセッサにより、１個の共用プロセッサにより、また、幾つかは共用されていても分散されていても良い複数の個別的なプロセッサにより、実現される。さらにその上、プロセッサはこれに限定するものではないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェアと、ＡＳＩＣハードウェアと、読出専用メモリ（ＲＯＭ）と、ランダムアクセスメモリ（ＲＡＭ）と、他の記憶媒体との内の少なくともいずれかを含むことができる。
【００３２】
次に、本発明について非限定的な例により添付図面を参照しながら詳細に説明する。
【図面の簡単な説明】
【００３３】
【図１】セルラ無線システムの概要を示す図である。
【図２】実施例１に従って、ＲＮＣがノードＢにＤＲＸモードではなくなったＵＥについて通知する様子を示す図である。
【図３】実施例２に従って、ＲＮＣがノードＢにＤＲＸモードではなくなったＵＥについて通知する様子を示す図である。
【図４】“ＲＡＣＨ送信タイミング”フレームの送信を示す図である。
【図５】代表的なＲＡＣＨ送信タイミングペイロード構造を示す図である。
【図６】実施例３に従って、ＲＮＣがノードＢにＤＲＸモードではなくなったＵＥについて通知する様子を示す図である。
【図７】変形されたＨＳ−ＤＳＣＨデータフレームを示す図である。
【図８】実施例４に従って、ＲＮＣがノードＢにＤＲＸモードではなくなったＵＥについて通知する様子を示すである。
【図９】変形されたＨＳ−ＤＳＣＨデータフレームを示す図である。
【図１０】ユーザ機器の実施形を示す図である。
【図１１】ノードＢの実施形を示す図である。
【図１２】中央ノードの実施形を示す図である。
【発明を実施するための形態】
【００３４】
図１には、セルラ無線システム１００の概要が示されている。そのシステムは、例えば、ＷＣＤＭＡ／ＨＳＰＡシステムである。システム１００は、ここではノードＢと記されている複数の無線基地局１０１を含む。図１の簡略図では、その内の１つだけが示されている。無線基地局１０１は無線ネットワーク制御装置（ＲＮＣ）１０９と記されている中央ノードに接続される。もちろん、システム１００は複数のＲＮＣを含む。ＲＮＣ１０９はさらに、ＲＮＣ１０９の異なる動作を実行するモジュール１１１を含む。
【００３５】
モジュール１１１は、例えば、無線基地局１０１との信号の相互作用のためにネットワークインタフェース回路を用いて実現される。モジュール１１１はさらに、ネットワークインタフェース回路に動作可能に接続されたデジタルデータ処理回路を含むことができる。
【００３６】
移動局１０３はここでは単一のユニットとして表現されユーザ機器（ＵＥ）と記されているが、それは無線基地局によりカバーされる地理的な領域に存在しており、無線インタフェースにより無線基地局に接続できる。無線基地局１０１はさらに、無線基地局１０１の異なる動作を実行するためのモジュール１０５を有する。モジュール１０５は、例えば、モジュール１０５のメモリに格納されたコンピュータソフトウェア命令のセットで動作するマイクロコントローラを用いて実現される。次に、ＵＥ１０３は、ＵＥ１０３の動作を実行するよう適合されたモジュール１０７を有する。モジュール１０７は、例えば、モジュール１０７のメモリに格納されたコンピュータソフトウェア命令のセットで動作するマイクロコントローラを用いて実現される。ノードＢは、それがカバーする領域内の全てのＵＥへの、また、それらＵＥからの送信をサポートする。
【００３７】
いくつかの実施例に従えば、ＲＡＣＨでの送信後、ＵＥはＤＲＸモードを離れて、ダウンリンク送信を引き続き聴取するように構成されている。通常、ＵＥは一定期間のダウンリンク送信の連続的な監視の後、ＤＲＸモードに復帰するように構成されている。例えば、ＵＥは、イナクティビティタイマによって規定された時間の後ＤＲＸモードに復帰するように設定される。ＲＡＣＨ送信により搬送され、ノードＢ（無線基地局（ＲＢＳ）としても言及される）を介して受信されるデータ又は制御メッセージはノードＢによりＩｕｂインタフェースを介して無線ネットワーク制御装置（ＲＮＣ）に転送される。オプション的には、その転送はＩｕｂとＩｕｒの両方のインタフェースを介して実行される。ＩｕｂはＲＮＣとノードＢとの間のインタフェースであり、Ｉｕｒは同じネットワークにおける複数のＲＮＣ間のインタフェースである。ダウンリンク送信のスケジューリングを容易にするために、ＲＮＣはノードＢにＵＥがＤＲＸモードを離れたことを通知するように設定されている。又は、ＲＮＣはノードＢに、ＵＥがＤＲＸモードを離れて今はダウンリンク送信のために聴取／監視を引き続き行っていることを示唆するものである、ＵＥがＲＡＣＨでアップリンク送信を実行したことを通知する。
【００３８】
なお、発明者により認識されているように、このことは望ましいものである。なぜなら、ノードＢはＲＡＣＨでメッセージが送信された場合、その送信者のアイデンティティについて何の情報ももっていないからである。従って、ノードＢは特定のＵＥがＤＲＸモードを離れ、今はダウンリンク送信のために聴取／監視を引き続き行っているという事実に気づいていない。
【００３９】
ＲＡＣＨでの送信を受信する際に、ＲＮＣはその送信を行ったＵＥがＤＲＸモードを離れたことを理解する。ＲＮＣはまた、ＵＥのＤＲＸパターンと、ＵＥがＤＲＸモードに戻る前にダウンリンク送信を聴取しなければならない時間の長さを特定するイナクティビティタイマについての知識をもっている。異なる実施例に従えば、あるＵＥがＲＡＣＨでの送信を実行し、それ故にダウンリンク送信を引き続き監視していることを、ノードＢに通知するために、どのようにＲＮＣが設定されるのかについては幾つかの代替案がある。
【００４０】
解決策Ａ：その情報を搬送する新しい、ノードＢアプリケーション部／無線ネットワークサブシステムアプリケーション部（ＮＢＡＰ／ＲＮＳＡＰ）がノードＢに送信される。確認応答を要求したり、或いは、その要求をしない両方のＮＢＡＰ／ＲＮＳＡＰメッセージが用いられる。その情報は、例えば、次のように与えられる。
【００４１】
−受信されるＲＡＣＨ送信のＣＦＮ（接続フレーム番号）。また、例えば、Ｈ−ＲＮＴＩ（ＨＳ−ＤＳＣＨの無線ネットワーク一時的識別子）を用いた、ＵＥのアイデンティティが提供される。
【００４２】
−ＵＥがＤＲＸモードに復帰する最も早いＣＦＮと、また、ＵＥのアイデンティティ（例えば、Ｈ−ＲＮＴＩ）。
【００４３】
−同じ情報を搬送する何か別の量。これに限定されるものではないが、例としては、システムフレーム番号（ＳＦＮ）の使用、別の種類のタイムスタンプ、又は接続フレーム番号（ＣＦＮ）に代わる相対時間とＨ−ＲＮＴＩ（例えば、Ｕ−ＲＮＴＩ又はＳ−ＲＮＴＩ）に代わる別のタイプのＵＥアイデンティティを含む。
【００４４】
或いは、現存するＮＢＡＰ／ＲＮＳＡＰメッセージ（例えば、ＮＢＡＰ：ＣＯＭＭＯＮ  ＴＲＡＮＳＰＯＲＴ  ＣＨＡＮＮＥＬ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＲＥＱＵＥＳＴ；ＲＮＳＡＰ：ＣＯＭＭＯＮ  ＴＲＡＮＳＰＯＲＴ  ＣＨＡＮＮＥＬ  ＲＥＳＯＵＲＣＥＳ  ＲＥＱＵＥＳＴ）が上記の情報を含むために拡張されても良い。
【００４５】
図２には、上記の方法が描かれている。図２は、ＲＮＣがノードＢにＤＲＸモードを離れるＵＥについて、そして、ＤＲＸモードを離れるどのＵＥが制御プレーンメッセージを用いているのかについて通知する方法を示している。従って、まずステップ２０１では、ＲＮＣはＵＥがＤＲＸモードを離れたことを検出する。それから、ステップ２０３で、ＲＮＣはノードＢに対してＤＲＸモードを離れたＵＥについて通知する。このことは、例えば、ＣＦＮ、例えばＨ−ＲＮＴＩのようなＵＥアイデンティティを含むことができる新しい、又は、現存する制御プレーンメッセージを用いたＮＢＡＰメッセージを用いて実行される。幾つかの実施例に従えば、そのメッセージはドリフトＲＮＣ（ＤＲＮＣ）を介してＲＮＳＡＰメッセージにおいて送信される。それから、ステップ２０５では、ノードＢにはそのＵＥがＤＲＸモードにはいないことが通知される。ステップ２０５で受信されたメッセージの結果として、ノードＢはそのＵＥにデータ送信をすぐに開始することができる。
【００４６】
１つの代表的な実施例に従えば、ＮＢＡＰ“ＣＯＭＭＯＮ  ＴＲＡＮＳＰＯＲＴ  ＣＨＡＮＮＥＬ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＲＥＱＵＥＳＴ”が拡張される。２つの新しい情報要素（ＩＥ）がＨ−ＲＮＴＩとＣＦＮとして導入される。このことは以下の表Ａに示されている。以下は、ＴＳ２５．４３３（９．１．６節）ＣＯＭＭＯＮ  ＴＲＡＮＳＰＯＲＴ  ＣＨＡＮＮＥＬ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＲＥＱＵＥＳＴのＮＢＡＰの定義である。この例では、２つの新しいＩＥがＨ−ＲＮＴＩとＣＦＮとして導入されている。Ｈ−ＲＮＴＩ以外のＵＥアイデンティティや、他のタイマ／データフィールドが他の位置において定義される。
【００４７】
表Ａ：現存するＮＢＡＰメッセージに導入される新ＩＥ
0006054534.tif 000002
0006054534.tif 000003
【００４８】
解決策Ｂ：新しいＩｕｂ制御フレームが用いられて上述した解決策Ａで説明した情報を転送する。
【００４９】
この方法は図３に図示されている。そこでは、制御フレームプロトコルが用いられてノードＢにＤＲＸモードを離れるＵＥについて通知する。図３では、Ｉｕｂ／Ｉｕｒユーザプレーンメッセージのデータフレームにおいて導入された指示を用いてＲＮＣとノードＢとの間で通信が行われる。図３に示された例では、まずステップ３０１で、ＲＮＣはＵＥがＤＲＸモードを離れたことを検出する。それから、ステップ３０３で、ＲＮＣはノードＢに対してＤＲＸモードを離れたＵＥについて通知する。このことは、Ｉｕｂ／Ｉｕｒユーザプレーンのデータフレームにおける指示を用いて実行される。例えば、現存するフレーム又は新しいフレームにおけるスペアビットが用いられる。それから、ステップ３０５では、ノードＢにはそのＵＥがＤＲＸモードにはいないことが通知される。ステップ３０５で受信されたメッセージの結果として、ノードＢはそのＵＥにデータ送信をすぐに開始することができる。
【００５０】
幾つかの実施例に従えば、新しい制御フレームが“ＲＡＣＨ送信タイミング”として定義される。この新しい制御フレームが、ステップ３０３において図３に関連して上述した送信の代わりに用いられる。そのようなフレームの送信は図４に示されている。図４に示されている制御フレームは、ＲＮＣがノードＢに対してＵＥがアップリンク（ＵＬ）送信を行ったことを通知したい場合に用いられる新しい制御フレームである。それは、図３におけるメッセージ３０３の実施形の例である。従って、図３のステップ３０３におけるメッセージは、現存するメッセージの拡張であるか、又は、図４に示した新しいメッセージである。図５には、図４で示したメッセージのあり得るペイロード構造が示されている。従って、図５は代表的なＲＡＣＨ送信タイミングペイロード構造を示している。
【００５１】
解決策Ｃ：ダウンリンクＩｕｂフレームプロトコルが拡張されて上述した解決策Ａの情報を搬送する。これは、ヘッダのスペアビット、スペア拡張、又は、他のスペア位置を用いて実現される。それから、その情報はデータフレーム又は制御フレームに挿入されノードＢへと送信される。
【００５２】
そのような方法の例が図６に示されている。まずステップ６０１で、ＲＮＣはＵＥがＤＲＸモードを離れたことを検出する。それから、ステップ６０３で、ＲＮＣはノードＢに対してＤＲＸモードを離れたＵＥについて通知する。このことは、ヘッダのスペアビット、スペア拡張、又は、他のスペア位置を用いて実行される。例えば、現存するフレーム又は新しいフレームにおけるスペアビットが用いられる。それから、その情報はデータフレーム又は制御フレームに挿入されノードＢへと送信される。それから、ステップ６０５では、ノードＢにはそのＵＥがＤＲＸモードにはいないことが通知される。ステップ６０５で受信されたメッセージの結果として、ノードＢはそのＵＥにデータ送信をすぐに開始することができる。
【００５３】
図７には代表的な実施形が図示されている。図７では、現存するＨＳ−ＤＳＣＨデータフレームが用いられる。図７は３ＧＰＰ  ＴＳ２５．４３５（６．２．６Ａ節）［ＵＰ  ｐｒｏｔ］のＵＰフレームの簡略変形バージョンを示している。インジケータを導入する代わりに、スペア拡張からの１オクテットが割当てられ、ＣＦＮを定義する。ＲＮＣはこのＣＦＮを用いてノードＢに対して、最初のデータがどの無線フレームでダウンリンク送信されねばならないのかを通知する。類似のやり方がＨＳ−ＤＳＣＨデータフレームタイプ３に適用できる。また、ＴＳ２５．４２５におけるＩｕｒユーザプレーンにおけるデータフレームに対しても適用できる。
【００５４】
新しいＩＥフラグが新しいデータフィールドに対して定義される。その例では、新しいデータフィールドが１オクテットのＣＦＮとして定義される。また、他の範囲や他のデータフィールドのＣＦＮを定義することも可能である。
【００５５】
解決策Ｄ：ＲＡＣＨ送信がＩｕｂフレームの受信者から受信されたかどうかを示す新しいフラグを搬送するためにダウンリンクＩｕｂフレームプロトコルが拡張される。このことは、ヘッダのスペアビット、スペア拡張、又は、他のスペア位置を用いて達成される。それから、そのフラグはデータ又は制御フレームに挿入されノードＢへと送信される。ノードＢは、同じＵＥに関してノードＢにおけるデータフレームと何らかの現存するデータとの内のいずれかがそのＵＥにすぐさま送信されるかもしれないとのインジケータとしてそのフラグを解釈するように設定される。或いは、そのインジケータとＵＥアイデンティティを含む新しい制御フレームがＲＮＣからノードＢに送信されるために導入されても良い。或いは、ＮＢＡＰ／ＲＮＳＡＰ共通チャネルメッセージが拡張されても良いし、或いは、新しいメッセージが導入されそのインジケータとＵＥアイデンティティをＲＮＣからノードＢに通信しても良い。
【００５６】
そのようなやり方に従った解決策の例は、図８と図９とに図示されている。図８では、ダウンリンクＩｕｂフレームプロトコルが拡張されて、ＲＡＣＨ送信がＩｕｂフレームの受信者から受信されたかどうかを示す新しいフラグを搬送する。まずステップ８０１で、ＲＮＣはＵＥがＤＲＸモードを離れたことを検出する。それから、ステップ８０３で、ＲＮＣはノードＢに対してＤＲＸモードを離れたＵＥについて通知する。このことは、ヘッダのスペアビット、スペア拡張、又は、他のスペア位置を用いて実行される。それから、その情報はデータフレーム又は制御フレームに挿入されノードＢへと送信される。それから、ステップ８０５では、ノードＢにはそのＵＥがＤＲＸモードにはいないことが通知される。ステップ８０５で受信されたメッセージの結果として、ノードＢはそのＵＥにデータ送信をすぐに開始することができる。
【００５７】
図９には代表的な実施形が図示されている。図９では、現存するＨＳ−ＤＳＣＨデータフレームが用いられる。図９は３ＧＰＰ  ＴＳ２５．４３５（６．２．６Ａ節）［ＵＰ  ｐｒｏｔ］のＵＰフレームの簡略変形バージョンを示している。その例では、現存するＨＳ−ＤＳＣＨデータフレームが用いられる。その例では、ＨＳ−ＤＳＣＨデータフレームタイプ２のヘッダにおけるスペアビット２が新しいフラグのために割当てられる。それから、ノードＢはＵＥに対する終了するか後に続くかの内の少なくともいずれかのデータのスケジューリングにおいて、この情報を利用する。
【００５８】
図１０には、上述の手順に従うように適合された代表的なユーザ機器が示されている。図１０に示されているように、例示するＵＥ１０３はプロセッサ１１４の形態のコントローラと、メモリ１１３と、トランシーバ１１２と、アンテナ２３とを含む。特定の実施例において、ＵＥまたは他の形態の移動局により備えられるような上述したいくつか又は全ての機能は、図１０に示されているメモリ１１３のようなコンピュータ可読媒体に格納された命令を実行するプロセッサ１１４により提供される。移動局の別の実施例は、上述の機能のいずれかと上述した解決策のいずれかをサポートするのに必要な何らかの機能との内の少なくともいずれかを含むある側面の移動局の機能の提供を担当する図１０に示されたもの以外の付加的な構成要素を含んでもよい。
【００５９】
図１１には、代表的なノードＢが示されている。図１１に示されているように、例示するノードＢ１０１はプロセッサ１２１の形態のコントローラと、メモリ１２３と、トランシーバ１２２と、アンテナ１２８とを含む。また、例示するノードＢはネットワークインタフェース１２４を含むことができる。ノードＢ１０１はさらにスケジューラ１２６を含むことができる。そのスケジューラは、コントローラに内蔵されているか、又は、そのコントローラから分離構成とすることもできる。特に、スケジューラ１２６は、ＵＥに対するダウンリンク送信をスケジュールし、ＵＥが引き続きダウンリンク送信を監視しているという示唆を考慮するためにＵＥへのダウンリンク送信のスケジュールを調整するよう適合されている。
【００６０】
特定の実施例において、ノードＢと他のタイプの移動体通信ノードとの内の少なくともいずれかにより備えられるような上述したいくつか又は全ての機能は、図１１に示されているメモリのようなコンピュータ可読媒体に格納された命令を実行するプロセッサ１２１により提供される。ノードＢの別の実施例は、上述の機能のいずれかと上述した解決策のいずれかをサポートするのに必要な何らかの機能との内の少なくともいずれかを含む付加的な機能の提供を担当する付加的な構成要素を含んでもよい。
【００６１】
さらに図１２に、ＲＮＣのような代表的な中央ノード１０９を示す。例示する中央ノード１０９はプロセッサ１３１の形態のコントローラと、メモリ１３３と、ノードＢや移動体交換センタのようなセルラネットワークの他のノードとの接続のためのネットワークインタフェース１３４とを含む。特定の実施例において、中央ノードにより備えられるもとして上述したいくつか又は全ての機能、特に上述した解決策のいずれかをサポートするのに必要な何らかの機能は、メモリ１３３のようなコンピュータ可読媒体に格納された命令を実行するプロセッサ１３１により提供される。
【００６２】
要約すると、ＮＢＡＰ／ＲＮＳＡＰ制御メッセージとＩｕｂ／Ｉｕｒ制御フレームとデータフレームとの内の少なくともいずれかがＲＮＣにより用いられ、ＵＥがＲＡＣＨでアップリンク送信を実行し、引き続きダウンリンク送信を監視していることをノードＢに示す。或いは、新しい又は変形された制御メッセージと制御／データフレームとが用いられても良い。
【００６３】
上述の例はＮＢＡＰとＩｕｂフレームプロトコルに対して与えられた。同様の例がＲＮＳＡＰとＩｕｒフレームプロトコルに適用される。
【００６４】
ここで説明された方法及びデバイスを用いることでＲＡＣＨでのアップリンク送信に対するダウンリンクでのより迅速な応答を提供することができる。加えて、呼設定時間が削減される。
【図１】
0006054534.tif 000004
【図２】
0006054534.tif 000005
【図３】
0006054534.tif 000006
【図４】
0006054534.tif 000007
【図５】
0006054534.tif 000008
【図６】
0006054534.tif 000009
【図７】
0006054534.tif 000010
【図８】
0006054534.tif 000011
【図９】
0006054534.tif 000012
【図１０】
0006054534.tif 000013
【図１１】
0006054534.tif 000014
【図１２】
0006054534.tif 000015