(57)【特許請求の範囲】
【請求項１】
無線ローカルエリアネットワークにおける移動端末復号化失敗処理を実行する方法であって、
ネットワークの移動端末からネットワークのアクセスポイントに対して所定の休眠インターバルを含む休眠要求を送信し、
アクセスポイントからの、休眠期間と移動端末の休眠開始時間を含み、スリープ期間はネットワークでの情報報知インターバルの倍数である休眠予約を移動端末で受信し、
移動端末がスリープ開始時間に休眠状態に入り、
移動端末が、休眠期間の最後に、ネットワークのアクセスポイントから送信された媒体アクセス制御（ＭＡＣ）中の目覚まし通知を受け取る過程を有する方法であって、前記方法はさらに、
移動端末がネットワークのアクセスポイントから送信された媒体アクセス制御（ＭＡＣ）フレーム中の目覚まし通知の復号化に失敗したか否かを、移動端末が決定し、
移動端末は、復号化失敗の決定に応答して、所定の数のＭＡＣフレームを受信するか、移動端末を目覚めさせるための目覚まし通知が適切に復号化されるか何れか早い方が行われるまで、目覚めた状態で、続いて到来するＭＡＣフレームを監視する過程を有し、
さらに、ネットワークのアクセスポイントから送信された媒体アクセス制御（ＭＡＣ）フレームの目覚まし通知を、ネットワーク内の移動端末が復号化に失敗したか否かをネットワークでのアクセスポイントが決定し、
再送信の回数が所定の閾値に到達するか、移動端末が再送信された目覚まし通知のうちの一つの復号化に成功するか何れか早い方が発生するまで、当該移動端末に対して次に予定されている目覚まし通知送信期間より前に、アクセスポイントから移動端末に対して引き続くＭＡＣにおいて目覚まし通知を再送信する過程を有することを特徴とする方法。
【請求項２】
目覚まし通知がポーリング要求を含み、移動端末がポーリング要求に対する応答に失敗したときに、移動端末が目覚まし通知の適切な復号化に失敗したと決定する請求項１に記載の方法。
【請求項３】
アクセスポイントが目覚まし通知にゼロ値のポインターを含めたとき、移動端末は目覚まし状態で、次の通知があるまで、各報知チャネル（ＢＣＣＨ）とフレーム制御チャネル（ＦＣＣＨ）を復号化する請求項１に記載の方法。
【請求項４】
アクセスポイントが目覚まし通知にゼロ値のポインターを含めることによって帯域幅の使用を最小化する請求項３に記載の方法。
【請求項５】
アクセスポイントが少なくとも２つの目覚まし通知を移動端末へ送信し、少なくとも２つの目覚まし通知のそれぞれがゼロ値のポインターを含む請求項３に記載の方法。
【請求項６】
前記所定のＭＡＣフレームの数は、１より大きい請求項１に記載の方法。
【請求項７】
ゼロの指示値が、ａ）ＭＡＣフレームが移動端末のダウンリンクデータを有しておらず、ｂ）移動端末が将来提供されるダウンリンクデータを待ち受けるために目覚めた状態であるべき旨を示す請求項６に記載の方法。
【請求項８】
ゼロの指示値は、移動端末がアクセスポイントに応答信号を送信すべきでないことを示す請求項７に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の技術分野】
本発明は全般的に無線ローカルエリアネットワーク通信分野に係り、特にＬＡＮ内の移動端末の休眠状態の確立と調整に係わる。
【０００２】
【発明の背景】
高い処理効率を備えた無線ＬＡＮサービスの新しい次期標準である、ＥＴＳＩ  ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２は、現存するアプリケーションと新しいアプリケーションのために、新しい機会を切り開くことを約束する。現バージョンと提案されるＥＴＳＩ  ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２の所定の部分をここに参考して明細書に取り込むものとする。ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２  ＬＡＮネットワークは、ＬＡＮネットワークのアクセスポイント（ＡＰ）と移動端末（ＭＴ）が相互に通信するために同じ無線周波数を使用することを意味する、時分割二重（ＴＤＤ）エアリンクを使用する。ＡＰはオペレータのイントラネットと言った、ネットワーク（ＮＷ）に接続され、ＭＴは、ほとんどの場合において、パーソナルコンピューター（ＰＣ）の無線ネットワークインターフェースカード（ＮＩＣ）であろう。
【０００３】
図１は、セル１０２内にＡＰ１０４を収容した典型的なＨＩＰＥＲＬＡＮ  ＴＹＰＥ２システムの一構成例を示すものである。ＭＴ１０６は、１０８および１１０もセル１０２内に位置している。図１に示したように、ＡＰ１０４は、例えば、ＭＴ１１０と無線ＴＤＤエアリンク１１２を介して通信できる。各セル内で、当該セルのＡＰはセル内の１局以上のＭＴと通信するのに最適な周波数を選択する。当該ＡＰの周波数選択は、例えば、他の周波数におけるＡＰの干渉測定に基づき、さらにセル内のＭＴによる測定に基づくことができる。
【０００４】
提案されたＨＩＰＥＲＬＡＮ  ＴＹＰＥ２無線ＬＡＮ標準によれば、無線ＬＡＮシステムは、予約対応ＭＡＣレイヤとして実行される媒体アクセス制御（ＭＡＣ）レイヤを有している。図２は、報知制御チャネル（ＢＣＣＨ）２０２、フレーム制御チャネル（ＦＣＣＨ）２０４、ダウンリンクチャネル（ＤＬＣＨＡＮ）２０６、アップリンクチャネル（ＵＬＣＨＡＮ）２０８およびランダムアクセスチャンネル（ＲＡＣＨ）２１０を収容した典型的なＭＡＣフレーム構造を具備した典型的なＭＡＣデータフレーム２００を示すものである。図２に示されたように、ＵＬＣＨＡＮ２０８とＲＡＣＨ２１０との間の境界と同様に、ＤＬＣＨＡＮ２０６とＵＬＣＨＡＮ２０８との間の境界は、トラフィック要求に従って変化しうる。ＭＴ１１０が認証され、接続がＭＴ１１０とＡＰ１０４との間で確立されたと仮定すると、次に、ＡＰ１０４を介してアップリンク（ＵＬ）データを送信するために、ＭＴ１１０はランダムアクセスの機会を検出するために、ＢＣＣＨ２０２とＦＣＣＨ２０４を監視する。ＭＴ１１０はＲＡＣＨ２１０を介してアップリンクリソースを要求することができ、ＡＰ１０４はアップリンクリソース要求を受信確認し、ＭＴ１１０による使用に対して、ＴＤＤエアリンク１１２でのＵＬリソースを予定に入れ始める。すなわち、ＭＴ１１０がアップリンクリソース要求を出したときに、予約対応接続が開始する。
【０００５】
ＭＴ１１０が休眠状態か、次の可能な機会にＭＴ１１０へＤＬデータを送信する場合に、ＡＰ１０４が、ＭＴ１１０に対してネットワーク（ＮＷ）からダウンリンク（ＤＬ）データを受信するとき、ＡＰ１０４はデータをバッファに蓄積し、ＭＴ１１０へのデータ送信を保留する。ＡＰ１０４は、ＭＡＣ−ＩＤとＢＣＣＨ２０２の次のＦＣＣＨ２０４にＭＴ１１０のデータリンク制御チャネルＩＤ（ＤＬＣＣ−ＩＤ）を具備したフレーム２００の形式を有するフレームを送信することによってＭＴ１１０（および／または、セル１０２内の他のＭＴ）に対してデータを有することを知らせる。この状況において、ＦＣＣＨ２０４は、ＭＴ１１０に対してフレーム２００のＤＬＣＨＡＮ２０６でのデータの正確な位置情報も含んでいる。ＭＡＣ−ＩＤを有するＭＴは、複数のＤＬＣＣ−ＩＤを有することができる。
【０００６】
ＭＴは、ほぼ、蓄電池のような有限なソースによって電力供給されているので、ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２標準はＭＴのエネルギー利用を保護するためにＭＴに対して休眠モードを提供する。この休眠モードは、図３にて略述されている。図３に示したように、第一ステップ３０２において、ＭＴは休眠の時間間隔、すなわち、ＡＰに送る休眠期間に関するＭＴによる示唆を収容可能な休眠要求信号を送信する。ＡＰは休眠要求信号を受信し、開始時間と休眠期間を決定し、ステップ３０４にて、ＭＴがＭＴに待機中のＤＬデータを発生させるために、ＡＰからＭＡＣフレームのＢＣＣＨを監視するための「目覚まし」の前に、ＭＴが休眠モードに入るべき開始時間とＭＴが休眠状態にある休眠期間または時間を示した休眠予約信号をＭＴへ送信する。休眠期間は、例えば、任意のＭＡＣフレームの数であってもよい。ステップ３０６において、ＭＴが休眠モードに入って、次にステップ３０８において、休眠期間の有効期間が終了するとき、ＭＴは休眠から目覚めて、ＭＴに待機中のＤＬデータの指示にてＢＣＣＨを監視する。ＤＬデータが待機している場合、ＡＰはＢＣＣＨを介してＭＴに通知し、ＭＴへＤＬデータのダウンロードを行う予定となろう。
【０００７】
特に、ＭＴは、ＢＣＣＨが待機データ標識のような、ダウンリンクデータが未定のＭＴのためにＡＰに待機している旨を示す信号を有することを認識した場合、ＭＴは、ＭＴに向けられた特定の目覚ましＰＤＵを求めてＭＡＣフレームの低速報知チャネル（ＳＢＣＨ）の内容を分析する。ＭＡＣフレームでのＳＢＣＨの位置は、ＦＣＣＨでの情報要素（ＩＥ）によって提供される。すなわち、ＭＴはさらに、待機中のデータがそのＭＴ向けに待機しているのか否か（あるいは、そのＭＴはデータが待機している複数のＭＴに含まれるのか否か）を確認して決定する。ダウンリンクデータがどのＭＴのためにも待機していない場合、ＭＴは、休眠待機時間だけ休眠モードに戻り、当該時間の終わりには目を覚まして、ＢＣＣＨの待機データ標識を監視するサイクルを繰り返す。待機しているデータ標識が存在していないか、当該指示がダウンリンクデータが待機していないことを示す場合、ＭＴは休眠状態に戻る。
【０００８】
図４は、特定の目覚ましＰＤＵを求めてＭＡＣフレームのＳＢＣＨを分析する場合を示すものである。図４に示したように、ＭＴの休眠時間が、時刻４２０で終了すると、最初にＭＴは、ＢＣＣＨ４１０を検査して、ＢＣＣＨ４１０に、ＭＡＣフレーム４０６がＭＴに対するデータを有することを示した待機データ標識が含まれているか否かを決定する。当該待機データ標識は、データが存在している場合にも、どのＭＴにデータが提供されるべきかを示していない。ＢＣＣＨ４１０での待機中のデータ標識が、ＭＡＣフレーム４０６が不特定のＭＴに対するデータを有していることを示す場合、ＭＴはＭＡＣフレーム４０６がそれに対するデータを有するか否かを決定しようとする。それは、ＳＢＣＨ４１８がＭＡＣフレームで開始する位置に関する指示に対して、ＦＣＣＨ４１２を分析することによって行う。例えば、ＦＣＣＨ４１２は、ＳＢＣＨ４１８が開始する位置を示す所定の情報要素（ＩＥ）４１４を有しうる。例えば、所定のＩＥ４１４はＭＡＣ識別（ＭＡＣ−ＩＤ）＝０、および、ダウンリンク制御チャネル識別（ＤＬＣＣ−ＩＤ）＝０を有するように定義できる。
【０００９】
ＳＢＣＨは、ＭＡＣフレーム４０６のＤＬＣＨＡＮに位置する。ＤＬＣＨＡＮはＳＢＣＨを含む複数の論理チャネルを含むか、これを支持することができる。前記チャネルは、例えば、ユーザーデータチャネル（ＵＤＣ）、「データリンク制御」を表すＤＬＣ制御チャネル（ＤＬＣＨ）、専用制御チャネル（ＤＣＣＨ）、帯域内チャネル（ＩＢＣＨ）および，上記記載の低速報知チャネル（ＳＢＣＨ）を収容することができる。
【００１０】
ＭＴは、ＳＢＣＨ４１８がＭＴのＭＡＣ−ＩＤを収容する目覚ましＰＤＵのうちどれかを有するか否かを決定するためにＳＢＣＨ４１８を分析する。結果が肯定的である場合、ＭＴはダウンリンクデータが待機していることを認識して、ＭＴがダウンリンクデータを受信するために能動状態になる。結果が否定的である場合、ＭＴはダウンリンクデータがＭＴに待機していないことを認識して、ＭＴはＡＰに通知せずに自動的に休眠モードに戻る。
【００１１】
ＭＴがＡＰに転送すべき、待機中のアップリンクデータを有する場合、ＭＴは休眠期間タイマー、または、時間周期を短縮して、例えば、ＭＡＣフレーム２００のＲＡＣＨ２１０上にアップリンクリソース要求信号を送信することによってＡＰからのアップリンクリソースを要求することができる。
【００１２】
モビテックスおよびＰＡＣＴ（パーソナルエア通信システム）システムにおいては、モバイルは、ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２のケースとは異なる休眠段階の設計概念を認識している必要がある。
【００１３】
しかし、上述の方法は、複数の欠点を有する。例えば、ＭＴがＢＣＣＨ、ＦＣＣＨおよび所定の目覚ましでのＳＢＣＨを適切な復号化に失敗した場合の、ＭＴとＡＰの挙動は知られていない。ＭＴがＢＣＣＨ、ＦＣＣＨまたはＳＢＣＨを符号化し損なったときに、ＭＴが休眠状態に戻ると仮定すると、ＡＰは、ＭＴが首尾よくＭＴを目覚めさせるためにＡＰから送信された目覚まし情報（例えば、目覚まし通知）を復号化したか否か、あるいは、ＡＰが適切に（例えば、目覚まし情報が、目覚まし情報にて識別されたＭＡＣフレームでの予約アップリンクチャネル上で、または、次の有効なＲＡＣＨを介してＡＰに所定の信号と返すといった、受信確認信号をＭＴに指示して送信させる状況において）ＭＴからの受信確認を復号化または認識し損なったか否かを認識できない。目覚まし情報は、例えば、例えば、ＦＣＣＨに位置した目覚まし情報要素（ＩＥ）、あるいは、ＳＢＣＨに位置した目覚ましパケットデータユニット（ＰＤＵ）である可能性がある。
【００１４】
ＡＰも、ＭＴがＢＣＣＨ，ＦＣＣＨまたはＳＢＣＨを適切な復号化に失敗した状況を認識できない。すなわち、ＡＰは、結局ＭＴの状態を認識できない。さらに、ＭＴがＢＣＣＨ、ＦＣＣＨまたはＳＢＣＨを適切な復号化に失敗した状況において、ＭＴが休眠に戻ると仮定すると、ＡＰは、ＭＴが再度ＭＴとの通信を確立しようとする前に、再度目覚めるまで待機する必要がある。
【００１５】
特に、ＡＰがＭＴに目覚まし通知を送信して、ＭＴが適切にＢＣＣＨ、ＦＣＣＨまたはＳＢＣＨの復号化に失敗し、このように、ＭＴに提供される目覚ましＩＥまたはＰＤＵを逃したとき（ＭＴのＭＡＣ−ＩＤに適合する目覚ましＩＥまたはＰＤＵでのＭＡＣ−ＩＤは、目覚ましＩＥまたはＰＤＵはＭＴに提供されることを示す）、ＡＰは、ＭＴが首尾よく目覚まし通知を受信し、ダウンリンクデータを受信の準備が行われることを前提とする。次に、ＡＰはＭＴに待機しているダウンリンクデータを送信し始める。ＭＴがアクティブでなく、目覚まし通知を逃した後に休眠状態に戻った場合、ＡＰの再送タイマーは、待機中のダウンリンクデータを検査するために再度目覚める前に時間切れとなり、その結果、ＡＰは、セルに存在する認識されたＭＴのリストからＭＴを削除することになる可能性がある。
【００１６】
さらに、ＭＴが、ＢＣＣＨ、ＦＣＣＨ、または、ＳＢＣＨの復号化に失敗したときに、ＡＰに新しい休眠要求信号を送信することを要求されると、休眠要求信号は、ＭＡＣフレームの他のデータトラフィックと衝突し、予期せぬ遅延およびＡＰが解決解決しなければならない複雑な状況を引き起こす。目覚まし通知が送信されたすべてのＭＴへの送信が、休眠要求信号を送信すべきすべてのＭＴがこれを完了したとＡＰが決定できるまで保留されるとすれば、ＡＰと１局以上のＭＴとの間のデータ送信は、望ましくないほど遅延する可能性がある。
【００１７】
【発明の要旨】
本発明の典型的な実施例によれば、ＭＴへの目覚まし通知の形式は、ＭＴが目覚まし通知を受信確認するように要求されるか否かを指示することができ、ＭＴはＢＣＣＨ、ＦＣＣＨまたはＭＴに対して目覚まし通知を有するかもしれないＳＢＣＨを復号化し損なうとき、ＭＴはＡＰからＭＴに対しての新規の目覚まし通知の存在を予期するために、連続するＭＡＣフレームを復号化する。
【００１８】
本発明の別の実施例によれば、現在のトラフィックの総計およびスケジューラーとＡＰでの休眠通知エンティティにて実施されるアルゴリズムに応じて、ＭＴに向けた第二番目の目覚まし通知は、ＭＴに対して第一番目の目覚まし通知を有したＭＡＣフレームに続く次のＭＡＣフレームに収容されうる。トラフィックが増すので、第二番目の目覚まし通知が第一番目の目覚まし通知を有したＭＡＣフレームに続く次のＭＡＣフレームに続いたＭＡＣフレームに収容される可能性も増加する。
【００１９】
本発明の別の実施例によれば、ＭＴに対して目覚まし通知を有するかもしれないＢＣＣＨ、ＦＣＣＨまたはＳＢＣＨを首尾よく復号化した後に、ＭＴは、所定のＭＡＣフレームの数（Ｎｆｒａｍｅｓ）が発生するか、ＭＴが首尾よく目覚まし通知を受信するまで、ＭＴに対して目覚まし通知を発生させるために連続したＭＡＣフレームを監視しつづける。ＭＴが首尾よく目覚まし通知を受信するとき、ＭＴは目覚めている状態であろう。
【００２０】
本発明の別の実施例によると、ＡＰは、ダウンリンクデータがＭＴに待機中であることを示した目覚まし通知をＭＴに送信するとき、ＭＴがアクティブ、すなわち、目覚めているかのようにＡＰは続行するだろう。ＡＰは、（例えば、ＭＴがＭＴへ受信確認信号を返信すべき旨を示した目覚まし通知を送信することによる）送信データのＭＴの優先権をポーリングしているか否かに応じて、ＡＰは、例えば、所定のＭＡＣフレームの数が発生するまでの設計上可能な回数で、ポーリング要求を再送信するであろう。
【００２１】
ポーリングが使用されていない場合、ＡＰは、例えば、ＭＡＣフレームの所定の回数（Ｎｆｒａｍｅｓ）の設計上可能な回数までデータを送信または再送信しつづけるであろう。設計上可能な回数は、再送信の最大許容送信回数によって制限、または、それに基づくことが可能である。
【００２２】
本発明の実施例によれば、前記の特徴は様々に組み合わせることも可能である。
【００２３】
【図の詳細な説明】
本発明の様々な実施例は、ＳＢＣＨに位置した目覚ましＰＤＵよりむしろ、目覚まし情報がＦＣＣＨに位置した目覚ましＩＥを収容する状況において使用もされうる。特に、ＭＴは、ＢＣＣＨが、データリンクがＭＴに対してＡＰにて待機中である指示を有することを認識する場合、ＭＴは、情報要素（ＩＥ）に対してＭＡＣフレームでＦＣＣＨの内容を分析するか、または、ダウンリンクデータを示した目覚ましＰＤＵを予定に入れるか、ＰＤＵはＭＴに待機している。
【００２４】
図５は、ＭＴは、ダウンリンクデータがＭＴに対して待機中である旨を示して、ＭＴのＭＡＣ−ＩＤを具備した情報要素（ＩＥ）に対してＭＡＣフレームでのＦＣＣＨの内容を分析する場合を示すものである。このように、図５に示されたように、ＭＴ休眠時間が、時間５２０にて有効期間が終了するとき、ＭＴは、最初にＢＣＣＨ５１０が図４に関して記述されたような、ＭＡＣフレーム５０６がＭＴに対してデータを収容している旨を示した待機中のデータ指示を有するか否かを決定するためにＢＣＣＨ５１０を調査する。ＢＣＣＨ５１０での待機中のデータ指示は、ＭＡＣフレーム５０６が不特定のＭＴに対してデータを有することを示す場合、ＭＴはＭＡＣフレーム５０６がＭＴに対してデータを有するか否かを決定しようとする。ＦＣＣＨ５１２が、目覚ましＩＥ５１４のような、ＭＴのＭＡＣ−ＩＤを収容する目覚まし通知ＩＥを有するか否かを決定するために、ＦＣＣＨ５１２を分析することによって行う。はい、の場合、ＭＴは、ＭＴに対して待機中のダウンリンクデータが存在することを認識し、待機中のデータを受信するために、アクティブ状態（すなわち、起きている）になるであろう。いいえ、の場合、ＭＴは、ＭＴに待機中のダウンリンクデータが存在しないことを認識し、ＡＰに通知することなく再度、自動的に休眠モードに入る。
【００２５】
データがフレームにて予定されるとき、ＦＣＣＨは常時ＭＡＣフレームに存在するので、ＡＰが休眠しているＭＴを異なるグループに分配するときに、超過費用を招くことはない。例えば、一局の休眠しているＭＴを目覚めさせるために、ＭＴのＭＡＣ−ＩＤを搬送するＦＣＣＨにて一つのＩＥは必要であり、２つの休眠しているＭＴが目覚める場合は、二つのＩＥはＦＣＣＨなどにて要求される。このように、前記ＳＢＣＨに関するような間接費を避けることは可能である。
【００２６】
さらに、アクティブＭＴでのＩＥがＭＴに対してのＭＡＣ−ＩＤを有しており、ＭＴが受信するように予定されるダウンリンクデータを検索しうるＭＡＣフレームでのダウンリンクチャネルのどれかを示すと推定するので、個々の休眠しているＭＴのＩＥまたは目覚ましＰＤＵは、ＭＴが目覚めた状態、すなわち起きていた場合、ＭＴに信号を送るために単純に同じＩＥを使用できる。
【００２７】
ＩＥまたは目覚ましＰＤＵは、ＭＴがＭＡＣフレーム内の割り当てアップリンクチャネルにてＡＰへ所定の受信確認信号を返送すべき旨をＭＴに指示する形式にもなりうる。ＩＥは、ＡＰがＭＴのために保留していた割り当てアップリンクチャネルを識別する。このように、ＩＥは、ＡＰからＭＴへポーリング要求として使用されうる。択一的に、まず、ＲＡＣＨが有効な状態になると、ＩＥは同じＭＡＣフレームまたは連続するＭＡＣフレームでのＲＡＣＨを介して所定の受信確認信号をＭＴに指示してＡＰへ返送させることができる。ＦＣＣＨはＳＢＣＨよりも早くＭＡＣフレームに配置されるので、ＳＢＣＨの代わりに、ＦＣＣＨにＩＥを配置するのは、目覚めさせて準備し、所定の受信確認信号を送信するのに更なる時間を要する。
【００２８】
ＩＥまたは目覚ましＰＤＵはゼロ値のポインター、すなわち、ＩＥにてゼロ値に設定されるポインターも含むことが可能である。ゼロ値は、ＭＴにＭＡＣフレームがＭＴに対してダウンリンクデータを有しないことを示し、ＭＴは、将来提供されるダウンリンクデータを受信するために通知して、ＢＣＣＨとＦＣＣＨを復号化するまで、単純に目覚めた状態にすべきである。例えば、これは、ＭＴが目覚める同じＭＡＣフレームでの新しいＭＴを処理する方法でＡＰのスケジューラーを提供できる。
【００２９】
本発明の第一番目の実施例によれば、ＭＴへの目覚まし通知の形式は、ＭＴが目覚まし通知を受信確認するために要求されるか否かを指示することができ、ＭＴがＢＣＣＨ、ＦＣＣＨまたはＭＴに対しての目覚まし通知を有するかもしれないＳＢＣＨの復号化に失敗したときに、ＭＴはＡＰからＭＴへ新しい目覚まし通知の存在を予期するために連続するＭＡＣフレームを復号化する。
【００３０】
本発明の第二番目の典型的な実施例によれば、存在するトラフィックの総和およびスケジューラーとＡＰでの休眠通知エンティティにて実施されるアルゴリズムに応じて、ＭＴに向けた第二番目の目覚まし通知はＭＴに対しての第一番目の目覚まし通知を有したＭＡＣフレームに続く次のＭＡＣフレームに収容することが可能である。トラフィックが増すので、第二番目の目覚まし通知が第一番目の目覚まし通知を有したＭＡＣフレームに続く次のＭＡＣフレームに連続するＭＡＣフレームに収容される可能性も増加する。
【００３１】
本発明の第三番目の典型的な実施例によれば、首尾よくＭＴに対しての目覚まし通知を有するかもしれないＢＣＣＨ、ＦＣＣＨまたはＳＢＣＨを復号化した後に、ＭＴは、所定のＭＡＣフレームの数が発生するか、ＭＴが首尾よく目覚まし通知を受信するまで、ＭＴに対しての目覚まし通知を発生させるために連続するＭＡＣフレームを監視しつづけるだろう。ＭＴが首尾よく目覚まし通知を受信するとき、ＭＴは起きた状態であろう。
【００３２】
本発明の第四番目の典型的な実施例によれば、ＡＰは、ＭＴにダウンリンクデータが待機中であることを示した目覚まし通知をＭＴに送信するとき、ＡＰはＭＴがアクティブ、すなわち、起きているかのように続行するだろう。ＡＰが（例えば、ＭＴが受信確認信号をＭＴへ返送すべきである旨を示した目覚まし通知を送信することによって）送信データのＭＴの優先権をポーリングしているか否かに応じて、ＡＰはポーリング要求を設計上可能な回数、例えば、所定のＭＡＣフレーム数が発生するまで、再送信するだろう。
【００３３】
ポーリングが使用されていない場合、ＡＰは、データを設定上可能な回数、例えば、所定のＭＡＣフレームの数が発生するまで再送信するだろう。設定上可能な数は再送信の最大許容に基づくことが可能であり、または、制限されうる。
【００３４】
図６は、全般的にＭＴの展開から本発明の典型的な実施例に対しての上記に記載の原理を説明するものである。図６に示されたように、ステップ６０２にて開始した後に、制御は、ＭＡＣフレームを監視するために目覚めたＭＴが、ＭＴに対しての目覚まし通知を有することが可能であったＭＡＣフレームでＢＣＣＨ、ＦＣＣＨまたはＳＢＣＨを適切な復号化に失敗した旨を決定するステップ６０４に進む。ステップ６０４から、制御は、カウンターＮがゼロに設定されるステップ６０６に進み、ステップ６０６から、制御が、ＭＴが次のＭＡＣフレームにてＢＣＣＨおよびＦＣＣＨを復号化するステップ６０８に進む。ステップ６０８から、制御は、カウンターＮが増加していくステップ６１０に進み、ステップ６１０から、制御はステップ６１２へ進む。ステップ６１２において、ＭＴは、最新のＭＡＣフレームがＭＴに向けた目覚まし通知を有したか否かを決定する。はい、の場合、制御は、ＭＴが適切に目覚まし通知を処理する、ステップ６１２からステップ６１４に進み、制御は、ステップ６１４から当該過程が終了するステップ６２０へ進む。ステップ６１２において、ＭＴが最新のＭＡＣフレームがＭＴに対しての目覚まし通知を含んでいなかったことを決定する場合、制御は、Ｎが所定値Ｎｆｒａｍｅｓと比較されるステップ６１２からステップ６１６へと流れる。Ｎが所定値Ｎｆｒａｍｅｓ以上である場合、制御は、ＭＴが休眠状態に戻るステップ６１８に進む。ステップ６１８から、制御は、ステップ６２０へ進む。ステップ６１６において、Ｎが所定値Ｎｆｒａｍｅｓより小さい場合、制御はステップ６０８に戻って、サイクルを繰り返す。
【００３５】
図７は、全般的にＡＰの展開から、本発明の典型的な実施例に対しての上記記載の原理を説明するものである。図７に示されたように、当該過程はステップ７０２で開始し、そして、ＡＰがＭＡＣフレームにて、目覚まし通知をＭＴへ送信するステップ７０４へ進む。ステップ７０４から、制御は、カウンターＭがゼロに設定されるステップ７０６へ進む。ステップ７０６から、制御は、目覚まし通知がＭＴへのポーリング要求であったか否かが決定されるステップ７０８へ進む。はい、の場合、制御は、ＡＰがＭＴからポーリング受信確認信号を受信したか否かを決定するステップ７１０へ流れる。はい、の場合、制御は、ステップ７１０からステップ７１８へ進み、当該過程は終了する。いいえ、の場合、制御は、ＡＰが次の有効な機会において、連続するＭＡＣフレームでのＭＴへポーリング要求を再送信するステップ７１０からステップ７１２へ進む。ステップ７１２から、制御は、カウンターＭが増加していくステップ７１４へ進む。ステップ７１４から、制御は、Ｍが所定値Ｍｒｅｔｒａｎｓｍｉｓｓｉｏｎｓと比較されるステップ７１６へ進む。Ｍが所定値Ｍｒｅｔｒａｎｓｍｉｓｓｉｏｎｓ以上である場合、制御は、ステップ７１６からステップ７１８へ進み、当該過程は終了する。Ｍが所定値Ｍｒｅｔｒａｎｓｍｉｓｓｉｏｎｓより小さい場合、制御はステップ７１６から７１０へ戻る。
【００３６】
ステップ７０８にて、目覚まし通知がポーリング要求でなかったことが決定される場合、制御は、Ｍの値が増加していくステップ７０８からステップ７２４へ進む。ステップ７２４から、制御は、Ｍの値が所定値Ｒｒｅｔｒａｎｓｍｉｓｓｉｏｎｓと比較されるステップ７２６に進む。Ｍの値が所定値Ｒｒｅｔｒａｎｓｍｉｓｓｉｏｎｓ以上の場合、制御は、ステップ７２６からステップ７１８へ進んで、当該過程は終了する。Ｍの値が所定値Ｒｒｅｔｒａｎｓｍｉｓｓｉｏｎｓより小さい場合、制御は、ＡＰが、ＭＴは首尾よく目覚まし通知を受信したか否かを決定するステップ７２６からステップ７２０へ進む。ＡＰは全般的に、ＭＴが首尾よく、例えば、技術的に周知の自動繰り返し要求（ＡＲＱ）の原理を使用して、目覚まし通知を受信したか否かを決定することができる。最初に送られたときに受信しなかった場合、ＭＡＣレイヤが非受信確認モードで動作するか、データにとって時間が重要な意味を有し、送信時に受信されなければ意味を失う場合、所定値Ｒｒｅｔｒａｎｓｍｉｓｓｉｏｎｓは１に設定されうる。ステップ７２０において、ＡＰは、ＭＴが首尾よく目覚まし通知を受信したことを決定する場合、制御は、ステップ７２０から７１８に進んで、当該過程は終了する。ＭＴが、首尾よく目覚まし通知を受信しなかった場合、制御は、ＡＰが目覚まし通知と次の有効な機会において連続するＭＡＣフレームにてＭＴに対しての関連する待機中のダウンリンクデータのどれかを再送信するステップ７２０からステップ７２２へ進む。ステップ７２２から、制御はステップ７１８へ進んで、当該過程は終了する。
【００３７】
図８は、本発明の典型的な実施例に従って、典型的なＡＰの内部詳細を示すものである。特に、ＡＰ８００はスケジューラーエンティティ８０２と休眠通知エンティティ８０４を収容することができる。
【００３８】
当業者は、上記記載の特徴が様々に組合せ可能であることを理解するであろう。
【００３９】
「無線ローカルエリアネットワークにおける移動端末休眠段階割当てと通知」と言うタイトルで、代理人整理番号０４００００−５２８と同一かつ本出願と同日に出願された出願中かつ共有に係る出願は、ここでは参考文献によって具体化される。
【００４０】
当事者は、上記で参照した出願中かつ共有に係る出願にて記載された特徴と実施例は好適に本出願で記載された特徴と実施例と組み合わせうることを理解するだろう。
【００４１】
エリクソン書類番号ＥＲＶＳ−９９０１３、ＥＲＶＳ−９９０２１およびＥＲＶＳ−９９０２２は、ここでは参考文献によって具体化され、各付則Ａ、ＢおよびＣとして整理されている。
【００４２】
１９９９年４月７日に公示された提案中のＥＴＳＩ  ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２の所定の部分は、ここで参考文献によって具体化されて、付則Ｄとして整理されている。
【００４３】
本発明は、本来の意図または特徴から離れることなく他の特定の形式にて具現化され、記載された特定の実施例に制限されることがないことは当事者には明らかである。現在特許公開された実施例は、すべての点において説明および制限されることなく考慮されている。本発明の範囲は詳細な説明よりもむしろ特許請求項によって具体化され、意味および範囲および同義語の範囲内にあるすべての変化は含まれている。
【図面の簡単な説明】
添付図を熟読することにより、本発明の他の目的と長所は、上記の好ましい実施例の詳細な説明から当事者に対しては明らかとなるであろう。添付図の同じ要素は参考文献の同じ数字によって示されている。
【図１】  図１は、ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２標準に従って典型的なセル構造を示すものである。
【図２】  図２は、ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２標準に従って典型的なＭＡＣフレームを示すものである。
【図３】  図３は、ＨＩＰＥＲＬＡＮ  ＴＹＰＥ２標準に従ってＭＴとＡＰとの間の典型的な休眠交渉対話形式を示すものである。
【図４】  図４は、ＭＡＣフレームのＳＢＣＨに位置した目覚ましＰＤＵを具備することが可能な典型的なＭＡＣフレームを示すものである。
【図５】  図５は、本発明の典型的な実施例に従って典型的なＭＡＣフレームを示すものである。
【図６】  図６は、本発明の典型的な実施例に従う過程のフローチャートを示すものである。
【図７】  図７は、本発明の典型的な実施例に従う過程のフローチャートを示すものである。
【図８】  図８は、本発明の典型的な実施例に従う典型的なＡＰの内部詳細を示すものである。
【図１】
0004562922.tif 000002
【図２】
0004562922.tif 000003
【図３】
0004562922.tif 000004
【図４】
0004562922.tif 000005
【図５】
0004562922.tif 000006
【図６】
0004562922.tif 000007
【図７】
0004562922.tif 000008
【図８】
0004562922.tif 000009