(57)【特許請求の範囲】
【請求項１】
セルラ無線システムにおいて第1の通信装置と第2の通信装置との間の通信接続をリセットする方法であって、
前記通信接続をリセットする必要性を検出するステップ(201、404)と、
前記通信接続をリセットする必要性を示す第1の情報(203、210)を前記第1の通信装置から前記第2の通信装置へ送信するステップ(202、209)と、
前記第2の通信装置においてリセット処理手順を実行するステップ(205、212、411、422)と、
前記第2の通信装置に関する前記リセット処理手順の完了を示す第2の情報(207、214)を前記第2の通信装置から前記第1の通信装置へ送信するステップ(206、213、424)と、を有する前記方法において、
前記第1の通信装置から前記第2の通信装置へ送信される、前記通信接続をリセットする必要性を示す前記第１の情報の中へシーケンス番号を挿入するステップであって、前記通信接続をリセットする必要性を示す前記第1の情報を前記第1の通信装置から前記第2の通信装置へ送信する前記ステップから、前記第2の通信装置と関連するリセット処理手順の完了を示す前記第2の情報を前記第1の通信装置において障害なく前記第2の通信装置から受信するステップまで、前記通信接続をリセットする必要性が検出された後も、前記シーケンス番号の値が同じままである、シーケンス番号を挿入するステップを有することを特徴とする方法。
【請求項２】
セルラ無線システムにおいて第1の通信装置と第2の通信装置との間の通信接続をリセットする方法であって、
前記通信接続をリセットする必要性を検出するステップ(501、604)と、
前記通信接続をリセットする必要性を示す第1の情報(503、510)を前記第1の通信装置から前記第2の通信装置へ送信するステップ(502、509、607)と、
前記第2の通信装置においてリセット処理手順を実行するステップ(505、512、610、621)と、
前記第2の通信装置に関する前記リセット処理手順の完了を示す第2の情報(507、514)を前記第2の通信装置から前記第1の通信装置へ送信するステップ(506、513、623)と、を有する前記方法において、
前記通信接続をリセットする必要性を示す前記第１の情報を第1の通信装置から前記第2の通信装置で受信したことに対する応答として、シーケンス番号の値を前記第2の通信装置において増やすステップと、
前記第2の通信装置から前記第1の通信装置へ送信されかつ前記第2の通信装置と関連する前記リセット処理手順の完了を示す前記第2の情報の中へ、前記シーケンス番号の前記の増やされた値を、前記第2の通信装置において完了したリセット動作の実行結果を示す表示として挿入するステップと、を有することを特徴とする方法。
【請求項３】
前記シーケンス番号が単一のシーケンス番号ビットであって、前記通信接続をリセットする必要性を示す前記第1の情報を前記第1の通信装置から前記第2の通信装置へ送信する前記ステップから、前記第2の通信装置と関連するリセット処理手順の完了を示す前記第2の情報を前記第1の通信装置において障害なく前記第2の通信装置から受信する前記ステップまで、前記通信接続をリセットする必要性が検出された後も、前記シーケンス番号ビットの値が同じままであることを特徴とする請求項1に記載の方法。
【請求項４】
前記シーケンス番号はフレーム構成番号のインジケータであり、該インジケータの値はある現在のフレーム構成の番号を示し、かつ、前記通信接続をリセットする必要性を示す第1の情報を前記第1の通信装置から前記第2の通信装置へ送信する前記第1のステップから、前記第2の通信装置と関連するリセット処理手順の完了を示す第2の情報を前記第1の通信装置において障害なく前記第2の通信装置から受信する次のステップまで、前記通信接続をリセットする必要性が検出された後も、前記インジケータの値が同じままであることを特徴とする請求項1に記載の方法。
【請求項５】
前記フレーム構成番号インジケータはフレーム構成番号を示す完全な値であることを特徴とする請求項4に記載の方法。
【請求項６】
前記フレーム構成番号インジケータはフレーム構成番号を示す完全な値から得られる短縮された派生値であることを特徴とする請求項4に記載の方法。
【請求項７】
前記フレーム構成番号インジケータはフレーム構成番号を示す完全な値から得られる1グループの最下位ビットであり、少なくとも1ビットから構成されることを特徴とする請求項6に記載の方法。
【請求項８】
前記第1の通信装置から前記第2の通信装置へ送信され、前記通信接続をリセットする必要性を示すある情報が、前記第1の通信装置から前記第2の通信装置へ送信され、前記通信接続をリセットする必要性を示した、すでに受信された情報のシーケンス番号と同じ値のシーケンス番号を持つかどうかを前記第2の通信装置でチェックするステップと、
前記チェック時に否定が検出された場合のみの応答として、前記第2の通信装置において完全なリセット処理手順を実行するステップと、を有することを特徴とする請求項1に記載の方法。
【請求項９】
前記チェック時に否定が検出された場合のみの応答として、前記第2の通信装置においてあるフレーム構成番号の値を増やすステップを有することを特徴とする請求項8に記載の方法。
【請求項１０】
前記シーケンス番号が単一ビットであることを特徴とする請求項2に記載の方法。
【請求項１１】
前記通信接続をリセットする必要性を示す前記第１の情報を前記第1の通信装置から前記第2の通信装置において受信したことに対する応答として、前記第2の通信装置においてフレーム構成番号の値を増やすステップと、
前記第2の通信装置から前記第1の通信装置へ送信されるある情報であって、前記第2の通信装置と関連する前記リセット処理手順の完了を示す前記第２の情報の中へ前記フレーム構成番号の前記増やされた値を示すインジケータを挿入するステップと、
前記第2の通信装置と関連するリセット処理手順の完了を示す表示を前記第2の通信装置から前記第1の通信装置において受信したことに対する応答として、前記第2の通信装置から受信した前記インジケータが示す値に等しい値にフレーム構成番号を前記第1の通信装置でセットするステップと、を有することを特徴とする請求項2に記載の方法。
【請求項１２】
前記フレーム構成番号の前記増やされた値を示す前記インジケータが、前記フレーム構成番号自身の前記増やされた値であることを特徴とする請求項11に記載の方法。
【請求項１３】
前記フレーム構成番号の前記増やされた値を示す前記インジケータが、前記フレーム構成番号の前記増やされた値の短縮された派生値であることを特徴とする請求項11に記載の方法。
【請求項１４】
前記フレーム構成番号の前記増やされた値を示す前記インジケータが、前記フレーム構成番号を示す完全な値から得られる1グループの最下位ビットであり、かつ、少なくとも1ビットから構成されることを特徴とする請求項13に記載の方法。
【請求項１５】
通信接続を介するセルラ無線システム内の別の通信装置間で通信を行うための通信装置であって、
前記通信接続をリセットする必要性を検出する手段と、
前記通信接続をリセットする必要性を示す第1の情報と、リセット処理手順の完了を示す第2の情報とを相手方通信装置へ送信する送信手段と、
前記通信接続をリセットする必要性を示す第1の情報と、前記リセット処理手順の完了を示す第2の情報とを前記相手方通信装置から受信する受信手段と、
前記通信接続のリセット処理手順を実行するリセット手段と、を具備する前記通信装置において、
前記通信装置から前記相手方通信装置へ送信される、前記通信接続をリセットする必要性を示す前記第１の情報の中へシーケンス番号を挿入する手段であって、前記通信接続をリセットする必要性を示す前記第1の情報を前記通信装置から前記相手方通信装置へ送信してから、前記相手方通信装置と関連するリセット処理手順の完了を示す前記第2の情報を前記通信装置において障害なく前記相手方通信装置から受信するまで、前記通信接続をリセットする必要性が検出された後も、前記シーケンス番号の値が同じままである、シーケンス番号を挿入する手段を具備することを特徴とする通信装置。
【請求項１６】
通信接続を介するセルラ無線システム内の別の通信装置間で通信を行うための通信装置であって、
前記通信接続をリセットする必要性を検出する手段と、
前記通信接続をリセットする必要性を示す第1の情報と、リセット処理手順の完了を示す第2の情報とを相手方通信装置へ送信する送信手段と、
前記通信接続をリセットする必要性を示す第1の情報と、前記リセット処理手順の完了を示す第2の情報とを前記相手方通信装置から受信する受信手段と、
前記通信接続のリセット処理手順を実行するリセット手段と、を具備する前記通信装置において、
前記通信接続をリセットする必要性を示す前記第１の情報を前記通信装置から前記相手方通信装置で受信したことに対する応答として、シーケンス番号の値を前記相手方通信装置において増やす手段と、
前記相手方通信装置から前記通信装置へ送信されかつ前記相手方通信装置と関連する前記リセット処理手順の完了を示す前記第２の情報の中へ、前記シーケンス番号の前記の増やされた値を、前記相手方通信装置において完了したリセット動作の実行結果を示す表示として挿入する手段と、を有することを特徴とする通信装置。
【発明の詳細な説明】
【０００１】
本発明は、一般に、セルラ無線システムの基地局と端末装置間で機能する通信接続に関する。特に、本発明は通信接続をリセットする処理手順中ある同期局面を維持するタスクに関する。
【０００２】
セルラ無線システムの仕様には、通信装置が実現しなければならないプロトコル層から成るあるプロトコル・スタックが規定されている。ある種のプロトコル層は、装置間で通信接続を行う一対の装置内のピア・エンティティとして互いにサービスを提供し合っている。上記仕様には、このようなピア・エンティティ間の通信接続を設定し、維持し、解除する或る処理手順も規定されている。
【０００３】
一例として、UMTS(ユニバーサル移動通信システム)の仕様について考える。特に、互いに対してピア・エンティティであるMS(移動局)とRNC(無線ネットワーク制御装置)とからなるRLC(無線リンク制御)層について考える。確認応答モードの動作については、ESTI TS 125 322 V3.1.2(2000-01)として知られる公開技術仕様の中に、RLC層に対するリセット処理手順が規定されている。ESTIとは欧州電気通信標準化協会を表わす。前記技術仕様は本明細書に参考文献として取り入れられている。ピアRLCエンティティのいずれかによってプロトコル・エラーが検知された状況で、このリセット処理手順は、RNCとMSのピアRLCエンティティをリセットするために利用される。リセット処理手順のタスクは、エラー状態の解決のために双方のピア・エンティティにおいてすべての対応するプロトコル・パラメータをリセットして、同じネットワーク資源と最初のRLCパラメータの利用によりデータ伝送を継続することである。同時に、プロトコル・パラメータがリセットされると、RLC層が同じ暗号化用マスクをあまり間を置かずに再使用しないようにするために、RLC層はHFN(ハイパ−フレーム番号)の値を1だけ増やす必要がある。
【０００４】
公知のリセット処理手順は、ピアRLCエンティティ間でのあるPDU(プロトコル・データ・ユニット)の交換に依存し、PDUがRNCとMSとの間で問題なく進行するとき良好に機能する。しかし、通信エラーに起因して少なくとも1つのPDUが紛失する状況では公知のリセット処理手順は失敗する。図1は通信しているエンティティがリセット処理手順に関連する第1のPDUの進行方向に応じて送信側と受信側として指定された状況を示す図である。ステップ101で送信側はRLC層のプロトコル・エラーを検知するが、これはリセット処理手順の開始が必要であることを意味する。プロトコル・エラーが検知された時点でのHFN(ハイパ−フレーム番号)をMと仮定する。送信側は、ステップ102で、あるリセットPDUを受信側へ送信することによりリセット処理手順を開始する。リセットPDUは103で示されている。同時に、送信側はTimer RSTとして周知のタイマをセットする。タイマのセットと時間切れとの間の時間が黒い点線として図1に示されている。
【０００５】
ステップ104で、受信側はリセットPDUを受信し、それによってRLCレベルの動作のリセットを行う必要性を認知するようになる。ステップ105で、受信側はすべてのプロトコル・パラメータをリセットし、HFNの現在値を1だけ増やしてM+1にする。これらのタスクの完了後、受信側は、ステップ106で、リセットACK PDUとして周知の確認応答107を送信する。確認応答107の目的は、RLC層のリセットが受信側で完了した旨を送信側に通知することである。“送信側”と“受信側”という名称は第1のPDU103の伝送方向を意味し続けるという点に留意されたい。
【０００６】
ステップ108で、確認応答107は通信エラーに起因して紛失あるいは破損する。確認応答107は送信側に着信することはないので、送信側は確認応答107が送信されたことを全く知らない。ステップ109で、Timer RSTの時間切れが生じるため、送信側は新しいリセットPDU110を送信してTimer RSTの再設定を行う。わずかに左へシフトした点線がTimer RSTの新しいタイミング・ラウンドを表している。送信側の現在のHFN値はまだMのままである。
【０００７】
ステップ111で、受信側は後者のリセットPDU110を受信する。受信側には、確認応答107が紛失したことを知る手段はない。この確認応答の紛失は、第2のリセットPDU110の受信時に受信側がすべてのプロトコル・パラメータをステップ112で再リセットし、HFNの現在値を再び1だけ増やしてM+2にすることを意味する。これらのタスクの完了後、受信側はステップ113で確認応答114を送信する。今度は確認応答は送信側まで届き、送信側はステップ115としてこの確認応答を受信し、ステップ116で送信側の部分に対するすべてのプロトコル・パラメータをリセットし、HFNの現在値を1だけ増やしてM+1にする。1つのリセットACK PDU107が痕跡もなく紛失した結果、ステップ116の後、送信側と発信側のHFN値は異なるものとなる。言い換えれば、送信側と受信側との間のHFNの同期が失われたことになる。今度は、この同期の失敗は、継続されるRLC接続時の解読が失敗する原因となり、その結果、唯一の可能性として、対応する無線ベアラを解除し、新しい無線ベアラを設定するしかなくなるが、これは、遅延と不必要なシグナリング負荷とを引き起こす原因となる。
【０００８】
リセット処理手順と関連する、送信情報の消失に対する良好なロバスト性を備えた通信接続をリセットする方法と装置を提供することが本発明の目的である。
【０００９】
本発明の目的は、同期に関連する変化を引き起こす少なくとも当該送信情報の中にシーケンス番号を含めることにより達成される。
【００１０】
本発明は、セルラ無線システムにおいて第1の通信装置と第2の通信装置間の通信接続をリセットする方法に関し、
通信接続をリセットする必要性を検出するステップと、
通信接続をリセットする必要性を示す第1の情報を第1の通信装置から第2の通信装置へ送信するステップと、
第2の通信装置においてリセット処理手順を実行するステップと、
リセット処理手順の完了を示す第2の情報を第2の通信装置から第1の通信装置へ送信するステップと、を有し、
上記方法は、ある検出された通信接続をリセットする必要性と関連する、あるリセット動作の有効な回数の指示を第1の通信装置と第2の通信装置間で伝送されるある情報の中へ挿入するステップを有することを特徴とする。
【００１１】
本発明は、通信接続を介するセルラ無線システム内の別の通信装置間での通信を行うための通信装置にも適用され、該装置は、
通信接続をリセットする必要性を検出する手段と、
通信接続をリセットする必要性を示す第1の情報と、リセット処理手順の完了を示す第2の情報とを相手側通信装置へ送信する送信手段と、
通信接続をリセットする必要性を示す第1の情報と、リセット処理手順の完了を示す第2の情報とを相手側通信装置から受信する受信手段と、
通信接続のリセット処理手順を実行するためのリセット手段と、を具備し、
上記通信装置は、この通信装置と相手方通信装置との間で伝送されるある情報の中へ、通信接続をリセットするある検出された必要性と関連する、あるリセット動作の有効な回数の指示を挿入する手段を具備することを特徴とする。
【００１２】
試みられた従来技術によるリセット処理手順から結果として生じる可能性がある同期の失敗原因として、リセット処理手順の開始を要求する情報の受信側には、この情報が真正なものであるか、再送コピーであるかを知る手段がないという事実がある。当該情報の中へシーケンス番号を入れることにより、送信側は、それがその情報を送信する第１の試みであるか、後続の試みのいずれであるかを示すことが可能となる。
【００１３】
リセット処理手順の開始を必要とするこの情報の受信側はシーケンス番号をチェックし、受信側が受信した、対応する直前の情報で受信したシーケンス番号と、このシーケンス番号との比較を行う。シーケンス番号が、再送コピーである後者のバージョンを示した場合、受信側は同期局面をそれ以上変えずに、その確認応答を単に送信する。
【００１４】
この問題の別の見方として、完了したリセット処理手順の確認応答を行う当該情報の受信側が、確認応答が真正なものであるか、再送コピーであるかを知る手段を持たないという見方がある。確認応答を送信する通信相手は、この確認応答の中へシーケンス番号を入れることにより、それが確認応答の第1の試みであるか、後続する試みのいずれであるかを示すこともできる。
【００１５】
後者のアプローチによれば、確認応答を受信する装置、すなわち、リセット処理手順の元の起動装置であった装置はシーケンス番号をチェックし、最近開始されたリセット処理手順を行う前の同期局面について記述する予め格納されたある情報と、そのシーケンス番号との比較を行う。相手側の端の装置がリセットを求める複数の開始要求を受信したことがそのシーケンス番号によって示された場合、それに応じて確認応答を受信した装置はその同期局面を変更する。
【００１６】
本発明の非常に単純な実施例では、上記シーケンス番号は1ビット以上である必要はない。リセット処理手順の開始を必要とする情報の後続するすべてのコピーでは、シーケンス番号ビットの値は元のビット値と同じである。1つのリセット処理手順の完了に成功し、かつ、別の処理手順の開始の必要性が生じた場合にのみ、シーケンス番号ビットの値は変更される。確認応答時に、同期局面に対して行われた変更の数はシーケンス番号により示される。
【００１７】
本発明の特徴を示すと考えられる新規な特徴は詳細に請求項に記載されている。しかし、添付図面と関連して読むとき、本発明の構成とその動作方法の双方に関して、本発明の追加の目的と利点と共に、具体的な実施例についての以下の説明により本発明自体を最も良く理解することが可能となる。
【００１８】
図1については従来技術の範囲内で前述したので、以下の説明は図2〜9に関するものとなる。
【００１９】
図2は、図1と同じ様に、リセット処理手順と関連する第1のPDUの進行方向に従う送信側と受信側として通信しているエンティティが指定されている状況を示す図である。ステップ201で送信側はRLC層のプロトコル・エラーを検知する。これはリセット処理手順の開始が必要であることを意味する。プロトコル・エラーを検知した時点でのHFNを再びMと仮定する。送信側は、ステップ202で、受信側へあるリセットPDUを送信することによりリセット処理手順を開始する。リセットPDUは203で示されている。同時に送信側はタイマTimer RSTをセットする。タイマの実行時間を黒い点線として図2に示す。
【００２０】
本発明によれば、リセットPDU203にはシーケンス番号が含まれ、このシーケンス番号をRSN即ちリセット・シーケンス番号として表示する。この値は送信されるリセットPDU203に対してkである。ステップ202でのリセットPDU203の作成と送信に関連して、送信側は、リセットPDU203の中に含まれるRSNの値kを格納する。ステップ204で、受信側はリセットPDU203を受信し、それによってRLCレベルの動作のリセットの必要性が認知されることになる。また受信側はRSNの値kの受信と格納も行う。ステップ205で、受信側はすべてのプロトコル・パラメータをリセットし、HFNの現在値を1だけ増やしてM+1にする。これらのタスクの完了後、受信側はステップ206でリセットACK PDU207を送信する。
【００２１】
確認応答が問題なく送信側へ着信すれば、リセット処理手順は正常に完了し、本発明により追加される新規な特徴が非常に有用なものとして利用されることはない。しかし、ステップ208で、通信エラーに起因して確認応答207が紛失あるいは破損したと仮定する。確認応答207は復号化可能な形で送信側へ着信することはないので、送信側は確認応答207が送信されたことを全く知らない。ステップ209でTimer RSTの時間切れが生じるため、送信側は新しいリセットPDU210の送信を行う。送信側の現在のHFN値はまだMのままである。
【００２２】
本発明によれば、送信側は、新しいリセットPDU210が実際には前回のリセットPDU203の再送コピーであることをステップ209で検知する。なぜならば、Timer RSTの時間切れまでに前回のリセットPDU203に関する確認応答が受信されなかったからである。したがって送信側は、前回のリセットPDU203の中に含まれているRSNの格納値kを読み出し、この格納値kを新しいリセットPDU210の中にそのまま含める。
【００２３】
ステップ211で受信側は後者のリセットPDU210を受信する。今度は受信側は新しいリセットPDU210のRSNの値をチェックし、この値を第1のリセットPDU203で受信した予め格納された値kと比較する。受信側はこれら2つの値が同じであることを検知し、そのことから、確認応答207が紛失した旨を推論することができる。これは第2のリセットPDU210の受信時に、受信側がステップ212でプロトコル・パラメータをリセットしないこと、あるいは少なくともHFNの現在値をそれ以上増やさないことを意味する。ステップ212でプロトコル・パラメータをもう一度リセットしても何ら不都合を生じることはない。なぜならば、RLCパラメータ値はいずれにせよ元の同じ値に戻されるからである。ステップ212の後、受信側はステップ213で新しい確認応答214を送信する。
【００２４】
今回は、確認応答は送信側まで届き、送信側はステップ215でこの確認応答を受信し、送信側の一部に対するすべてのプロトコル・パラメータをステップ216でリセットし、HFNの現在値を1だけ増やしてM+1にする。第2のリセットPDU210のRSN値がkであったことを検知した後、受信側がステップ212でHFNの値をそれ以上増やさなかったため(すなわち第1のリセットPDU203の場合と同じ)、痕跡もなく紛失した1つのリセットACK PDU207は、送信側と発信側のHFN値が異なるという結果を生じることはない。この事実は送信側と受信側との間のHFN同期が維持されることを意味する。
【００２５】
たとえ第2のリセットACK PDU214が紛失したり破損したりしても送信側及び受信側装置の動作は同じままである。このような場合、送信側では、RSN値が第1と第2のリセットPDUの場合と依然同じである第3のリセットPDUを送信できるため、受信側ではステップ211、212、213が繰り返されることになる。通信の継続が不可能になるほど干渉状態や別のエラー源が厳しい状況に、通信資源を予約されたままにしないようにするためには、リセット処理手順の送信側の最大試行回数に対する制限を設けるのが合理的であるかもしれない。
【００２６】
ステップ217で、RLCレベルの通信が送信側と受信側との間で継続される。ステップ218で送信側は、RLC層でのプロトコル・エラーの発生を再び検知する。これは再びリセット処理手順の開始が必要であることを意味する。現在のHFNが今度はTであると仮定することができる。送信側はステップ219で、あるリセットPDUを受信側へ送信することによりリセット処理手順を再び開始する。リセットPDUは220で示されている。最新のリセットPDU220は何らかの別のリセットPDUの再送コピーではないので、この最新のリセットPDU220の中に含まれるRSN値はk以外の別の値、例えばk+1であるRSNをシーケンス番号として示してはいるが、リセットPDU203と220のシーケンス番号値との間にあるはっきりと規定された関係が存在することはあまり重要なことではない。2つのシーケンス番号値が異なっていればそれで十分である）。ステップ219でのこの新しいリセットPDU220の作成と送信に関連して、送信側は、リセットPDU220の中に含まれるRSNの値k+1を格納する。この動作は受信側でのリセットPDU220の受信221から前述したステップへ続く。
【００２７】
もしステップ218でRLC層の新しいプロトコル・エラーを検知したのが送信側ではなくて受信側であったとしたら、動作は前述のものと同じになったであろう。しかし、最新のリセットPDU中のシーケンス番号の値は前回のリセットPDU203の場合とは異なるという唯一の要件さえも今回は解除が可能である。ある装置内の受信リセットPDUから読み出されたシーケンス番号の受信と格納は、当該装置によって送信されるリセットPDUの中に含まれるシーケンス番号の格納とは異なるので、混乱が生じる危険性はない。しかし、個々のリセット処理手順の起動装置にかかわりなく、曖昧性のないようにシーケンス番号を個々のリセット処理手順と関連づけることにより、ある利点を得ることも可能となる。例えば、1ビットより相当に長いあるシーケンス番号が使用され、リセット処理手順に着手する必要があるとき、毎回このシーケンス番号をRLCレベルの接続中1だけ増やす場合、通信接続の観察された統計的品質を示すインジケータとして上記シーケンス番号値の利用が可能となる。
【００２８】
図3は、以上説明した処理手順でリセットPDUを構成する際に好適に利用できるPDU構成を示す。PDU301はNオクテット長であり、D/Cフィールド302と、PDUタイプ・フィールド303と、Rフィールド304と、PADフィールド305とを含む。これらの中で、D/Cフィールド302は、PDUがデータや制御情報を含むかどうかを示すためのフィールドであり、PDUタイプ・フィールド303には当該PDUタイプを示すIDが含まれ、Rフィールド304には予約ビットが含まれ、PADフィールドはパッディング用フィールドである。このパッディング用フィールドの目的は、当該セルラ無線システムの仕様で定められた一般的なPDUの規定にPDU301の長さを統一することである。
【００２９】
シーケンス番号kの最小の長さは1ビットである。したがって、当該ビットが0または1であるかどうかをチェックするだけで、ある受信PDUが真正のオリジナルなものであるか、再送コピーであるかがわかる。特に、シーケンス番号が、実際にはシーケンス番号の長さに関係なくやはり1ビットにすぎない場合、新しいリセット処理手順の開始時にシーケンス番号を1だけ増やすことは周期的動作として理解する必要があり、その場合、最大の生じ得るシーケンス番号値に1を加えることにより、結果として最小の生じ得るシーケンス番号値が与えられる。
【００３０】
このシーケンス番号は基本的にRフィールド304またはPADフィールド305内の任意の位置に入れることが可能である。特に、シーケンス番号として1ビットしか使用されていない場合、Rフィールド304の予約ビットの中の1つを指定することは合理的なことである。図3で、Rフィールド内のビットの中の1つがRSNすなわちリセット・シーケンス番号ビット306として示されていると仮定する。
【００３１】
図4aは通信装置の動作が従うことが可能なフローチャートの形で前述の方法を示す図である。ステップ401で、RLCレベルの通信接続の確立が開始され、次いで、開始処理手順の一部として、ステップ402でRSNの初期値が格納される。ステップ403は、この確立されたRLCレベルの通信接続を介する正常な通信に対応する。ステップ404と405は、この通信接続の状態をモニタするために装置が使用する制御ループを構成する。ステップ404で、プロトコル・エラーを検知した場合、当該装置は前記の例の表記法での送信側になる。ステップ406で、装置はRSN値を1だけ増やし、ステップ407で、Timer RSTをセットする。ステップ408で、装置は、増やされたRSN値を含むリセットPDUを今度は受信側の役割を果たす相手側装置へ送信する。
【００３２】
リセットPDUの送信後、送信側装置はステップ409と410とから成るループ内の循環を開始する。この循環時に送信側装置は、確認応答が受信されたかどうか、及び、タイマの時間切れが生じたかどうかを絶えずチェックする。確認応答の受信に起因してステップ409からステップ411への移行が生じる。ステップ411でRLCパラメータはリセットされる。その後、装置は現在のHFN番号をステップ412で1だけ増やし、ステップ403で正常な通信を再開する。確認応答の受信前にタイマにより上記装置の時間切れが生じた場合、ステップ410からステップ413への移行が続き、ステップ413で装置はリセットの最大許容試行回数に達したかどうかのチェックを行う。時間切れが生じなかった場合、装置はステップ407へ戻り、そこでタイマが再セットされる。この場合RSNの値が増やされない点に留意されたい。ステップ413で肯定が検知された場合、装置はそれ以上のリセットの試行を打ち切り、ステップ414でRLCの故障を宣言する。ステップ407、408、409、410、413から成るループの外側の別の場所に、RSN値の増加を行うステップ406を配置することも可能である。ステップ406は例えばステップ409と411との間、ステップ411と412との間、あるいは、ステップ412と403との間に存在してもよい。
【００３３】
ステップ405で肯定が検知されたこと、即ちリセットPDUの受信は上記装置が前記で用いた表記法での受信側装置になることを意味する。ステップ420で、装置は受信されたリセットPDUの中に含まれるRSN値をチェックし、RLC接続の設定段階で予め格納されているか、最新のリセット処理手順と関連して予め格納されているRSN値とこのRSN値との比較が行われる。通常の場合、2つのRSN値は同じではない。これは、受信されたリセットPDUが真正のオリジナルなものであり、再送コピーではないことを意味する。このような場合、装置は、ステップ421で新しく受信したRSNを格納し、ステップ422でRLCパラメータをリセットし、次いで、ステップ424でリセットACK PDUを送信する前にステップ423で現在のHFNの値を増やす。2つのRSN値が等しいことがステップ420で検知された場合、ステップ421、422、423は省かれる。ステップ424で確認応答を送信した後、装置はステップ403で正常な通信状態へ戻る。このことは、正常な通信が直ちに続くことを意味するものではないことに留意されたい。ステップ424で送信された確認応答の紛失または破損が生じる可能性もある。その場合、装置が前回のリセットPDUの再送コピーを受信するとすぐにステップ405からステップ420への新しい移行が生じる。
【００３４】
前述の本発明の実施例をわずかに修正したバージョンとして、RSNが全く規定されずに、現在のHFNまたは現在のHFNの派生値が、前述の実施例の中でRSNとして同じ目的に使用されるような場合がある。図4bはこの代替の実施例を示すものである。送信側がリセットPDUをステップ408’で送信するときはいつでも、そのリセットPDUが真正なオリジナルのリセットPDUであるか、再送コピーであるかに関りなく、送信側はリセットPDU中に現在のHFN値を含める。受信側は、このようなリセットPDUを受信すると、リセットPDUの中に含まれるHFN値が受信側の現在のHFN値と同じであるかどうかをステップ420’でチェックする。2つのHFN値が同じであれば、受信側はこれがこの特別のリセットPDUを受信する最初であることを認知する。その場合受信側は、パラメータ・リセット・ステップ422とHFN増加ステップ423とを実行する。受信されたリセットPDUの中に含まれるHFN値が受信側の現在のHFN値よりも小さい場合、最新の受信リセットPDUにより意図されたリセット処理手順と関連して、受信側がHFN増加ステップをすでに実行したこと、すなわち最新の受信リセットPDUが再送コピーであることが受信側により認知される。このような場合、受信側はその現在のHFN値をそれ以上増やさずに直ちに確認応答ステップ424の中へ入る。(潜在的に非常に短い)シーケンス番号の代わりにHFNを用いることは、HFNがリセットPDUから比較的大きなビット数を予約するという欠点を伴う。
【００３５】
前述の実施例をわずかに修正した別のバージョンでは、送信側により送信された第1のリセットPDU203にはRSNは全く含まれず、リセットPDU210のようなすべてのその後の再送コピーにRSN値が含まれる。受信装置は、受信したリセットPDUの中にRSN値を検知した場合、それが再送コピーであること、したがって現在のHFN値を変更しないことを認知する。本発明のこの実施例は、真正なオリジナルのリセットPDUが紛失したり破損したりした場合、受信側が受信したその再送コピーが、何らかの紛失したり破損したりしたリセットPDUであるのか、または何らかの別の比較的最近連続して受信した真正なオリジナルのリセットPDUであるかを受信側では知ることができないという欠点を持っている。
【００３６】
前述の記載では、特定の受信されたPDUが真正のオリジナルなものであるか、あるいは、再送コピーであるかをもう一方の端の装置が推論できるように、その伝送情報の中にシーケンス番号または別の情報を含むのは送信側の方であると仮定した。しかし、基本的には同期エラーを防止するためのシーケンス番号付けまたは対応する情報を利用する同じ原理を実現して、その確認応答の伝送情報の中へこのような情報の指示部分を含ませるように受信側へ義務づけることによりこの原理を実現することが可能である。以下、本発明のこのような代替の実施例について説明する。
【００３７】
図5は、通信用エンティティが、図1と図2の場合のようにリセット処理手順と関連する第1のPDUの進行方向に応じて送信側と受信側として指定されている状況を示す。接続設定処理の一部として、RSNとして知られているシーケンス番号に対して初期値kが格納されていると仮定する。ステップ501で、送信側はRLC層でのプロトコル・エラーを検知する。このことはリセット処理手順の開始が必要であることを意味する。プロトコル・エラーを検知した時点でのHFNをMと再び仮定する。送信側は、ステップ502で、あるリセットPDUを受信側へ送信することによりリセット処理手順を開始する。リセットPDUは503で示されている。同時に送信側はタイマTimer RSTをセットする。タイマの実行時間が図5に黒い点線として再び示されている。
【００３８】
本発明のこの代替の実施例によれば、リセットPDU503はシーケンス番号を含まず、従来技術により公知のリセットPDUである。ステップ504で、受信側はリセットPDU503を受信し、それによってRLCレベルの動作をリセットする必要性を認知する。受信側はいずれのシーケンス番号も受信しないが、RSNの初期値kは予め格納されている。ステップ505で、受信側はすべてのプロトコル・パラメータをリセットしHFNの現在値を1だけ増やしてM+1にする。本発明のこの代替の実施例によれば、受信側はその格納されたRSN値も1だけ増やしてk+1にする。
【００３９】
これらのタスクの完了後、受信側はステップ506でリセットACK PDU507を送信するが、このリセットACK PDU507は、ステップ505で受信側が取得したRSNの値k+1がリセットACK PDU507の中に含まれるという点で、以前使用した従来技術によるリセットACK PDUとは今回は異なっている。ステップ508で、通信エラーに起因して確認応答507が紛失あるいは破損したと仮定する。確認応答507は復号化可能な形で送信側へ着信することはないので、送信側は確認応答507が送信されたことを全く知らない。ステップ509でTimer RSTの時間切れが生じるため、送信側は新しいリセットPDU510の送信を行う。送信側の現在のHFN値はMのままであり、さらに、送信側の現在のRSN値もkのままである。
【００４０】
本発明のこの実施例によれば、新しいリセットPDU510が実際には前回のリセットPDU503の再送コピーであることに送信側はステップ509で検知することができる。なぜならば、Timer RSTが時間切れになる前に前回のリセットPDU503に関する確認応答が受信されなかったからである。しかし、新しいリセットPDU510がこの場合も、RSN値とは関連しない従来技術から得られるような公知のリセットPDUにすぎないので、上記のような検知はほとんど重要性を持たない。
【００４１】
ステップ511で受信側は後者のリセットPDU510を受信する。受信側は、後者のリセットPDUが以前受信したリセットPDU503の再送コピーであるかどうかを知る手段を持たない。そのため受信側は、HFNの現在値とkとを再度増やして、全く同じプロトコル・パラメータ・リセット・ステップ512を実行する。
【００４２】
ステップ512の後、受信側はステップ513で新しいリセットACK PDU514を送信側へ送信し、次いで、このPDUの中へ最新の格納されたRSN値、今回はk+2を再び含める。今度は、確認応答は送信側へ届き、送信側はこの確認応答をステップ515で受信する。送信側はその部分に対するすべてのプロトコル・パラメータをステップ516でリセットする。受信したRSN値をそれの格納値と比較することにより、送信側は2という差が生じていることを検知する。これに基づいて、送信側は、HFNの現在値と格納されたRSN値の双方を2だけ増やし、M+2と、k+2にする。1つのリセットACK PDU507が痕跡もなく再び紛失したが、成功したリセットACK PDU514が更新されたRSN値を含んでいたために、送信側と発信側のHFN値は結局同じ値になった。このことは送信側と受信側の間のHFN同期が維持されていることを意味する。もし第1のリセットACK PDU507が問題なく受信されたのであれば、第1のリセットACK PDU507内のRSN値k+1は、送信側に、HFNの現在値と格納されたRSN値の双方を1だけ増やしてM+1とk+1にさせたであろう。
【００４３】
図5の実施例でも、たとえ第2のリセットACK PDU514が紛失したり破損したりしたとしても、送信側及び受信側装置の動作は同じままである。このような場合、送信側は、第1及び第2のリセットPDUと同じ既知の無番号のフォーマットを持つ第3のリセットPDUを送信することも可能であり、その結果ステップ511、512、513が受信側で繰り返されることになる。第3のリセットACK PDUが最終的に着信した場合、このPDUはRSN値k+3を含むことになり、これに起因して送信側はその現在のHFNと格納されたRSN値を3だけ増やすことになる。
【００４４】
プロトコル・エラーの次の発生時に、双方の通信装置内でRSNの格納値は当初はまだ同じであるため、上述の処理手順を繰り返すことも可能である。
【００４５】
図6aは、通信装置の動作が従うフローチャートの形での上述の代替のアプローチに基づく方法を示す図である。ステップ601で、RLCレベルの通信接続の確立が開始され、処理手順の一部としてRSNの初期値がステップ602で格納される。ステップ603は上記確立されたRLCレベルの通信接続を介する通常の通信に対応する。ステップ604と605によって、通信接続の状態をモニタするために装置が用いる制御ループが構成される。ステップ604でプロトコル・エラーを検知した場合、当該装置は前述の例の表記法での送信側になる。ステップ606で装置はTimer RSTをセットする。ステップ607で装置は相手側装置へリセットPDUを送信するが、この相手側装置が今度は受信側の役割を果たす。
【００４６】
リセットPDUの送信後、送信側装置はステップ608と609とから成るループ内の循環を開始する。この循環時に送信側装置は、確認応答が受信されたかどうか、及び、タイマの時間切れが生じたかどうかを絶えずチェックする。確認応答の受信に起因してステップ608からステップ610への移行が生じ、ステップ610でRLCパラメータのリセットが行われる。その後装置は、リセットACK PDUで受信したRSN値と、装置が予め格納しているRSN値との間の差分をステップ611で算出する。ステップ612で、装置は現在のHFN番号を算出された差分の量だけ増やし、次いで、ステップ613でローカルなRSN値も算出された差分の量だけ増やして、このようにして更新されたRSN値の格納が行われる。その後装置はステップ603で正常な通信を再開する。確認応答の受信前にタイマにより上記装置の時間切れが生じた場合、ステップ609からステップ614への移行が続き、装置はリセットの最大許容試行回数に達したかどうかをステップ614でチェックする。この回数に達していない場合、装置はステップ606へ戻り、そこでタイマが再びセットされる。ステップ614で肯定が検知された場合、装置はそれ以上のリセットの試行を打ち切り、ステップ615でRLCの故障を宣言する。
【００４７】
ステップ605で肯定が検知されたこと、即ちリセットPDUの受信は、装置が前記で用いた表記法での受信側装置になることを意味する。ステップ620で装置は、RSN値を新しく格納する前に、ローカルに格納されたRSN値を1だけ増やす。その後装置はステップ621でRLCパラメータをリセットし、ステップ623でリセットACK PDUを送信する前にステップ622で現在のHFNの値を増やす。装置はステップ623で送信されたリセットACK PDUの中へ最近更新されたRSN値を含める。ステップ623で確認応答を送信した後、装置はステップ603で正常な通信状態へ戻る。これは、正常な通信が直ちに続くことを意味するものではないことに再度留意されたい。ステップ623で送信された確認応答の紛失または破損が生じる可能性もあるからである。その場合、装置が前回のリセットPDUの再送コピーを受信するとすぐにステップ605からステップ620への新しい移行が生じる。
【００４８】
RSNが再び完全に省かれて、リセット関連のPDUのシーケンシャルな管理が専らHFN値のみに基づいて行われるような、先程説明した方法の実施例を示すことが可能である。図6bはこのような修正された実施例を示す。図6aと6bの方法の違いとして、第1に、RSN初期化ステップ(図6aのステップ602)が図6bには存在しないという点が挙げられる。また受信側サイドの動作時に図6bにはRSN増加ステップ(図6aのステップ620)が存在しない。リセットACK PDUの中に含まれているのは、更新されたRSN値(この値は今回は存在さえしない)ではなくて、更新されたHFN値であるという点で、ステップ623’はステップ623とは異なるものである。送信側サイドの動作時に図6aのRSN関連ステップ611と613とが欠落している。さらに、図6aのステップ612の増加処理は図6bの612’の単純な置換動作へ単純化され、この場合送信側はそれ自身の現在のHFN値をリセットACK PDUで受信されたHFN値と置き換える。
【００４９】
特に、単一ビットがRSNとして用いられる場合、ビットで表わされるHFN値の方がRSN値よりもずっと長いということは前述した。しかし、いずれかの方向でのPDUの生じ得る紛失または破損が、推定されたHFN値と正しいHFN値との間で非常に小さな偏差しか生じない場合があることを考慮に入れる場合、リセットPDUまたはリセットACK PDUの中にHFN値全体を含むものとして示されている本発明の実施例の著しい単純化が可能となる。完全なHFN値の代わりに、リセットPDUまたはリセットACK PDUの中にその派生値、例えばHFN値の最下位ビットまたは2つの最下位ビットを含めることが可能である。4つまでのHFNの偏差を示すには2ビットあれば十分であり、このことは実際のほとんどのケースに対して十分以上である。HFNの最下位ビットだけの利用でさえ(すなわち上記RSNベースの実施例で説明したRSNビットが現在のHFN値の最下位ビットに常に等しいと述べることにより)図1で説明した問題の解決には充分である。
【００５０】
送信側義務及び受信側義務の実施例による組み合わせが可能であるように、RSNベース及びHFNベースの実施例は、いくつかの方法による組み合わせが当然可能である。ここで、送信側義務とは、送信側が、リセット関連PDUのシーケンシャルな管理に関連するある値をPDUの中へ挿入しなければならない実施例を指し、また、受信側義務とは、同様に受信側がこのような値を挿入しなければならない実施例を指すものである。これらの実施例の組み合わせは、例えば送信側がすべての送信されたリセットPDU内にRSN値を含むこと、及び、HFN同期が実際に維持されることを確認する目的で、すべての送信されたリセットACK PDUの中に受信側が現在のHFN値またはその派生値を含むことを意味する。
【００５１】
図7は、パケット交換通信接続で利用することが望ましいデータ・プロトコル・スタックの提案された構成を示す。この構成では、一方の端は移動局(MS)であり、無線アクセス・ネットワーク(RAN)と、在圏GPRSサポート・ノード(SGSN)と、ゲートウェイGPRSサポート・ノード(GGSN)とを通じてGPRSネットワーク(一般パケット無線サービス)を介する通信が行われる。ピア・エンティティがMSとRANとの中にあるプロトコル層として、例えば公知のUMTS物理層である物理層701と、媒体アクセス制御(MAC)層702と、MAC層702の一部にすぎないと見なされる場合もある(そのため702と703の間に破線が引かれている)無線リンク制御層703とが挙げられる。また、ピア・エンティティがRANとSGSNの中にあるプロトコル層として、MSとSGSN、SGSNとGGSN、あるいはMSとGGSNが示されている。しかし、データまたはユーザ・プレーン・プロトコルしか図7には示されていない。プロトコルの完全な実例の中には、サブネットワーク従属制御プロトコル(SNDCP)と並行して層3移動管理(L3MM)ブロックと、ショート・メッセージ・サービス(SMS)ブロックとが含まれる。さらに、図7には示されていないが、公知のセッション管理(SM)と無線資源管理(RR)エンティティが存在する。MS内のアプリケーション層は、例えば別のMSまたはある別の端末装置内に位置するピア・エンティティとの交信を行う。
【００５２】
図7のプロトコル層のうち、本発明はMSとRAN内のRLC層703に関するものである。通信装置におけるプロトコル層の諸機能の実現についてはそれ自体公知であり、プロトコル層の要求される動作をプログラムして、マイクロプロセッサが実行できる機械可読命令に変えるという形をとるのが典型的である。図2、4a、4b、5、6a及び6bと関連して前述の方法を実現するようなプログラミングを行うことは当業者の能力の範囲内の事柄である。
【００５３】
図8は本発明の実施例に基づくMSのある部分を概略的に示すものである。アンテナ801は双方向通信ブロック802を介して受信ブロック803及び送信ブロック804と結合されている。受信ブロック803からのペイロード・データのシンク(sink)と、送信ブロック804へのペイロード・データのソース(source)とはベースバンド・ブロック805であり、このベースバンド・ブロック805は、今度は、人間のユーザまたは電子的ユーザと交信するためにユーザ・インターフェースブロック806と結合されている。制御ブロック807は受信ブロック803から制御情報を受信し、送信ブロック804を介して制御情報の送信を行う。さらに、制御ブロック807はブロック803、804及び805の動作を制御する。
【００５４】
本発明によれば、制御ブロック807は比較ブロック810を具備し、HFN値とRSN値とを必要な場合に格納するためのパラメータ・メモリ811と結合され、また、受信されたRSN値および/またはHFN値、あるいは、受信されたPDUから得られる上記値の派生値を読み出す受信パラメータ抽出ブロック812と結合される。必要な場合にRLCの故障を示すためにRLC故障表示エンティティ813が設けられ、リセットPDUとリセットACK PDUとを必要に応じて構成するためにPDU構成ユニット814が設けられる。パラメータ管理ブロック815は、パラメータ格納装置811の中へそれらの値を戻して格納する前にパラメータ値の必要な計算と増加とを行う。
【００５５】
図9は、セルラ無線ネットワーク、さらに正確には、WCDMAを利用するUMTS無線ネットワークの典型的RNCの機能構成を規定するものである。本発明が上記機能構成に限定されると考えるべきではないことは当然のことである。本発明は別のタイプのセルラ無線ネットワークにおいても利用可能である。
【００５６】
図9のRNCはSFU(スイッチ回路網ユニット)901を具備し、いくつかの制御プロセッサ・ユニットをこのSFUに接続することが可能である。並列の冗長ユニットの形でハードウェア・レベルの冗長性を与えることにより典型的には信頼性が向上する。複数のプロセッサ・ユニットとSFU901との間でMXU(多重化用ユニット)902を用いて、プロセッサ・ユニットからの低いビットレートをSFU入力ポートの高いビットレートに対応づけることが可能となる。NIU(ネットワーク・インターフェース・ユニット)903は異なるインターフェース(ノードBへ向うIubインターフェース、他のRNCへ向うIurインターフェース、コア・ネットワーク・ノードへ向うIuインターフェースなど)との物理層接続の処理を行う。OMU(運用保守ユニット)904にはRNC構成と障害情報とが含まれ、運用保守センターからのアクセスが可能である。SU(シグナリング・ユニット)905はRNCで要求されるすべての制御プレーン及びユーザ・プレーンのプロトコルを実行する。したがって、図8と関連して前述した方法と類似の方法で、PDU及びパラメータ管理エンティティ810〜815をシグナリング・ユニットに設けることにより、シグナリング・ユニットのRNCで本発明の実現が可能となる。
【００５７】
本願のあるセルラ無線システムに固有の用語の使用によって、他のセルラ無線システムにおける本発明の適用性が限定されると解釈すべきではない。従属請求項に記載の特徴は別様に明白に記載されていない限り自由に組み合わせることが可能である。
【図面の簡単な説明】
【図１】  公知のリセット処理手順を示す図である。
【図２】  本発明の実施例によるリセット処理手順を示す図である。
【図３】  本発明の一部として用いられるプロトコル・データ・ユニットの好適な構成を示す図である。
【図４ａ】  本発明の実施例による通信装置の動作を示す図である。
【図４ｂ】  図4aの実施例から変更された本発明の実施例による通信装置の動作を示す図である。
【図５】  本発明の別の実施例によるリセット処理手順を示す図である。
【図６ａ】  本発明の前記別の実施例による通信装置の動作を示す図である。
【図６ｂ】  図6aの動作から変更された本発明の実施例による通信装置の動作を示す図である。
【図７】  プロトコル層の構成内での本発明の適用を示す図である。
【図８】  本発明の実施例による移動局を示す図である。
【図９】  本発明の実施例による無線ネットワーク制御装置を示す図である。
【図１】
0003905385.tif 000002
【図２】
0003905385.tif 000003
【図３】
0003905385.tif 000004
【図４ａ】
0003905385.tif 000005
【図４ｂ】
0003905385.tif 000006
【図５】
0003905385.tif 000007
【図６ａ】
0003905385.tif 000008
【図６ｂ】
0003905385.tif 000009
【図７】
0003905385.tif 000010
【図８】
0003905385.tif 000011
【図９】
0003905385.tif 000012