(57)【要約】      （修正有）【課題】専用のチャネル上で修復不能エラーを処理する方法及び相関するワイヤレス装置を提供する。【解決手段】UEはRLC修復不能エラーとRL失敗を検出する。UEが専用のチャネル（DCH）状態である間、二つのエラーは、異なる方法で処理される。RL失敗は、RAB解放工程の実行を導き、その特徴は、各タイマーの値により、相関するRABを解放すべきかどうかを決定する。RLC修復不能エラーは、RAB解放工程の実行を許可しない。よって、サービスの不要な中断が生じない。UTRANは、選択的にインジケーターを含み、これらのインジケーターにより、UEに指示されたRLC再構築手続きの実行を命令する。【選択図】図４
2004166233.tif 000002
【特許請求の範囲】
【請求項１】
ワイヤレス装置の専用のチャネル上での修復不能エラーを処理する方法であって、本方法は、
前記ワイヤレス装置がCELL＿DCH状態かを検出する工程と、
第一層無線リンク失敗が生じたかを検出する工程と、
前記ワイヤレス装置がCELL＿DCH状態にあり、且つ無線リンク失敗を生じているのを検出するのに対応して、RAB解放工程を実行して、無線ベアラーを解放する工程と、
前記ワイヤレス装置がCELL＿DCH状態にあり、且つ無線リンク失敗を生じていないのを検出するのに対応して、RAB解放工程を実行しない工程と、
を備えることを特徴とする方法。
【請求項２】
前記ワイヤレス装置は、セルアップデート手続きを開始することを特徴とする請求項１に記載の方法。
【請求項３】
更に、
前記ワイヤレス装置が前記セルアップデート工程を開始するのに対応し、UTRANが前記ワイヤレス装置からセルアップデートメッセージを受信する工程と、
前記セルアップデートメッセージを受信するのに対応して、前記UTRANは、“RLC再構築インジケーター（RB２、RB３、RB４）”IEを含むセルアップデート確認メッセージを構成する工程と、
前記UTRANが、前記セルアップデート確認メッセージを前記ワイヤレス装置の伝送する工程と、を備えることを特徴とする請求項２に記載の方法。
【請求項４】
第１ワイヤレス装置を備えたワイヤレスシステムであって、前記第１ワイヤレス装置は、第１メモリと電気的に接続される第１CPUを備え、前記第１メモリは、前記第１CPUにより実行される第１プログラムコードを含み、前記第１プログラムコードは、前記第１CPUに以下の工程、
前記第１ワイヤレス装置がCELL＿DCH状態かを検出する工程と、
第１層無線リンク失敗が生じたかを検出する工程と、
前記第１ワイヤレス装置がCELL＿DCH状態にあり、且つ無線リンク失敗を生じているのを検出するのに対応して、RAB解放工程を実行して、無線ベアラーを解放する工程と、
前記第１ワイヤレス装置がCELL＿DCH状態にあり、且つ無線リンク失敗を生じていないのを検出するのに対応して、RAB解放工程を実行しない工程と、
を実行させることを特徴とするワイヤレスシステム。
【請求項５】
前記第１プログラムコードは、更に、前記第１ワイヤレス装置に、セルアップデート工程を開始させることを特徴とする請求項４に記載のワイヤレスシステム。
【請求項６】
前記ワイヤレスシステムは、更に、第２ワイヤレス装置を備え、前記第２ワイヤレス装置は、第２メモリと電気的に接続される第２CPUを備え、前記第２メモリは、前記第２CPUにより実行される第２プログラムコードを含み、前記第２プログラムコードは、前記第２CPUに以下の工程、
前記第１ワイヤレス装置から、セルアップデートメッセージを受信する工程と、
前記セルアップデートメッセージを受信するのに対応して、 “RLC再構築インジケーター（RB２、RB３、RB４）”IEを含むセルアップデート確認メッセージを構成する工程と、
前記セルアップデート確認メッセージを前記第１ワイヤレス装置に伝送する工程と、
を実行させることを特徴とする請求項５に記載のワイヤレスシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレスコミュニケーション装置に関するものであって、特に、第二層中の回復不能エラーと第一層中の無線リンク失効の処理間を判別するものである。
【背景技術】
【０００２】
第三世代パートナーシップ、プロジェクト（３rd Generation Partnership Project、３GPP）規格の３GPP TS ２５．３３１ V３．１１．０（２００２−０６）の“RRC（Radio Resource Control）規格”と３GPP TS ２５．３２２ V３．１１．０（２００２−０６）の“RLC(Radio Link Control)プロトコル規格（RLC Protocol Specification）”は、第三世代携帯電話規格（Universal Mobile Telecommunications System、UMTS）の技術性参考文献とされる。UMTSは、UEと称される装置（通常はモバイル装置）を描写し、ワイヤレスコミュニケーションにおいて、一つ、或いは複数のベースと疎通している。これらのベースステーション（即ち、いわゆるノードB）と無線ネットワークコントローラー（Radio Network Controller、RNCs）は、UMTS地上無線接続網（UMTS Terrestrial Radio Access Network、UTRAN）と称される。
【０００３】
図１を参照する。図１は３GPPワイヤレスコミュニケーションネットワーク１０の簡易図であり、ワイヤレスコミュニケーションネットワーク１０は、コアネットワーク（core network、CN）３０と通信する複数の無線ネットワークサブシステム（Radio Network System、RNSs）２０を含む。CN３０中に、パケット交換（packet switch、PS）ドメイン３０ｐ、及び回線交換（circuit switch、CS）ドメイン３０cを含む。複数のRNS２０は、UTRAN２０uを形成する。各RNS２０は、複数のノードB（Node B）２４と通信するRNC２２を含む。ノードB２４はトランシーバ（transceiver）で、調整後、無線信号を送受信し、セル領域を定義する。複数のノードB２４は、UTRAN位置登録領域（UTRAN Registration Area、URA）を定義する。特に、ワイヤレスコミュニケーションネットワーク１０は、UE４０を特定のRNS２０に割り当て、RNS２０は、UE４０のサービングRNS（Serving RNS、SRNS）２０sと称される。UE４０に送るデータは、CN３０（或いは、UTRAN２０u）からSRNS２０sに伝送される。このデータは、一つ、或いは多くの、特定のデータ構造を有するパッケージの形式で送り出され、その後、複数の無線ベアラー（Radio Bearers、RBs）２８、４８の一つのRBにより伝送、受信する。UE40に構築されたRB４８は、UE SRNS２０ｓ上に構築された対応するRB２８を有する。RBsは、順に、RB０〜RBnの番号がつけられる。一般に、RB０〜RB４は、専用の信号伝達SRBs（Signaling RBs、SRBs）で、これらのRBsは主に、UTRAN２０uとUE４０間のプロトコル信号を送るのに用いられ、以下で詳述する。
【０００４】
４以上であるRBs２８、４８（即ち、RB５、RB６等）は、通常、ユーザーデータを運ぶのに用いられる。RNC２２は、セルアップデート手続き（procedure）により、UE４０が割り当てられるノードB２４を用いて、UE４０にデータを伝送したり、UE４０からデータを受信したりする。セルアップデート手続きは、UE４０により開始されて、ノードB２４により定義されるセルを交換する。新しいセル領域の選定は、例えば、SRNS２０sのドメイン内のUE４０の位置に基づく。UE４０は、データをワイヤレスコミュニケーションネットワーク１０に伝送し、これらの信号がSRNS２０sにより収集された後、CN３０に送られる。UE４０はもう一つのRNS２０のドメインに移動することもあり、ドリフトRNS（drift RNS、DRNS）２０dと称される。DRNS２０dのノードB２４は、UE４０により伝送される信号を収集する。DRNS２０dのRNC２２は、受信した信号をSRNS２０sに伝送する。SRNS２０sは、DRNS２０dからの信号を、ノードB２４からの対応信号と合わせて、合成信号を生成し、デコードした後、パケットデータに処理する。その後、SRNS２０sは、受信したデータをCN３０に伝送する。よって、UE４０とCN３０間の全ての通信は、SRNS２０sを通過しなければならない。
【０００５】
図２と、図１を合わせて参照する。図２は、コミュニケーションネットワーク１０中に用いられるUMTS無線インターフェースプロトコルの機構を示す図である。UE４０とUTRAN２０u間の通信は、第一層、第二層、第三層を含むマルチ層コミュニケーションプロトコルによりもたらされ、伝達信号平面（Signaling Plane、C−plane）９２とユーザー平面（user plane、U−plane）９４の伝達を提供する。第一層は実体層６０で、UTRAN２０u中、DRNS２０dとSRNS２０sから受信した信号の合成を担う。第二層はPDCP層７０、RLC層７２、及び媒体アクセス制御（Media Access Control、MAC）７４を含む。第三層は、RRC（Radio Resource Control）層８０を含む。U平面９４は、UE４０とUTRAN２０u間のユーザーデータ伝送を処理し、C平面９２は、UE４０とUTRAN２０u間の信号伝達データの伝送を処理する。RRC８０は、UE４０とUTRAN２０u 間の全RBs２８、４８を構築、設定する。PDCP層７０は、U平面９４から受信されたサービスデータユニット（SDU）のヘッダー圧縮を提供する。RLC層７２は、PDCP層７０ SDUとRRC８０ SDUの細分化（segmentation）を提供し、細分化後、RLCプロトコルデータユニット（PDU）になる。RLC層７２は、一つ或いはそれ以上のRLCエンティティ７６から構成される。各RLCエンティティ７６は、RB２８、４８と関連する。UTRAN２０u中の各RB２８は、このRB２８専属のRLCエンティティ７６を有する。同様に、UE４０中の同一のRB４８も、対応するRLCエンティティ７６を有する。
【０００６】
同一のRB２８、４８の二つの対応するRLCエンティティ７６は、“RLC対等エンティティ”と称される。確認応答ACK伝送下で、RLC層７２は、上層（PDCP７０、或いは、RRC層８０）に、UE４０とUTRAN２０u間のRLC PDUが正確に送受信されたことに関する情報を提供する。MAC層７４は伝送チャネル上にRLC PDUのスケジューリングと多重化（Multiplexing）を提供して、実体層６０間のインターフェースを提供する。
【０００７】
図３と、図１及び図２を合わせて参照する。図３は、RRC層８０の状態を示す図である。RRC層８０は、二つの主要な状態、すなわち、アイドルモード８１とUTRA RRC接続モード８６を有する。アイドルモード８１の時、RRC層８０間には、いかなる通信も存在しない。つまり、RB０以外には、RRC層８０を通信させることが出来るSRBs２８、４８がない。UTRAN２０u中、RB０は全UE４０が使用できるコモンチャネル（common channel）である。UE４０を範例の基盤（プラットホーム）とすると、UE４０のRRC層８０が、一旦、UTRAN２０u中の同等RRC層８０接続を構築すると、UE４０のRRC層８０は、UTRA RRC接続モード８６に切り替わる。この接続は、一般に、シェアチャネル（shared channel）であるRB0に沿って初期化される。UTRA RRC接続モード８６は、四つの固有の状態、すなわち、CELL＿DCH状態８２、CELL＿FACH状態８３、CELL＿PCH状態８４、URA＿PCH状態８５を有する。CELL＿DCH状態８２の特徴は、専用のチャネルがUE４０に割り当てられて、アップリンク（uplink）（UE４０からUTRAN２０u）とダウンリンク（downlink）（UTRAN２０uからUE４０）の通信に用いられることである。CELL＿FACH状態８３の特徴は、割り当てられる専用のチャネルがないが、UE４０はデフォルトコモン（default common）、或いは、シェア伝送チャネルが与えられて、アップリンクに用いられる。CELL＿PCH状態８４の特徴は、割り当てられる専用のチャネルがなく、UE４０にとって、可能なアップリンクがなく、UE４０の位置は、UTRAN２０uによりセルレベルで認知される（つまり、一つのノードB２４を基本とする）ことである。URA＿PCH状態８５の特徴は、割り当てられる専用のチャネルがなく、UE４０にとって、可能なアップリンクがなく、UE４０の位置は、UTRAN２０uによりURA基準で認知されることである。
【０００８】
多数の再設定手続き（procedure）は、RRC層８０がRBs２８及び４８をセットアップ及び設定するのに有効である。これらの手続きは、UTRAN２０uが特定の情報を、RBs２８及び４８に沿ってUE４０に送り、UE４０により、対応する情報に応答する手続きを含む。一般には、情報はRB２に沿って送られ、すなわちSRBである。この情報は、無線ベアラーセットアップ（Radio Bearer Setup）、無線ベアラー再設定（Radio Bearer Reconfiguration）、無線ベアラー解除（Radio Bearer Release）、伝送チャネル再設定（Transport Channel Reconfiguration）、実体チャネル再設定（Physical Channel Reconfiguration）を含む。これらの再設定情報に対し、UE４０は、対応する“完成”或いは、“失敗”応答情報を備え、UE４０端でその手続きが成功したかどうかを示し、UTRAN２０uに必要な情報を与えて、UTRAN２０uに手続きを終了させる。再設定情報と応答情報は全て、任意の情報素子（information element、IE）、すなわち、補助情報を保持するデータ領域を運ぶ。この他、セルアップデート手続きもあり、この手続きは、UE４０からのセルアップデートメッセージに起因し、UTRAN２０uにより応答する。セルアップデート手続きは、UE４０により、セル位置（即ち、ノードB２４）の変化、URAの変化、或いは接続状態８２、８３、８４、８５の変化を示すのに用いられ、無線リンク（radio link、RL）失敗とRLC修復不能エラーを示すのに用いられる。RL失敗とは、実体層、即ち第一層６０で生じる接続失敗のことである。RLC修復不能エラーはRLC層７２で生じ、原因は多種である。
【０００９】
AM接続にとって、送信端RLCエンティティ７６が以下の状況の一つを検出した場合、RESET PDUを対等なRLCエンティティ７６に伝送して、この二つのRLC対等エンティティ７６をリセットする：
１）“MaxDAT回の再伝送後のNo＿Discard”（No＿Discard after MaxDAT number of retransmission）が設定され、VT（DAT）がMaxDATの値と等しい時（TS ２５．３２２の第９．７．３．４節を参照する）；
２）VT（MRW）がMaxMRW値と等しい時；
３）“不正確なシーケンス番号（erroneous sequence number）”を有するSTATUS PDUが受信される時（TS ２５．３２２の第１０節を参照する）；
‐AMD PDU、或いはSTATUS PDUの伝送を停止する；
‐VT（RST）の値を一つ増加する；
‐VT（RST）＝MaxRSTである場合：
‐送信端はRESET PDUを下層に送ることが出来る。
【００１０】
‐TS ２５．３２２の第１１．４．４ａ節で指定される動作を実行する；
‐そうでない（VT（RST）<MaxRST）場合：
‐RESET PDUを下層に送る；
‐Timer＿RSTを開始する。
詳細は、３GPP規範TS ２５．３２２の第１１．４節を参照する。RESET PDUを伝送するのを試みる回数が最高値に達する時、送信端RLCエンティティ７６実行中のRLC RESET手続きを終了すると共に、上層（即ちRRC層８０）に、修復不能エラーが生じたことを示す。RRC層８０が、AM RLCエンティティ７６から修復不能エラーが生じたことを受信した後、UE４０は、“RLC修復不能エラー”を発生原因として、CELL UPDATE手続きを実行し、つまり、UE４０は、セルアップデート（Cell Update）メッセージを伝送するとともに、“AM＿RLCエラーインジケーター（RB２、RB３、RB４）”IE、或いは、“AM＿RLCエラーインジケーター（RB>４）”IEを、“TRUE”に設定し、RLC修復不能エラーが、制御平面９２、或いはユーザー平面９４で生じたことを示す。TS ２５．３３１の第８．３．１を参照すると、後方にもセルアップデート手続きの詳細が記されている。
【００１１】
ユーザー平面９４でRLC修復不能エラーが生じた時、UE４０からのCELL UPDATE／URA UPDATE情報を受信した後、UTRAN２０ｕは、選択的に、“RLC再構築（re-establish）インジケーター（indicator）（RB５及び５より大きいRB）”IEを、セルアップデート確認（CELL UPDATE CONFIRM）メッセージに入れて、UE４０でRLC再構築手続きを実施するように要求し、この状況下で、対応するRLCエンティティ７６も、UTRAN２０ｕで再構築されなければならない。
【００１２】
制御平面９２でRLC修復不能エラーが生じた時、UE４０からのCELL UPDATE／URA UPDATE情報を受信した後、UTRAN２０ｕは、選択的に、“RLC再構築インジケーター（RB２、RB３及びRB４）”IEを、CELL UPDATE CONFIRM情報に入れて、UE４０でRLC再構築手続きを実施するように要求し、この状況下で、対応するRLCエンティティ７６も、UTRAN２０ｕで再構築されるか、或いは、ダウンリンクCCCH上でRRC接続解除手続き（RRC CONNECTION RELEASE）情報を伝送することにより、RRC接続解除手続きを開始しなければならない。RL失敗、或いはRLC修復不能エラーが専用のチャネル上に生じる（RRC層８０は、CELL＿DCH状態８２）場合、CELL UPDATE情報を伝送する前に、UE４０は無線アクセスベアラー（radio access bearer、RAB）解放工程を実施し、好ましいセル２４を選択しなければならない。RAB解放手続きは、相関するタイマーT３１４とT３１５がゼロであるRABを解放する。RABは、一つ、或いはそれ以上のRBを備えることが出来るが、通常、RABとRBは一対一の関係である。RLC再構築手続きが実行されている間、タイマーT３１４、或いはタイマーT３１５が期限切れの場合、UE４０は、期限切れタイマーと相関するRABを解放しなければならない。TS ２５．３２２の第８．３．１．２節において、上述と関連する以下のような記述がある。
URAアップデート、或いはセルアップデート手続きが開始される時、UEは：
１>タイマーT３０５を停止する；
１>UEがCELL＿DCH状態の場合：
２>RAB解放工程を実行する；
１>変数PROTOCOL＿ERROR＿INDICATOR、FAILURE＿INDICATOR、UNSUPPORTED＿CONFIGURATIO、INVALID＿CONFIGURATIONをFALSEに設定する；
１>変数CELL＿UPDATE＿STARTEDをTRUEに設定する；
１>UEがまだCELL＿FACH状態でない場合：
２>CELL＿FACH状態に移動する；
２>第８．５．１７節に従って、PRACHを選択する；
２>第８．５．１９節に従って、次のCCPCHを選択する；
２>第８．６．５．１節で示されるように、システム情報に与えられる伝送フォーマット組（transport format set）を使用する。
１>UEがセル再選択を実行する場合：
２>変数C＿RNTIを消去する；
２>MAC層中で消去されたばかりのC＿RNTIの使用を停止する。
１>第８．５．１５節に従って、現在のセルのSFNによりCFNを設定する；
１>セルアップデート手続きの場合：
２>第８．３．１．３節に従って、CELL UPDATE情報の内容を設定する；
２>アップリンクCCCH上で、CELL UPDATE情報を伝送する。
１>URAアップデート手続きの場合：
２>第８．３．１．３節に従って、URA UPDATE情報の内容を設定する；
２>アップリンクCCCH上で、URA UPDATE情報を伝送する。
１>計数器V３０２を１に設定する；
１>MAC層が、情報伝送の結果が成功か失敗かを示す時、タイマーT３０２を開始する。
公知のRAB解放工程が以下で記述される。更に、以下の工程も、TS２５．３３１によるものである。
RAB解放工程において、UEは：
２>変数RB＿TIMER＿INDICATORにおいて、“T３１４が期限切れ”IE及び“T３１５が期限切れ”IEを、FALSEに設定する；
２>タイマーT３１４及びT３１５の保存値が共にゼロの場合；或いは、
２>タイマーT３１４の保存値がゼロで、且つ、変数ESTABLISHED＿RABSの“再構築タイマー”IEの値が“T３１５を使用”に設定された無線アクセスベアラーに相関する無線ベアラーがない場合：
３>その無線リソースを全て解放する；
３>構築された信号接続（変数ESTABLISHED＿SIGNLING＿
CONNECTIONS中に保存される）と構築された無線アクセスベアラー（変数ESTABLISHED＿RABS中に保存される）の解放を、上層に示す；
３>変数ESTABLISHED＿SIGNLING＿CONNECTIONSを除去する；
３>変数ESTABLISHED＿RABSを除去する；
３>アイドルモードに進入する；
３>第８．３．２節に従って、接続モードからアイドルモードに進入する時、その他の動作を実行する；
３>手続きを終了する。
【００１３】
２>タイマーT３１４の保存値がゼロの場合：
３>無線アクセスベアラーが変数ESTABLISHED＿RABSの“再構築タイマー”IEの値が“T３１４を使用”に設定された無線アクセスベアラーに相関する無線ベアラーを全て解放する；
３>変数RB＿TIMER＿INDICATORにおいて、“T３１４期限切れ”IEをTRUEに設定する。
【００１４】
２>タイマーT３１５の保存値がゼロの場合：
３>変数ESTABLISHED＿RABSの“再構築タイマー”IEの値が“T３１５を使用”に設定された無線アクセスベアラーに相関する無線ベアラーを全て解放する；
３>RB＿TIMER＿INDICATORにおいて、“T３１５期限切れ”IEをTRUEに設定する。
【００１５】
２>タイマーT３１４の保存値がゼロより大きい場合：
３>変数ESTABLISHED＿RABSの“再構築タイマー”IEの値が“T３１４を使用”に設定される無線アクセスベアラーに相関する無線ベアラーがある場合；
４>タイマーT３１４を開始する。
【００１６】
３>変数ESTABLISHED＿RABSの“再構築タイマー”IEの値が“T３１４を使用”、或いは“T３１５を使用”に設定される無線アクセスベアラーに相関する無線ベアラーがない場合
４>タイマーT３１４を開始する。
【００１７】
２>タイマーT３１５の保存値がゼロより大きい場合：
３>変数ESTABLISHED＿RABSの“再構築タイマー”IEの値が“T３１５を使用”に設定される無線アクセスベアラーに相関する無線ベアラーがある場合；
４>タイマーT３１５を開始する。
【００１８】
２>解放された無線ベアラーにとって：
３>変数ESTABLISHED＿RABS中から、該無線アクセスベアラーに関する全情報を削除する；
３>同一の無線アクセスベアラーに属する全無線ベアラーが解放される時：
４>CNドメイン識別（CN  domain  identity）と変数ESTABLISHED＿  RABSに保存されたRAB識別により、上層に、無線アクセスベアラーがローカル端で開放されたことを示す；
４>変数ESTABLISHED＿RABS中から、該無線アクセスベアラーに関する全情報を削除する。
【００１９】
２>[４]に従って、適切なUTRAセルを選択する；
２>変数ORDERED＿RECONFIGURATIONをFALSEに設定する。
例えば、タイマーT３１４の保存値がゼロで、且つ、タイマーT３１５の保存値がゼロより大きい時、UE４０は、変数ESTABLISHED＿RABS中の“再構築タイマー”のIEの値が、“タイマーT３１４を使用”の無線アクセスベアラーに相関する全無線ベアラー４８を解放し、タイマーT３１５を起動する。タイマーT３１５が期限切れの場合、UE４０は、変数ESTABLISHED＿RABS中の“再構築タイマー”のIEの値が、“タイマーT３１５を使用”の無線アクセスベアラーに相関する全無線ベアラー４８を解放し、アイドルモード８１に進入する。
【００２０】
TS ２５．３３１の第８．３．１．２節で記述されるように、RRC８０がCELL＿DCH状態８２である間、UE４０は同じ方式で、RL失敗及びRLC修復不能エラーを処理する。つまり、CELL＿DCH状態８２の時、二つのエラー状態のどちらが生じるかにかかわらず、RAB解放工程を実行する。しかし、RL失敗及びRLC修復不能エラーは、多くの差異がある。例えば、RLC修復不能エラーは、RLC再構築手続きにより、初期状態に戻って修復される。RL失敗は無線接続の時の実体層で問題が生じ、再構築手続きにより修復されることは無い。よって、RAB解放を実行する時、タイマーT３１４及びT３１５がRLC修復不能エラー上で使用される保証はない。且つ、タイマーT３１４及びT３１５の時間は、RLC再構築手続きが必要とする時間よりも短いために、RLC再構築手続きが完成する前に、正常に機能しているRAB（即ち、サービス、或いはアプリケーションのRAB）が解放されてしまう。
【００２１】
例を挙げると、例えばUE４０がCELL＿DCH状態８２に属すると共に、ユーザー平面９４のRAB６〜１０を備える場合、RAB６〜１０は、一対一の写像関係であるRB４８ ６〜１０を備える。更に、タイマーT３１４がゼロ秒に設定され、タイマーT３１５が１０秒に設定される場合、RAB６とRAB７以外のRABは全て、タイマーT３１４と相関する。RLC修復不能エラーがRB６上だけで生じる場合、UE４０は、“AM＿RLCエラーインジケーター（RB>４）”IEを“TRUE”に設定したCELL UPDATE情報を、UTRAN２０uに伝送する。UTRAN２０uは、“RLC再構築インジケーター（RB５及び更に大きいRB）”IEを含むCELL＿UPDATE CONFIRM情報に応答して、UE４０中のRAB６〜１０の全RLC再構築を要求する。よって、正常に作動中のRAB８、９及び１０（即ちRB８、９及び１０）は、再構築が完了する前に、解放される。タイマーT３１４（ゼロ秒）は、RLC再構築手続きを実行するのに必要な時間よりも短いからである。正常でないRB６（即ちRAB６）は、RLC再構築手続きが実行された後、RB６は良好な状況に回復するが、正常に作動中のRAB８、９及び１０（即ちRB８、９及び１０）は、再構築が完了する前に、解放される。正常に作動中のRAB（即ち、サービス、或いはアプリケーションのRAB）は、不要な解放がなされて、無線利用率の減少を招き、サービス中断率を増加させ、UE４０のユーザーに不便を感じさせる。
【００２２】
最後に、TS ２５．３３１の第８．３．１．６節によると、CELL UPDATE CONFIRM情報を受信した場合、UE４０は、“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEと、“RLC再構築インジケーター（RB５、及び５より大きいRB）”IE両方を処理しなければならない。しかし、TS ２５．３３１の第８．３．１．５節によると、UTRAN２０uは、CELL UPDATE CONFIRM情報中に、“RLC再構築インジケーター（RB５、及び５より大きいRB）”IEしか含まず、“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEは、UTRAN２０uにより、CELL UPDATE CONFIRM情報中に含まれないため、この“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEは、実質上、作用することはない。
【非特許文献１】“無線リソース・コントロールプロトコル仕様(RRC：Radio Resource Control protocol specification）”、３ＧＰＰ ＴＳ ２５．３３１ Ｖ３．１１．０、サード・ジェネレーション・パートナーシップ・プロジェクト・オーガニゼイショナル・パートナーズ(3rd Generation Partnership Project Organizational partners）、２００２年６月、［平成１５年１０月６日検索］、インターネット＜ＵＲＬ：http://www.quintillion.co.jp/3GPP/Specs/25331-3b0.pdf＞
【非特許文献２】“無線・リンク・コントロール・プロトコル仕様(RLC protocol specification)”、３ＧＰＰ ＴＳ ２５．３２２ Ｖ３．１１．０、２００２年６月、［平成１５年１０月６日検索］、インターネット＜ＵＲＬ：http://www.quintillion.co.jp/3GPP/Specs/25322-3b0.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【００２３】
よって、本発明は、専用のチャネル上で、修復不能エラーを処理し、上述のような問題を解決する改良された方法を提供することを目的とする。
【課題を解決するための手段】
【００２４】
好ましい実施形態において、本発明は、専用のチャネル上で修復不能エラーを処理する方法及び相関するワイヤレス装置を開示する。簡単に言えば、ワイヤレス装置がCELL＿DCH状態で、第一層の無線リンク失敗が生じたことを検出した場合、改善された無線アクセスベアラー（RAB）解放工程が実行されて、無線ベアラーを解放する。しかし、ワイヤレス装置がCELL＿DCH状態で、第一層の無線リンク失敗が生じないことを検出した場合、RAB解放工程は実行されない。
【００２５】
最後に、本発明は、UTRANが“RLC再構築インジケーター（RB２、RB３、及びRB４）”情報素子IEを含むCELL UPDATE CONFIRM情報をUEに、伝送するのを許可する。
【発明の効果】
【００２６】
本発明の長所は、第一層の無線リンク失敗が専用のチャネル上で検出された時だけ、RAB解放工程を実行することで、不要なRAB解放を回避し、よって、不要なサービス中断を回避することができる。また、タイマーT３１４及びT３１５を、RLC修復不能上で使用するのを回避し、UE４０が充分な時間でRLC接続を再構築できるようにする。よって、中断しそうなRAB及びサービスを救うことができる。
【００２７】
本発明の長所は更に、UTRANが、CELL UPDATE CONFIRM情報中に、“RLC再構築インジケーター（RB２、RB３、及びRB４）”情報素子IEを含み、UEに伝送され、よって、UEからUTRANに伝送が開始される“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEと対応関係を有することである。
【発明を実施するための最良の形態】
【００２８】
以下の記述中、UEは、ワイヤレスコミュニケーション装置で、携帯電話、トランシーバ、PDA、コンピュータ、或いは、データの無線交換が要求されるその他の装置である。このデータの無線交換は、３GPPが規定するプロトコルに完全に符合する。
【００２９】
図４は、本発明によるUE（User Equipment）１００を示す図である。本発明のUE１００は、公知のUEと大部分が相同している。UE１００は、例えば、キーボード１０２と液晶ディスプレイ１０４等の入力出力の装置を備える。トランシーバ１０８は、無線信号を受信し、対応するデータを制御回路１０６に提供することができ、また、制御回路１０６からのデータを無線方式で伝送することができる。トランシーバ１０８は、３GPP第一層６０の一部分である。制御回路１０６は、UE１００操作の制御を担い、３GPPの第二層及び第三層を実行するのに用いられる。特に、RRC層８０の実施上、適当な修正により、本発明の改良に符合させる。制御回路１０６は、電子コミュニケーションシステム中、CPU１０６cとメモリ１０６mを含み、このような手配と公知の無線コミュニケーションシステムとは相同している。メモリ１０６mは、本発明のコミュニケーションプロトコルの第二層及び第三層を実行するのに用いられるプログラムコード１０７を保持している。公知のUEと比較して、本発明のUE１００は、プログラムコード１０７に修正を加えて本発明の方法を実施し、RRC層８０に関連するプログラムコード１０７に修正を加えて、本発明の改善を実行する。当該技術を熟知する者なら、好ましい実施形態の詳細を参照した後、本発明が開示する修正方法が理解できるであろう。
【００３０】
RLC修復不能エラー（RLC層７２により検出される）が専用のチャネルで生じる（RRC層８０がCELL＿DCH状態８２である）時、UE１００は、タイマーT３１４  １０９a或いはタイマーT３１５  １０９bがゼロあるかにより相関するRABの解放を決定しない。つまり、UE１００がCELL＿DCH状態８２である時、RAB解放工程は、RLC修復不能エラーに呼び出されない。タイマーT３１４  １０９a或いはタイマーT３１５  １０９bは、RL失敗の時（トランシーバ１０８の第一層６０により検出される）のみ用いられ、専用のチャネル上で、RLC修復不能エラーが発生する時に用いられない。
【００３１】
セルアップデート手続きが実行される時、本発明は更に、RAB解放工程が実行される時の条件を変更する。以下で詳述される本発明の改善工程（プログラムコード１０７により実行される）は、UE１００がセルアップデート手続き、或いはURAアップデート手続きを実行するのを制御する。
URAアップデート手続き、或いは、セルアップデート手続きを開始する時、UEは：
１>タイマーT３０５を停止する；
１>UEがCELL＿DCH状態である場合；
１>この手続きがトリガーされるのが、“無線リンク失敗”によるものである場合：
２>改良されたRAB解放工程を実行する；
１>変数PROTOCOL＿ERROR＿INDICATOR、FAILURE＿INDICATOR、UNSUPPORTED＿CONFIGURATION、INVALID＿CONFIGURATIONをFALSEに設定する；
１>変数CELL＿UPDATE＿STARTEDをTRUEに設定する：
１>UEがまだCELL＿FACH状態でない場合；
２>CELL＿FACH状態に移動する；
２>第８．５．１７節に従って、PRACHを選択する；
２>第８．５．１９節に従って、次のCCPCHを選択する；
２>第８．６．５．１節で示されるように、システム情報に与えられる伝送フォーマット組を使用する。
１>UEがセル再選択を実行する場合：
２>変数C＿RNTIを消去する；
２>MAC層中で消去されたばかりのC＿RNTIの使用を停止する。
１>第８．５．１５節に従って、現在のセルのSFNによりCFNを設定する；
１>セルアップデート手続きの場合：
２>第８．３．１．３節に従って、CELL UPDATE情報の内容を設定する；
２>アップリンクCCCH上で、URA UPDATE情報を伝送する。
１>URAアップデート手続きの場合：
２>第８．３．１．３節に従って、CELL UPDATE情報の内容を設定する；
２>アップリンクCCCH上で、URA UPDATE情報を伝送する。
１>計数器V３０２を１に設定する；
１>MAC層が、情報伝送の結果が成功か失敗かを示した時、タイマーT３０２を開始する。
上述の工程中で示される章節と公知技術の同一章節は完全に相同し、且つ、全て、TS２５．３３１によるものである。よって、描写を簡潔にするため、上述の工程の章節の詳細は省略する。注意すべきことは、本発明中のセルアップデート手続き／URAアップデート手続きは、RAB工程が（１）UE１００がDCH状態８２である時；（２）セルアップデート手続き／URAアップデート手続きが開始される原因が、“無線リンク失敗”である時だけ実行される。よって、プログラムコード１０７中で実施される本発明の手続きは、“無線リンク失敗”のようなエラーだけが、RAB解放工程を実行する。特に、本発明中のセルアップデート手続き／URAアップデート手続きを実行する中で、RLC修復不能エラーが生じる時、RAB解放工程を実行しない。
【００３２】
最後に、“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEが機能的に適切で、有用な手続きのインジケーターであることを確保するため、本発明は、UTRAN２０uがCELL UPDATE／URA UPDATE情報を受信する時、UTRAN２０uにより、実行される工程を補強する。本工程は、以下で記述され、TS２５．３３１の第８．３．１．５節で示される公知技術に対応している。
UTRANがセル／URAアップデート手続きを受信した時、UTRANは：
１>該手続きがCELL UPDATEの受信によりトリガーされる場合：
２>SRNS再配置が実行される場合：
３>CELL UPDATE CONFIRM情報を、ダウンリンクDCCH上に伝送する。
【００３３】
２>そうでなければ：
３>UTRAN中、整備（maintained）される各CNドメインの開始値（START value）を更新し、“開始表（START list）”IE中の“CNドメイン識別（CN domain identity）”中で示されるCNドメインが、相同の “開始表（START list）”IE中の “開始値（START）”が指定する値に設定する；
３>本手続きが、UEがCELL＿DCH状態の時トリガーされるものでない場合、“開始表（START list）”IE中の“CNドメイン識別（CN domain identity）”中で示される各CNドメインは：
４>“開始表”IE中の対応するSTART値を有する、２０MSBのMAC−d HFNを設定する；
４>MAC−d HFNの残りのLSBをゼロに設定する。
【００３４】
３>ダウンリンクDCCH、或いは、暗号が必要ない時に、選択的にCCCH上で、CELL UPDATE CONFIRM情報を伝送する；及び
３>選択的に、“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEと、“RLC再構築インジケーター（RB５及び５より大きいRB）”IEを含んで、UEでRLC再構築を要求し、対応するRLCエンティティが、UTRANで再構築されるようにする；或いは、
１>該手続きが、URA UPDATEの受信によりトリガーされたものである場合、
２>SRNS再配置（SRNS relocation）が実行される場合：
３>URA UPDATE CONFIRM情報を、ダウンリンクDCCHに伝送する。
【００３５】
２>そうでなければ、
３>URA UPDATE   CONFIRM情報を、ダウンリンクCCCH、或いは、DCCHに伝送する。
２>多数のURA識別（URA identity）が広められるセルで、URA UPDATE CONFIRM情報中に、“URA識別（URA  identity）”IEが含まれる；或いは、
１>ダウンリンクCCCH上で、RRC CONNECTION RELEASE情報を伝送することにより、RRC接続解放手続きを開始する。特に、UTRANは：
２>CELL＿UPDATE情報が、RB２、RB３及びRB４中の修復不能エラーのせいで、伝送される場合：
３>ダウンリンクCCCH上で、RRC CONNECTION RELEASE情報を伝送することにより、RRC接続解放手続きを開始する。
【００３６】
UTRANは、多くのCELL UPDATE CONFIRM／URA UPDATE CONFIRM情報を伝送して、UEにより、メッセージの適切な受信の確率を増加させる。この場合、これらの重複情報のRRC SN（Sequence Number）は相同である。
【００３７】
上述の工程に関して、注意すべきことは、本発明の工程は、UTRANが選択的に、“RLC再構築インジケーター（RB２、RB３、及びRB４）”IE、及び“RLC再構築インジケーター（RB５及び５より大きいRB）”IEを含んで、UEでRLC再構築を要求することである。その一方、公知技術は、“RLC再構築インジケーター（RB５及び５より大きいRB）”IEだけを、容認する。
【００３８】
公知技術と比較すると、本発明は、UEがCELL＿DCH状態で、RLC修復不能エラーが検出される時、RAB解放工程を阻止する。更に、UTRANは、明らかに、UEに送られるCELL UPDATE CONFIRM情報中に、“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEを含み、よって、UEにより、CELL UPDATE情報中のUTRANに伝送が開始される“RLC再構築インジケーター（RB２、RB３、及びRB４）”IEと関連性を与える。
【００３９】
本発明の好ましい実施形態を前述の通り開示したが、これに限定するものではなく、当該技術を熟知する者なら誰でも、本発明の精神と領域を脱しない範囲内で各種の変動や潤色を加えることができる。従って本発明の保護範囲は、特許請求の範囲で指定した内容を基準とする。
【図面の簡単な説明】
【００４０】
【図１】ワイヤレスコミュニケーションシステムを示した説明図である。
【図２】UMTSを示した説明図である。
【図３】図２で示されるRRC層を示す図である。
【図４】本発明によるワイヤレス装置を示す図である。
【図１】
2004166233.tif 000003
【図２】
2004166233.tif 000004
【図３】
2004166233.tif 000005
【図４】
2004166233.tif 000006
【外国語明細書】
2004166233.tif 000007
2004166233.tif 000008
2004166233.tif 000009
2004166233.tif 000010
2004166233.tif 000011
2004166233.tif 000012
2004166233.tif 000013
2004166233.tif 000014
2004166233.tif 000015
2004166233.tif 000016
2004166233.tif 000017
2004166233.tif 000018
2004166233.tif 000019
2004166233.tif 000020
2004166233.tif 000021
2004166233.tif 000022
2004166233.tif 000023
2004166233.tif 000024
2004166233.tif 000025
2004166233.tif 000026
2004166233.tif 000027
2004166233.tif 000028
2004166233.tif 000029
2004166233.tif 000030
2004166233.tif 000031
2004166233.tif 000032
2004166233.tif 000033