(57)【要約】【課題】送信局と受信局との間にＨＦＮ同期を回復し、時間のかかる処理やシステムリセットを必要とせず、データ損失を回避できる方法を提供する【解決手段】  本発明の同期回復方法において、暗号化セッションが開始する際に、初期のＨＦＮを導入し、暗号化セッション中に無線通信システムにおける複数の通信局の間にＨＦＮの非同期を検出し、無線通信システムにおける一の通信局における現在のＨＦＮを調整し、調整されたＨＦＮを導出し、この調整されたＨＦＮを採用し、暗号化セッションにおける後の処理に用いる。【選択図】図９
2006087097.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおいて、ハイパー・フレーム・ナンバー（HFN:  Hyper  Frame  Number）の同期を維持する方法であって、
暗号化セッションが開始する際に、初期のＨＦＮを導入する工程、
受信したプロトコール・データ・ユニットにおけるシーケンス・ナンバーの異常な値を検出する工程、及び
所定のプロトコール・データ・ユニットにおけるシーケンス・ナンバーは、直前のプロトコール・データ・ユニットと直後のプロトコール・データ・ユニットからなるシーケンスに属しない場合、当該所定のプロトコール・データ・ユニットを放棄する工程
を有する
同期維持方法。
【請求項２】
無線通信システムにおいて、ハイパー・フレーム・ナンバー（以下、ＨＦＮ（Hyper  Frame  Number）と記す）の同期を回復する方法であって、
（ａ）暗号化セッションが開始する際に、初期のＨＦＮを導入する工程、
（ｂ）前記暗号化セッション中に、前記無線通信システムにおける複数の通信局の間にＨＦＮの非同期を検出する工程、
（ｃ）前記無線通信システムにおける一の通信局における現在のＨＦＮを調整し、調整されたＨＦＮを導出する工程、及び
（ｄ）前記調整されたＨＦＮを採用し、前記暗号化セッションにおける後の処理に用いる工程
を含む
同期回復方法。
【請求項３】
前記工程（ｂ）において、プロトコール・データ・ユニット（以下、ＰＤＵ（Protocol  Data  Unit）と記す）における長さ表示部の異常な状態に関連する現象を検出する
請求項２に記載の同期回復方法。
【請求項４】
前記工程（ｂ）において、長さ表示部を含み、順次受信された所定の第２の数の復号化PDUから、所定の第１の数の長さ表示部における異常な状態に関連する現象を検出する
請求項２に記載の同期回復方法。
【請求項５】
前記工程（ｂ）において、ＰＤＵにおける不適合なパッディング・パターンに関連する現象を検出する
請求項２に記載の同期回復方法。
【請求項６】
前記工程（ｃ）において、前記通信局は、前記無線通信システムにおける受信局である
請求項２に記載の同期回復方法。
【請求項７】
前記工程（ｃ）において、前記現在のＨＦＮを１ずつ増大し、前記調整されたＨＦＮを導出する
請求項２に記載の同期回復方法。
【請求項８】
前記工程（ｃ）において、前記現在のＨＦＮを１ずつ減少し、前記調整されたＨＦＮを導出する
請求項２に記載の同期回復方法。
【請求項９】
（ｆ）一つのＰＤＵが受信されたあと所定の期間において、ＨＦＮの調整を禁止する工程をさらに有する
請求項２に記載の同期回復方法。
【請求項１０】
前記工程（ｆ）において、前記ＰＤＵは長さ表示部を含み、前記現在のＨＦＮを用いて前記ＰＤＵを復号化する場合、ＨＦＮ非同期が検出されていない
請求項９に記載の同期回復方法。
【請求項１１】
前記工程（ｆ）において、前記所定の期間は、SNスペース・ナンバーに相当する数のＰＤＵを送信するのに必要とする時間以上である
請求項９に記載の同期回復方法。
【請求項１２】
（ｇ）前記工程（ｃ）によりＨＦＮ同期の回復が判断されるまで、前記工程（ｂ）を繰り返す工程と、
（ｈ）前記工程（ｇ）の判断により前記ＨＦＮ同期の回復が判断されていないとき、前記工程（ｃ）及び前記工程（ｄ）を繰り返す工程と、
をさらに有する
請求項２に記載の同期回復方法。
【請求項１３】
前記工程（ｇ）は、前記工程（ｂ）、工程（ｃ）、工程（ｄ）を所定の回数繰り返したあと、ＨＦＮの調整を中断し、以前のＨＦＮの値をリストアする工程を含む
請求項１２に記載の同期回復方法。
【請求項１４】
前記所定の回数は２である
請求項１３に記載の同期回復方法。
【請求項１５】
前記リストアされた以前のＨＦＮの値に基づいて、現在のＰＤＵを放棄し、次のＰＤＵを復号化する
請求項１３に記載の同期回復方法。
【請求項１６】
前記以前のＨＦＮの値は、調整前のＨＦＮの値である
請求項１３に記載の同期回復方法。
【請求項１７】
現在のＰＤＵにおけるＳＮと次に続くＰＤＵにおけるＳＮとの間にＳＮ反転が発生した場合は、前記調整前のＨＦＮの値を一つ増大する
請求項１６に記載の同期回復方法。
【請求項１８】
前記工程（ｂ）、工程（ｃ）、工程（ｄ）、工程（ｇ）、工程（ｈ）を所定の回数繰り返したあと、ＨＦＮの調整の繰り返しを中止し、暗号化同期プロセスを起動する工程をさらに含む
請求項１２に記載の同期回復方法。
【請求項１９】
前記所定の回数は２である
請求項１８に記載の同期回復方法。
【請求項２０】
無線通信システムの受信装置おいて、ハイパー・フレーム・ナンバー（HFN:  Hyper  Frame  Number）の同期を維持する方法であって、
暗号化セッションが開始する際に、初期のＨＦＮを導入する工程、
受信したプロトコール・データ・ユニットにおけるシーケンス・ナンバーの異常な値を検出する工程、及び
所定のプロトコール・データ・ユニットにおけるシーケンス・ナンバーは、直前のプロトコール・データ・ユニットと直後のプロトコール・データ・ユニットからなるシーケンスに属しない場合、当該所定のプロトコール・データ・ユニットを放棄する工程
を有する
同期維持方法。
【請求項２１】
無線通信システムの受信装置おいて、ハイパー・フレーム・ナンバー（以下、ＨＦＮ（Hyper  Frame  Number）と記す）の同期を回復する方法であって、
（ａ）暗号化セッションが開始する際に、送信装置と共通する初期のＨＦＮを導入する工程、
（ｂ）前記暗号化セッション中に、前記受信局にＨＦＮの非同期を検出する工程、
（ｃ）前記受信局における現在のＨＦＮを調整し、調整されたＨＦＮを導出する工程、及び
（ｄ）前記受信局に前記調整されたＨＦＮを採用し、前記暗号化セッションにおける後の処理に用いる工程
を含む
同期回復方法。
【請求項２２】
前記工程（ｂ）において、プロトコール・データ・ユニット（以下、ＰＤＵ（Protocol  Data  Unit）と記す）における長さ表示部の異常な状態に関連する現象を検出する
請求項２１に記載の同期回復方法。
【請求項２３】
前記工程（ｂ）において、長さ表示部を含み、順次受信された所定の第２の数の復号化PDUから、所定の第１の数の長さ表示部における異常な状態に関連する現象を検出する
請求項２１に記載の同期回復方法。
【請求項２４】
前記工程（ｂ）において、ＰＤＵにおける不適合なパッディング・パターンに関連する現象を検出する
請求項２１に記載の同期回復方法。
【請求項２５】
前記工程（ｃ）において、前記現在のＨＦＮを１ずつ増大し、前記調整されたＨＦＮを導出する
請求項２１に記載の同期回復方法。
【請求項２６】
前記工程（ｃ）において、前記現在のＨＦＮを１ずつ減少し、前記調整されたＨＦＮを導出する
請求項２１に記載の同期回復方法。
【請求項２７】
（ｆ）一つのＰＤＵが受信されたあと所定の期間において、ＨＦＮの調整を禁止する工程をさらに有する
請求項２１に記載の同期回復方法。
【請求項２８】
前記工程（ｆ）において、前記ＰＤＵは長さ表示部を含み、前記現在のＨＦＮを用いて前記ＰＤＵを復号化する場合、ＨＦＮ非同期が検出されていない
請求項２７に記載の同期回復方法。
【請求項２９】
前記工程（ｆ）において、前記所定の期間は、SNスペース・ナンバーに相当する数のＰＤＵを送信するのに必要とする時間以上である
請求項２７に記載の同期回復方法。
【請求項３０】
（ｇ）前記工程（ｃ）によりＨＦＮ同期の回復が判断されるまで、前記工程（ｂ）を繰り返す工程と、
（ｈ）前記工程（ｇ）の判断により前記ＨＦＮ同期の回復が判断されていないとき、前記工程（ｃ）及び前記工程（ｄ）を繰り返す工程と、
をさらに有する
請求項２１に記載の同期回復方法。
【請求項３１】
前記工程（ｇ）は、前記工程（ｂ）、工程（ｃ）、工程（ｄ）を所定の回数繰り返したあと、ＨＦＮの調整を中断し、以前のＨＦＮの値をリストアする工程を含む
請求項３０に記載の同期回復方法。
【請求項３２】
前記所定の回数は２である
請求項３１に記載の同期回復方法。
【請求項３３】
前記リストアされた以前のＨＦＮの値に基づいて、現在のＰＤＵを放棄し、次のＰＤＵを復号化する
請求項３１に記載の同期回復方法。
【請求項３４】
前記以前のＨＦＮの値は、調整前のＨＦＮの値である
請求項３１に記載の同期回復方法。
【請求項３５】
現在のＰＤＵにおけるＳＮと次に続くＰＤＵにおけるＳＮとの間にＳＮ反転が発生した場合は、前記調整前のＨＦＮの値を一つ増大する
請求項３４に記載の同期回復方法。
【請求項３６】
前記工程（ｂ）、工程（ｃ）、工程（ｄ）、工程（ｇ）、工程（ｈ）を所定の回数繰り返したあと、ＨＦＮの調整の繰り返しを中止し、暗号化同期プロセスを起動する工程をさらに含む
請求項３０に記載の同期回復方法。
【請求項３７】
前記所定の回数は２である
請求項３６に記載の同期回復方法。
【請求項３８】
無線通信システムの受信装置おいて、ハイパー・フレーム・ナンバー（以下、ＨＦＮ（Hyper  Frame  Number）と記す）の同期を回復する方法であって、
（ａ）暗号化セッションが開始する際に、送信装置と共通する初期のＨＦＮを導入する工程、
（ｂ）前記暗号化セッション中に、前記受信局にＨＦＮの非同期を検出する工程、
（ｃ）前記受信局における現在のＨＦＮを調整し、調整されたＨＦＮを導出する工程、
（ｄ）前記受信局に前記調整されたＨＦＮを採用し、前記暗号化セッションにおける後の処理に用いる工程、及び
（ｅ）一つのＰＤＵが受信されたあと所定の期間において、ＨＦＮの調整を禁止する工程
を含み、
前記工程（ｅ）において、前記所定の期間は、SNスペース・ナンバーに相当する数のＰＤＵを送信するのに必要とする時間以上であり、前記ＰＤＵは長さ表示部を含み、前記現在のＨＦＮを用いて前記ＰＤＵを復号化する場合、ＨＦＮ非同期が検出されていない
同期回復方法。
【請求項３９】
（ｆ）前記工程（ｃ）によりＨＦＮ同期の回復が判断されるまで、前記工程（ｂ）を繰り返し、前記工程（ｂ）、工程（ｃ）、工程（ｄ）を２回繰り返したあと、更なるＨＦＮの調整を中止し、以前のＨＦＮの値をリストアする工程であって、放棄されたＰＤＵにおけるＳＮと次に続くＰＤＵにおけるＳＮとの間にＳＮ反転が発生した場合に、前記調整前のＨＦＮの値を一つ増大するところの工程、
（ｇ）前記工程（ｆ）により、ＨＦＮ同期が回復されていないとき、及び更なるＨＦＮの調整を中断していないとき、前記工程（ｃ）及び前記工程（ｄ）を繰り返す工程、及び
（ｈ）前記工程（ｂ）、工程（ｃ）、工程（ｄ）、工程（ｇ）、工程（ｈ）を２回繰り返したあと、ＨＦＮの調整の繰り返しを中止し、暗号化同期プロセスを起動する工程
をさらに有する
請求項３８に記載の同期回復方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信の技術分野に関し、特に、暗号化された無線通信システムにおいて、データ転送を中断せずにパラメータ同期を回復する技術に関する。
【背景技術】
【０００２】
高性能な通信技術規格が開発されつつある。３ＧＰＰＴＭ（3rd  Generation  Partnership  Project）は新しい通信プロトコールの一例である。例えば、[非特許文献１]にはＵＭＴＳ（Universal  Mobile  Telecommunication  System）通信システム及びそのセキュリティ・プロトコールが説明されている。また、[非特許文献２]には、UMTSに用いるＲＬＣ（Radio  Link  Control）機能が詳細に説明されている。
【０００３】
これらの規格には、「三レイヤー」方法（three-layer  approach」により通信を行う。
【０００４】
図１は、上記の通信プロトコールにおける三つのレイヤーを示すブロック図である。
【０００５】
代表的な無線通信システムにおいて、第１の局１０は一つ以上の第２の局２０と無線通信を行う。第１の局１０におけるアプリケーション１３はメッセージ１１を生成し、三番レイヤーのインターフェイス１２に送り、そして、メッセージ１１は第２の局２０に送られる。三番レイヤーの動作を制御するために、三番レイヤーのインターフェイス１２は三番レイヤーの信号送信メッセージ１４を生成できる。インターフェイス１２は、メッセージ１１、或いは、信号送信メッセージ１４を二番レイヤーのサービス・データ・ユニット（service  data  unit:  SDU）１５として二番レイヤーのインターフェイス１６に伝送する。SDU１５は任意の長さを有する。二番レイヤーのインターフェイス１６は、二番レイヤーのSDU１５と一つ以上の二番レイヤーのプロトコール・データ・ユニット（protocol  data  unit:  PDU）１７とを結合する。二番レイヤーのPDU１７は一番レイヤーのインターフェイス１８に伝送される。PDU１７は固定長を有する。即ち、可変長のSDU１５は固定長のPDU１７として伝送される。この点について以下に詳細に述べる。
【０００６】
一番レイヤーのインターフェイス１８はデータを第２の局２０へ送信する物理的なレイヤーである。送信データは第２の局２０における一番レイヤーのインターフェイス２８に受信され、一つ以上のPDU２７に再構築され、二番レイヤーのインターフェイス２６に伝送される。インターフェイス２６は、PDU２７を受信し、PDU２７から一つ以上の二番レイヤーのSDU２５を構築し、三番レイヤーのインターフェイス２２に伝送する。インターフェイス２２は、SDU２５をメッセージ２１、或いは、三番レイヤーの信号送信メッセージ２４に変換する。メッセージ２１は第１の局１０におけるアプリケーション１３が生成したメッセージ１１と同一である。また、信号送信メッセージ２４は、インターフェイス１２が生成した信号送信メッセージ１４と同一である。変換されたメッセージはインターフェイス２２に処理される。受信されたメッセージ２１は第２の局２０におけるアプリケーション２３に伝送される。
【０００７】
本稿において、PDUは、レイヤー内部に使われ、下位レイヤーに送信され、また、その下位レイヤーから受信されるデータ・ユニットである。一方、SDUは、上位レイヤーに送信され、また、上位レイヤーから受信されるデータ・ユニットである。
【０００８】
図２は、二番レイヤーからの簡略化された送信・受信プロセスを示す図である。
【０００９】
第１の局４０における二番レイヤーのインターフェイス４２は、三番レイヤーのインターフェイス４３から、SDU１〜SDU５からなるSDU列４４を受信する。SDU１〜SDU５はそれぞれ異なる長さを有する。インターフェイス４２はSDU列４４をPDU１〜PDU４からなるPDU列４５に変換する。PDU１〜PDU４は同一の長さを有する。PDU列４５における各PDUは、あるヘッダーと関連付けられ、このヘッダーにシーケンス・ナンバー（SN:  sequence  number）が含まれている。このSNはかかるPDUを特定し、また、かかるPDU  のPDU列４５における位置を示す。このＳＮにより、第２の局５０は、受信したPDU列５８（PDU列４５を処理し送信して生成される）におけるＰＤＵの順序を適切に特定できる。そのため、元のSDU列４４に対応するSDU列５４を正しく再構築できる。このようなヘッダー付きの送信モードは、確認モード（AM:  acknowledged  mode）送信と非確認モード（UM:  unacknowledged  mode）送信を含む。AM送信とUM送信のいずれには、送信局４０によりヘッダーが各PDUに付加され、各PDUがＳＮを持つことが要求される。
【００１０】
以下は、ヘッダーを各PDUに付加することを要求する送信モードを例として説明し、他の送信モードの説明を省略する。ＳＮのビット・サイズが送信モードにより変化する。例えば、UM送信モードの場合、ＳＮは各PDUのヘッダーにおいて７ビットを占め、一方、ＡM送信モードには、ＳＮは各PDUのヘッダーにおいて１２ビットを占める。
【００１１】
言い換えれば、PDU列４５における各PDU、即ち、PDU１〜PDU４は、それぞれあるＳＮと関連付けられ、図２においてそれらＳＮにそれぞれ参照番号４００〜４０３を付される。これらＳＮは、ｎビットのデータであり、二番目レイヤーのインターフェイス４２によりPDU列４５における各PDUに割り当てられる。具体的に、ＳＮ４００はＰＤＵ１に関連し、如何なる値を有してもよい。即ち、PDU列４５における一番目のPDU１のＳＮはゼロでなくでもよい。その後のPDUのＳＮ４０１〜４０３の値は、PDU１のＳＮ４００の値より、１ずつ増大する。例えば、ＳＮ４００の値は１９２である場合、ＳＮ４０１〜４０３の値は、それぞれ１９３、１９４、１９５である。なお、ＳＮはｎビットのデータである（ｎはＳＮのワード長である）ことから、ＳＮの値は２ｎ−１以上になると、ＳＮ反転（rollover）が発生するので、このとき、順番的に後ろのＰＤＵは前のＰＤＵより小さいＳＮを持つことが有り得る。例えば、ＳＮのワード長は８ビットであり、最初のＳＮの値はゼロ、その後のＳＮの値は１つずつ増大するとすると、２５６回増大したあと、ＳＮの値はゼロになる。即ち、ＳＮは周期的なアンビギュイティを有する。具体的に、２ｎ個のＰＤＵごとにＳＮは繰り返し、ＳＮ４６ａに与えられた値は、２ｎ個のＰＤＵごとに再び現れる。よって、ＳＮでＰＤＵ４５を唯一に特定することができない。従って、ＳＮを唯一の識別子として信号送信メッセージを第１の局４０と第２の局５０の間に伝送する際に、第１の局４０と第２の局５０の間に混乱は起こる可能性がある。そのため、ＳＮに加えて、各ＰＤＵに関連するハイパー・フレーム・ナンバー（HFN:  Hyper  Frame  Number）をも用いる。
【００１２】
図２を参照すると、PDU列４５は暗号化エンジン４６により暗号化される。PDUの暗号に多くの変数が含まれる。暗号化エンジン４６は、PDU１〜PDU４のＳＮ４００〜４０３、及び暗号キー４７を変数として用いる。暗号キー４７は、三番レイヤーのインターフェイス４３からコマンド・プリミティブ（command  primitive）により提供される。そして、暗号化されたPDU（ePDU）列４８が得られ、一番レイヤーのインターフェイス４１に伝送され、送信される。
【００１３】
第２の局５０は、第１の局４０と逆の流れの処理を行なう。具体的に、第２の局５０は、あるＳＮをｅPDU列５８における各ｅＰＤＵと関連付け、即ち、ＳＮ５００〜５０３はそれぞれｅPDU１〜ｅPDU４と関連付けられる。AM送信とUM送信において、ＳＮ５００〜５０３は受信された各ｅＰＤＵのヘッダーから抽出される。ＳＮ５００〜５０３はＳＮ４００〜４０３と一致する。ＳＮ５００〜５０３及び暗号キー５７は復号化エンジン５６に使われ、ｅPDU列５８をPDU列５５に復号化する。そして、PDU列５５を二番レイヤーのSDU列５４に変換され、そのSDU列５４は、三番レイヤーのインターフェイス５３に伝送される。
【００１４】
ｅPDU列５８を正しくPDU列５５に復号化するために、復号化エンジン５６は暗号キー５７を使う必要がある。暗号キー５７は暗号キー４７と同じである。復号化エンジン５６は、三番レイヤーの信号送信メッセージ、いわゆる「暗号化再構築起動コマンド」（ciphering  reconfiguration  activation  command）を用い、暗号キー５７と暗号キー４７とを同期させる。
【００１５】
第１の局４０は、セキュリティを期して暗号キー４７を定期的に変更する場合がある。そのため、三番レイヤーのインターフェイス４３は、三番レイヤーの暗号化再構築起動コマンドを作成し、暗号キー４７の変更を要求し、また、この変更が有効になる期間には中継ぎをする。簡略化のため、暗号化再構築起動コマンドは、実際の時間でなく起動時間を示す。この起動時間は単なる二番レイヤーのＰＤＵのＳＮ値である。順番上この起動時間より前のＳＮを有するＰＤＵは古い暗号キーにより暗号化され、起動時間と同時又はその後のＳＮを有するＰＤＵは新しい暗号キーにより暗号化される。起動時間と暗号キーを暗号化再構築起動コマンドに含ませることで、第１の局４０は第２の局５０に同期して暗号化処理を行うことができる。
【００１６】
暗号化再構築起動コマンドを受信した後、第２の局５０は以前の暗号キーを用いて起動時間より前のＳＮを有するｅＰＤＵを復号し、新しい暗号キーを用いて起動時間と同時又はその後のＳＮを有するｅＰＤＵを復号する。
【００１７】
ＵＭＴＳシステムにおける暗号化メカニズムが働くために、送信局と受信局におけるすべてのパラメータはマッチしなければならない、即ち、すべてのパラメータは同期しなければならない。
【００１８】
図３は、従来技術において二番レイヤーのインターフェイス６０の詳細を示すブロック図である。
【００１９】
二番レイヤーのインターフェイス６０は、互いに通信するＲＬＣ（Radio  Link  Control）レイヤー６２とＭＡＣ（Medium  Access  Control）レイヤー６４を有する。ＭＡＣレイヤー６４は、ＲＬＣレイヤー６２と一番レイヤーのインターフェイス６１とのインターフェイスとして機能する。ＭＡＣレイヤー６４は、ＲＬＣレイヤー６２から受信するＰＤＵ６３の送信動作を一系列の送信時間間隔７２（ＴＴＩ：transmission  time  interval）に分割する（図４を参照されたい）。各ＴＴＩ７２は、同一の時間幅を有し、各ＴＴＩ７２の時間幅において、ＭＡＣレイヤー６４はトランスポート・ブロック・セット７４を一番レイヤーのインターフェイス６１へ送信する。各トランスポート・ブロック・セット７４は、所定の数のトランスポート・ブロック７０４を備え、各トランスポート・ブロック７０４は、一つのＲＬＣ  ＰＤＵ７５を有し、また、オプションとして、ＭＡＣヘッダーを備えてもよい。各ＴＴＩ７２におけるすべてのＲＬＣ  ＰＤＵ７５、そして、トランスポート・ブロック７０４は、同じ長さを有し、ただし、ＴＴＩ７２の幅内に、各トランスポート・ブロック・セット７４におけるＲＬＣ  ＰＤＵ７５（或いは、等価トランスポート・ブロック７０４）の数は変わることがある。
【００２０】
ＳＮは、送信局と受信局との間に送られる各情報パッケージに埋め込まれている。即ち、暗号化セッションが開始する前に、各ＲＬＣ  ＰＤＵ６３における初期のＨＦＮのみが明示的に送信局と受信局との間に伝送される。この場合を除き、ＳＮのみが送信され、ＨＦＮは送信されない。ＨＦＮを送信する代わりに、各局は各ＰＤＵのＳＮに基づき個別に現在のＨＦＮの記録を保持し、残りの暗号化セッションに使う。これを実現するために、各ＰＤＵ６３／７５と関連するＳＮ７６により、ＰＤＵ６３／７５について「カウント値−Ｃ」６８０を形成する。カウント値−Ｃ６８０は３２ビットを有し、その上位（３２−ｎ）ビットはＨＦＮ６８１に占められる（ＳＮはｎビットである）、下位ビットは、ＰＤＵ６３／７５のＳＮ６８２に占められる。ＨＦＮ６８１は最初にゼロに設定され、或いは、無線アクセスネットワークにより指定される所定値に設定され、そして、ＰＤＵ６３／７５のＳＮ７６の反転が検出されるたびに、ＨＦＮ６８１は一つ増大する。例えば、ＨＦＮ６８１はゼロであり、また、ＰＤＵ６３／７５のＳＮ７６の値は２５５である場合は、カウント値−Ｃ６８０は２５５であり、この値はＰＤＵ６３の暗号化に使われ、暗号化されたＰＤＵ７５を生成する。その後のＰＤＵ６３／７５は、ＳＮ７６の値はゼロであり、反転により、暗号化エンジン６７はＨＦＮ６８１の値をゼロから１に増やす。よって、そのＰＤＵ６３の暗号化に使われるカウント値−Ｃ６８０は２５６である。
【００２１】
暗号化セッションの間に、送信局、受信局の各々は独自のＨＦＮを保持する必要があるので、利用可能な同期の唯一の参照基準は、セッションが開始する際に最初のＨＦＮ値は受信されることである。これでは、一局のＨＦＮは他局のＨＦＮと非同期になってしまう危険性がある。ＳＮはワード長で決められた最大値で反転する（roll  over）と、ＨＦＮは１つ増加されるので、ＨＦＮ同期の喪失を引起す事由が２つある、即ち、（１）受信機はSNスペース・ナンバー(SN  space  number)」以上数の継続するＰＤＵを受信できなかった場合（ＵＭの場合は、ＳＮは７ビットであり、SNスペース・ナンバーは１２８である）、（２）ＰＤＵに埋め込んだＳＮフィールドにおける一部のビットは無線送信中に劣化した場合である。
【００２２】
受信局において正しく復号化ＳＤＵを連結するために、送信局の二番レイヤーは「長さ表示部」、すなわち、ＳＤＵデータの終了位置を示すビットを最後のＳＤＵデータセグメントが含まれているＰＤＵの最初の位置に挿入する（ここで、元々のＳＤＵが十分長く、複数のＰＤＵに分割可能であるとする）。ただし、幾つかのＳＤＵは十分短く、一つのＰＤＵに収まることができる場合は、これらのＳＤＵを連結することができ、適切な長さ表示部がＰＤＵの最初に挿入される。ＰＤＵのサイズにより、たとえば、長さ表示部（ＬＩ）は７ビット或いは１５ビットとすることができる。ＰＤＵ全体を占める十分なデータがない場合は、「パッディング・フィールド」、或いは、付随の「ＳＴＡＴＵＳ」メッセージを付加する。
【００２３】
図５は非確認モードデータ（UMD:  unacknowledged  mode  data）ＰＤＵの一例を示す図である。
【００２４】
ヘッダーは、ＳＮフィールド８１、拡張ビットＥ８２を含み、また、オプションとして、長さ表示部８３を含んでもよい。長さ表示部８３も拡張ビットＥ８４を有する。ＳＮフィールド８１の後に設けられた拡張ビットＥ８２は、ＵＭＤ  ＰＤＵ８０の次に続く８ビット（即ち、１バイト）にデータがあるか否か、或いは、長さ表示部があるか否かを示す。同様に、長さ表示部８３の後に設けた拡張ビットＥ８４は、ＵＭＤ  ＰＤＵ８０の次に続く８ビット（１バイト）にデータがあるか否か、或いは、他の長さ表示部があるか否かを示す。上記のように、一つ以上のＳＤＵのデータが一のＰＤＵ８０に含ませる場合、或いは、「パッディング・フィールド」や付随の「ＳＴＡＴＵＳ」メッセージがＰＤＵに含まれている場合は、複数の長さ表示部を設けてもよい。これらのフィールドは連続してＳＮ８１に継続する。[非特許文献２]によれば、データ８５の後の未使用の８ビット（１バイト）をパッディング８６とされる。ＰＤＵの未使用スペースは、ＰＤＵの最後に位置し、パッディング・フィールドと称される。長さ表示部の所定の値を用い、パッディング・フィールドの有無を示す。この所定の値はパッディング  ＬＩと称される。ＰＤＵ全体の長さはＲＬＣレイヤーにより決められたＰＤＵの長さに達するように、パッディング・フィールドは十分な長さを有しなければならない。パッディングは任意の値を有してもよく、送信機と受信機はただパッディングの値を無視する。ＳＴＡＴＵＳメッセージ、例えば、ＳＴＡＴＵＳ  ＰＤＵは、パッディングスペースの一部又は全部を使ってＡＭＤ  ＰＤＵに付随することができ、また、長さ表示部の所定の値を用い、付随のＳＴＡＴＵＳメッセージの有無を示す。付随のＳＴＡＴＵＳＰＤＵはＰＤＵデータのすぐ後に続くので、ここの長さ表示部（ＬＩ）は、パッディング  ＬＩを置き換える。利用可能なスペースの一部しか使わない場合は、ＰＤＵにおける付随のＳＴＡＴＵＳ  ＰＤＵの後の残留部分はパッディングとして認識される。
【００２５】
UM送信データを暗号化する際に（ここで、ＳＮは７ビットで、ＨＦＮは２５ビットである）、最初のバイトを除いたＰＤＵのすべてのバイトは暗号化される。この最初のバイトにはＰＤＵのＳＮ及び拡張ビットが含まれている。一方、ＡM送信データを暗号化する際に（ここで、ＳＮは１２ビットで、ＨＦＮは２０ビットである）、最初の２バイトを除いたＰＤＵのすべてのバイトは暗号化される。この最初の２バイトには、同様にＰＤＵのＳＮ及び拡張ビットが含まれている。この拡張ビットは、次のバイト（即ち、３番目のバイト）が、拡張ビットの付いている長さ表示部であるか否かを示す、或いは、次のバイトはＳＤＵのデータバイトであるか否かを示す。
【００２６】
周知のように、長さ表示部を送信側と受信側との間に生じるHFN非同期の検出に用いることができる。このことは[非特許文献３]及び[特許文献１]に説明されている。また、所定のパターンを有するパッディング・フィールドもHFN非同期の検出に用いることができる。ＰＤＵに埋め込まれた長さ表示部において生じ得るイリーガルな状態であって、HFN非同期の発生を表すイリーガルな状態は以下のものがある。
１．ＰＤＵに埋め込まれた長さ表示部の値はＰＤＵに格納され得るデータの長さより大きい。
２．複数の長さ表示部は小さい順に並んでいない。
３．長さ表示部の保留値はプロトコールに認められない値である。
４．ＰＤＵに埋め込まれた長さ表示部は所定値を有し、なお、所定の箇所にはない。
【特許文献１】US  Patent  Application  2003/0091048,  “Detection  of  Ciphering  Parameter  Unsynchronization  in  a  RLC  Entity”.
【非特許文献１】The  third  Generation  Partnership  Project  (3GPP）specifications,  3GPP  TS  33.102  V6.1.0  (2004-06),  “Security  Architecture”.
【非特許文献２】The  third  Generation  Partnership  Project  (3GPP）TS  25.322  V6.1.0  (2004-06),  Radio  Link  Control  (RLC)  protocol  specification.
【非特許文献３】3GPP  RAN  WG2  #37  document,  “Erroneous  LI  and  RLC  Reset  Procedure”,  R2-031831.
【発明の開示】
【発明が解決しようとする課題】
【００２７】
しかし、[非特許文献３]及び[特許文献１]に説明された以上の手法を用いてHFN非同期を検出する方法には問題点もある。[非特許文献３]によれば、誤った長さ表示部を検出すると、この誤った長さ表示部は、HFN非同期によるものであると推測され、ＲＬＣリセット処理が起動され、ＨＦＮ同期を回復させる。しかし、この方法はＡＭ送信にしか適用できない。ＵＭ送信の場合は、ＵＭ用のＲＬＣリセット処理は[非特許文献２]と[非特許文献３]のいずれにも開示されていないので、以上の[非特許文献３]の方法は適用できない。
【００２８】
[特許文献１]によれば、HFN非同期が検出されると、受信機は通信リンクを同期させるプロセスを起動する。これは明示パラメータ信号化処理により実行できる。ＡＭ送信とＵＭ送信両方用の明示パラメータ信号化処理の例としては、ＲＬＣ回復処理とセキュリティパラメータ同期処理がある。ＡＭ送信用の明示パラメータ信号化処理の例としては、ＲＬＣリセット処理がある。
【００２９】
明示パラメータ信号化処理には、送信側と受信側との間に明示的な信号送達が行われるので、送信負担が増え、時間がかかる。送信遅延や、無線送信における信号損失の発生や、タイムアウト再送信メカニズムの採用などにより、ＨＦＮ再同期処理も時間が掛かる。したがって、送信局と受信局との間にＨＦＮ再同期を実現でき、しかも、時間のかかる処理やシステムリセットを必要とせず、データ損失を回避できる方法が要求される。
【課題を解決するための手段】
【００３０】
本発明は、無線通信システムにおいて、ハイパー・フレーム・ナンバー（HFN:  Hyper  Frame  Number）同期を回復する方法を提供する。
【００３１】
本発明の同期回復方法は、暗号化セッションが開始する際に、初期のＨＦＮを導入する工程、暗号化セッション中に、無線通信システムにおける複数の通信局の間にＨＦＮの非同期を検出する工程、無線通信システムにおける一の通信局における現在のＨＦＮを調整し、調整されたＨＦＮを導出する工程、及び調整されたＨＦＮを採用し、暗号化セッションにおける後の処理に用いる工程を含む。
【発明の効果】
【００３２】
本発明によれば、データ転送を中断せずに、受信局はオンラインでＨＦＮ同期を回復することができ、また、非同期パラメータを使ってPDUを復号化する際に生じるデータ損失を最小限に抑えることができる。さらに、明示パラメータ信号化処理、例えば、RLCリセット処理を実行する必要性が低く、送信の時間遅延や信号損失を回避できる。
【発明を実施するための最良の形態】
【００３３】
次に、添付した図面を参照しながら、本発明の実施形態を説明する。
【００３４】
以下、３ＧＰＰＴＭ（3rd  Generation  Partnership  Project）を例として本発明を説明する。しかし、本発明はこれに限定されず、本発明の趣旨を離脱しない限り、本発明は同様な構成を有する如何なるシステムに適用する。
【００３５】
プロトコール・データ・ユニット（PDU）には、ハイパー・フレーム・ナンバー（HFN）非同期の検出に専用のフィールドがない。上記したように、長さ表示フィールド及びパッディング・フィールドをこれに用いることができるが、専用のフィールドではないので、多くの場合は適切に対応できず、信頼度の高いHFN非同期検出は十分に保証されていない。
【００３６】
例えば、長さ表示フィールドを利用する技術は長さ表示フィールドを有しないＰＤＵに適用できない。また、長さ表示フィールドを用いた技術に基づいてＨＦＮを調整してＰＤＵを復号化する場合、ＨＦＮ非同期の徴候を更に発見できなくても、得られた調整後のＨＦＮは真のＨＦＮ同期値であることを十分に保証できない。また、下層の巡回冗長検査(CRC:  cyclic  redundancy  check)メカニズムによる検出されないＰＤＵのビット劣化(bit  corruption)を考慮すると、ＨＦＮ非同期の徴候の検出は、ＨＦＮは非同期であることを十分に保証できない。ＰＤＵのビット劣化は下層CRCメカニズムによる検出から漏れる確率は低いので、一つの事象の中に、２つのＰＤＵのビット劣化が検出されない蓋然性が非常に低い。以下の説明にはこのような状況を考慮しないことにする。
【００３７】
以上に述べた理由によって、本発明は上記したＨＦＮ非同期検出技術を利用し、従来のシステムにおいて生じる問題を克服するように構成しまた保護手段を備える。
【００３８】
前述のように、ＨＦＮ同期喪失を引起す可能性が２つある、即ち、（１）受信機は、SNスペース・ナンバー以上数の継続するＰＤＵを受信しなかった場合、（２）ＰＤＵに埋め込まれたＳＮフィールドの一部のビットは無線送信中に劣化した場合である。
【００３９】
以下は、ＨＦＮ同期喪失を引起す２番目の可能性、即ち、下層CRCメカニズムにより検出されなかったＰＤＵにおけるビットの劣化を考える。
【００４０】
ＰＤＵのＳＮフィールドにおいてビット劣化が発生した場合は、劣化したＳＮは予想せぬ、順番外れの値にジャンプする。次のＰＤＵのＳＮから正常のシーケンスが再開する。
【００４１】
図６は、ＰＤＵが受信局９０により受信され、左から右への順序で復号化される様子を示す図である。
【００４２】
ＵＭ送信の場合（再送信が禁止されている）は、正常のＰＤＵ９１のシーケンスのＳＮ値は、例えば、０００、００１、００２、００３、００４、００５となる。もし第２のＰＤＵ９３が劣化し、そのＳＮ値は１００になった場合、受信局９０は以下のようなＰＤＵシーケンスを受信し、そのＳＮ値は、０００、１００、００２、００３、００４、００５である。
【００４３】
従来技術において、受信局は第３のＰＤＵ９４に対応するＨＦＮを１つ増やすべきとは判断する、なぜなら、第３のＰＤＵ９４のＳＮ値（００２）は直前のＰＤＵ９３のＳＮ値（１００）より小さいので、第３のＰＤＵ９４のＨＦＮは必ず後の１２８個のＰＤＵバッチに属するからである。さらに、ＵＭプロトコールの規定により、ＰＤＵ９４を調整前のＨＦＮ値を用いて再送信することができない。よって、ＰＤＵの劣化に起因する一時的な異常は検出されず、後に受信されたＰＤＵについて、送信局と受信局とのＨＦＮ値の差は１のままである。しかし、２つの継続するＰＤＵに発生するＳＮ劣化はCRCメカニズムにより検出されない確率が非常に低く、また、２つ継続するＰＤＵが劣化し、それらの劣化したＳＮ値も継続する確率が著しく低い。例えば、７ビットのＳＮを有するＵＭＤのＰＤＵについて、後者の確率は前者の確率の約１／１２８しかない。
【００４４】
本発明の第１の実施形態において、あるＳＮ値を有するＰＤＵを受信した場合、そのＳＮ値は、前回受信したＰＤＵのＳＮ値の次の値でなく、次に受信するＰＤＵのＳＮ値の前の値でもない場合は、このＰＤＵを無視する、言い換えれば、このＰＤＵを放棄し、恰も受信しなかったかのように処理を続行する。上記の例について、図７に示すように、第２のＰＤＵ９３（ＳＮ値＝１００）を放棄する。その後、次に続くＰＤＵ９４（ＳＮ値＝００２）、即ち、第３のＰＤＵ９４は、第１のＰＤＵ９２（ＳＮ値＝０００）と同じＨＦＮサイクルに属するとして処理される。このように、ＨＦＮ同期が保たれる。
【００４５】
次に、ＨＦＮ同期喪失を引起す１番目の可能性を考える。
【００４６】
受信機はSNスペース・ナンバー以上数の継続するＰＤＵを受信できなかった場合、送信機と受信機とのＨＦＮ値の差は１である。よって、受信機側でＨＦＮを１つ増やせば、ＨＦＮ同期が回復される。その理由は、SNスペース・ナンバー２倍以上数の継続するＰＤＵを受信できなかった場合（ＵＭの場合は、SNスペース・ナンバー＝１２８であるので、SNスペース・ナンバー２倍は２５６となる、即ち、２５６以上のＰＤＵを受信できなかった場合）を除き、ＨＦＮの非同期は、送信機と受信機とのＨＦＮ値の差は１であることを意味する。２５６以上のＰＤＵを受信しなかった或いは損失した場合は、現在のＨＦＮの値を１つ増やした後に、受信機は依然ＨＦＮ非同期を検出したなら、受信機側で、ＨＦＮの値をさらに１つ増やせばよい。多くのＰＤＵを損失する確率が低いので、ＨＦＮのオンライン調整量の最大値をある限界以内に制限する。ＨＦＮの調整量はこの限界値に達した後になおＨＦＮ非同期が検出された場合、オンラインＨＦＮ調整処理を失敗として終了する。そして、明示パラメータ信号化処理を起動する。
【００４７】
図８を参照して、以上の処理を次のようにまとめる。
ステップ８００：処理を開始する。ＰＤＵを受信する。
ステップ８０１：すべてのプロセスカウンターをゼロにリセットする。
ステップ８０２：受信したＰＤＵからＨＦＮ非同期を検出する。
ステップ８０３：分析によりＨＦＮ非同期を検出したか否かを判断し、ＨＦＮ非同期を検出できなかった場合は、ステップ８１２に進み、そうでない場合は、ステップ８０４に進む。
ステップ８０４：ＨＦＮ調整カウンターは参照され、カウント値が２より小さい場合、処理がステップ８０５に進み、そうでない場合は、ステップ８１０に進む。
ステップ８０５：現在のＨＦＮの値を１つ増やす。
ステップ８０６：ＨＦＮ調整カウンターの値を１つ増やし、現在のＨＦＮ値の増加を記録する。そして、処理はステップ８０２に戻る。
ステップ８１０：ＨＦＮの値を２回増やした場合、ＨＦＮの調整を中止し、暗号化同期プロセスを起動する。
ステップ８１１、８１２：  処理を終了する。
【００４８】
以上のＨＦＮ調整カウンターの最大許容値は、好ましい実施例を考慮して定めることができるが、現実的な数値を用いても良い。また、以上の処理は他の態様で実行されても良く、たとえば、他のステップを介在してもよい。
また、ステップ８０４を無視してステップ８０３から直接ステップ８０５に進んでもよい。さらに、無線送信中に損失される、SNスペース・ナンバーに相当する数のＰＤＵを送信機により送信するのに時間がかかるので、受信機は一つのＰＤＵが受信され、正しく復号化されるまでの一定の期間において、ＨＦＮ調整処理（ステップ８０５）を禁止してもよい。例えば、この一定の期間を送信機がSNスペース・ナンバーに相当する数のＰＤＵを送信するのに必要な時間以上に設定する。
【００４９】
以上の第1の実施形態に、ＨＦＮ調整処理が失敗として中止された場合は、一例として、ＨＦＮ調整処理中のＰＤＵを放棄する。放棄されたPDUのSNと次に続くPDUのSNとの間に、ＳＮ反転（rollover）が発生した場合を除き、元々の調整前のＨＦＮ値は次のＰＤＵに割り当てられる。上記のＳＮ反転が発生した場合は、元々のＨＦＮ値は一つ増やされる。言い換えれば、ＨＦＮ調整の回数は例えば事前に２に規定された場合（ステップ８０４）、ＨＦＮ調整処理が失敗として中止されたとき、元々のＨＦＮ値は既に二回増やされており、処理が中止された現在のＨＦＮ値は、「元々のＨＦＮ値＋２」に相当する。次のＰＤＵに割り当てられるＨＦＮ値は、「現在のＨＦＮ値−２」に相当する。従って、「元々のＨＦＮ値」とは、本発明の上記処理プロセスの一回反復においてHFN調整が行われる前のＨＦＮ値を意味し、単なる「前回のＨＦＮ値」を意味するものではない。
【００５０】
なお、ＰＤＵにおける各ビットが劣化し、また、この劣化は下層CRCメカニズムにより検出されない可能性がある。もし、ビット劣化がＨＦＮ非同期の検出に用いられたＰＤＵの部分に起きた場合は、例えば、長さ表示フィールド或はパッディング・フィールドに起きた場合は、ＨＦＮ非同期が誤って検出される可能性がある。しかし、ＰＤＵの劣化に起因するＨＦＮ非同期と、受信機がSNスペース・ナンバー以上数の継続するＰＤＵを受信しなかったことに起因するＨＦＮ非同期とは、見かけ上の効果が同じであり、また、共にHFN調整処理を起動させるので、別の措置をとり、誤ったケースに対してHFN調整処理を行うことを回避する必要がある。
【００５１】
HFN調整処理は所定の反復回数に制限されている。上記の例にはその反復回数は２に規定される。即ち、第１の実施例の反復回数を例にとると、ＨＦＮ調整処理が２回中止されれば、２つの継続するPDUが放棄され、本発明の方法によるＨＦＮ同期のオンライン回復は失敗したことを意味する。そして、明示パラメータ信号化処理が起動される。
【００５２】
図９を参照して、以上の処理を次のようにまとめる。
ステップ９００：処理を開始する。ＰＤＵを受信する。
ステップ９０１：すべてのプロセスカウンターをゼロにリセットする。
ステップ９０２：受信したＰＤＵからＨＦＮ非同期を検出する。
ステップ９０３：分析によりＨＦＮ非同期を特定したか否かを判断し、ＨＦＮ非同期を検出できなかった場合は、ステップ９２４に進み、そうでない場合は、ステップ９０４に進む。
ステップ９０４：ＨＦＮ調整カウンターが参照され、カウント値が２より小さい場合、処理がステップ９０５に進み、そうでない場合は、ステップ９０８に進む。
ステップ９０５：現在のＨＦＮの値を１つ増やす。
ステップ９０６：ＨＦＮ調整カウンターの値を１つ増やし、現在のＨＦＮ値の増加を記録する。そして、処理はステップ９０２に戻る。
ステップ９０８：ＨＦＮの値は２回増加された場合は、このPDUを放棄し、元々のＨＦＮ値をリストアする。
ステップ９１０：プロセス反復カウンターの値を１つ増やし、現在のＨＦＮ調整処理の反復回数を記録する。
ステップ９１２：プロセス反復カウンターが参照され、カウント値が２より小さい場合、処理がステップ９１４に進み、そうでない場合は、ステップ９１８に進む。
ステップ９１４：プロセス反復回数は２に達していない場合、現在反復中のＨＦＮ調整処理を失敗とし、調整処理前のＨＦＮ値をリストアする（ＳＮ反転が生じた場合を除く。この場合は、「調整処理前のＨＦＮ値＋１」を用いる）。そして、HFN調整カウンターをゼロにリセットする。
ステップ９１６：受信機は次のPDUが受信されるまで待機する。そして、処理はステップ９０２に戻る。
ステップ９１８：プロセス反復回数は２に達した場合、ＨＦＮの調整を中止し、暗号化同期プロセスを起動する。
ステップ９２０、９２４：  処理を終了する。
【００５３】
以上の各カウンターの最大許容値を好ましい実施例を考慮して定めることができるが、現実的な数値を用いても良い。また、以上の処理は他の態様で実行されても良く、他のステップを介在してもよい。
【００５４】
ここで説明した条件では、ＨＦＮ調整処理が失敗した後に元々のＨＦＮ値がリストアされ、現在のHFNを再同期させる場合を除き、ＨＦＮ調整処理は通常ＨＦＮを増加する処理である。以上の実施例には、HFNを再同期させるためにHFN値を減少する処理を行わない。
【００５５】
本発明の第２の実施例として、ＨＦＮ増加が一定回数（上限を設定する）失敗した後に（即ち、ＨＦＮを増加してもHFN同期を回復できなかった）、上記の第１の実施例のようにPDUを放棄することをせずに、HFN値を減少して、HFN同期を回復する処理を行う。上記の第１の実施例におけるＨＦＮを増加する処理と同様に、処理が失敗するまでのHFN減少処理及び反復処理について、処理回数に上限を設ける。
【００５６】
本発明の第３の実施例として、ＳＮの異常と共に又はその代わりに、長さ表示フィールドを用いてＨＦＮ非同期を検出する。例えば、次の状況を考える、即ち、逐次受信され、長さ表示フィールドを含み、所定の第２の数の復号化後のUMD  PDUから、所定の第１の数のイリーガルな長さ表示フィールドを検出する場合を考える、例えば、任意１０個のPDUから２つのイリーガルな長さ表示フィールドを検出する。
【００５７】
第３の実施例によれば、現在のＨＦＮ値を一つ増やし、そして、この１０個の長さ表示フィールドを含むPDUのうち、前回検出された、イリーガルな長さ表示フィールドを含むPDUは、その後の全てのPDUと共に、調整後のHFN値を用いて再度復号化する。
任意１０個の長さ表示フィールドを含むPDUのうち、２より多いPDUはイリーガルな長さ表示フィールドを含む限り、以上の処理を反復して行なう。上記の実施例と同様に、所定のPDUサンプル／バッチに対するＨＦＮ調整処理の反復処理について、処理回数に上限を設け、その上限に達した場合、処理が失敗したと判断する。
【００５８】
具体例として、例えば、受信機は以下のようなUMD  ＰＤＵシーケンスを受信し、そのＳＮ値は、０００、００１、００２、００６、００７、００８、００９、０１０、０１１、０１２、０１３、０１４、０１５、０１６、０１７、及び０１９であるとする。また、簡略化のために、SN値が奇数であるすべてのPDUは長さ表示フィールドを含み、SN値が偶数であるすべてのPDUは長さ表示フィールドを含まないとする。従って、リーガルな長さ表示フィールドは、ＳＮ値が００１、００７、００９、０１１、０１３、０１５、０１７、及び０１９となるPDUからしか検出されない。図１０を参照されたい。
【００５９】
ＳＮ値が００１、００９であるPDU（最初３つの長さ表示フィールドを含み、復号化後のPDUのうちの２つ）について、HFN=0の時、イリーガルな長さ表示フィールドが検出される。よって、この例には、ＨＦＮ値を一つ増やし、ＳＮ値が００９であるPDUを再度復号化する。そして、HFN=１の時、ＳＮ値が０１１、０１７であるPDUにイリーガルな長さ表示フィールドが検出される。即ち、その次の４つの長さ表示フィールドを含むPDUのうち、２つのPDUにイリーガルな長さ表示フィールドが検出される。よって、再びＨＦＮ値を一つ増やし、ＨＦＮは２になり、ＳＮ値が０１７であるPDUを再度復号化する。
【００６０】
実際に、イリーガルな長さ表示フィールド検出の成功率は１００％でないので、長さ表示フィールドを含むPDUの上記第２の数として小さな値を選択する場合は、大きな値を選択する場合より、長い回復時間が得られる。しかし、HFN同期の回復は、少ない回数の反復で実現できるものではない。一方、上記第１の数として大きな値（例えば、３）を選択して以上のメカニズムをより頑丈にすると、その結果、HFN同期回復の時間が延長される。なお、イリーガルな長さ表示フィールドが検出された前回のPDUが始まる際に、本実施形態によるHFNの更新を行う。即ち、任意のイリーガルな長さ表示フィールドを含むPDUのうち、前回検出されたイリーガルな長さ表示フィールドを含むPDUは再度復号化される。これにより、メモリに対する要求が低減される。しかし、メモリに対する要求を低減することが第１の目的ではない場合は、イリーガルな長さ表示フィールドが検出された最初のUMD  PDUからHFNの更新を行ってもよい。図１１を参照されたい。
【００６１】
ＨＦＮ非同期による他の徴候として不適合なパッディング・パターンがある。前述のように、PDUが通信システムに要求される所定の長さを有するために、パッディングはPDUの最後に未使用のスペースを占める。また、パッディングは、PDUのヘッドに（ここに「STATUS  PDU」が挿入されていない）自己の長さ表示部（ＬＩ）を有する。よって、パッディングＬＩによるパッディングとPDUの最後にあるパッディングとの不一致は生じる。従って、パッディング・パターンを用いてＨＦＮ非同期を検出することができる。
【００６２】
さらに、複数の前述したＨＦＮ非同期による徴候の組み合わせを用い、本発明の方法でＨＦＮ非同期を検出してもよい。
【００６３】
本発明によると、データ転送を中断せずに、受信局はオンラインでＨＦＮ同期を回復することができ、また、非同期パラメータを使ってPDUを復号化する際に生じるデータ損失を最小限に抑えることができ、また、明示パラメータ信号化処理、例えば、RLCリセット処理を、最後の手段として使う場合を除き、実行する必要性が低いので、送信の時間遅延や信号損失を回避できる。
【００６４】
以上、本発明の好ましい実施形態を説明したが、本発明はこれらの実施形態に限定されず、本発明の趣旨を離脱しない限り、本発明に対するあらゆる変更は本発明の範囲に属する。
【図面の簡単な説明】
【００６５】
【図１】上記の通信プロトコールにおける三つのレイヤーを示すブロック図である。
【図２】図２は、二番レイヤーからの簡略化された送信・受信プロセスを示す図である。
【図３】図３は、従来技術において二番レイヤーのインターフェイス６０の詳細を示すブロック図である。
【図４】従来技術において代表的なＴＴＩの配置を示す図である。
【図５】図５は非確認モードデータ（UMD:  unacknowledged  mode  data）ＰＤＵの一例を示す図である。
【図６】本発明の実施形態において、ＰＤＵが受信局９０により受信され、左から右への順序で復号化される様子を示す図である。
【図７】本発明の実施形態において、ＰＤＵにおけるＳＮ劣化によるＨＦＮ非同期を回避する方法を説明する図である。
【図８】本発明の一の実施形態に係る方法を説明するフローチャートである。
【図９】本発明の他の実施形態に係る方法を説明するフローチャートである。
【図１０】本発明の実施形態において、イリーガルな長さ表示部状態に誘発されたＨＦＮ調整により、受信したＰＤＵの復号化処理を説明する図である。
【図１１】本発明の実施形態において、イリーガルな長さ表示部状態に誘発されたＨＦＮ調整により、受信したＰＤＵの復号化処理を説明する図である。
【符号の説明】
【００６６】
１０、４０  第１の局
２０、５０  第２の局
１３、２３  アプリケーション
１１、２１  メッセージ
１２、２２、４３、５３  三番レイヤーのインターフェイス
１４、２４  三番レイヤーの信号送信メッセージ
１５、２５  二番レイヤーのサービス・データ・ユニット（ＳＤＵ）
１６、２６、４２、６０  二番レイヤーのインターフェイス
１７  二番レイヤーのプロトコール・データ・ユニット（ＰＤＵ）
１８、２８、４１、６１  一番レイヤーのインターフェイス
４４、５４  SDU列
４５、５８  PDU列
４６  暗号化エンジン
４７、５７  暗号キー
４８、５８  暗号化されたPDU（ePDU）列
５６  復号化エンジン
６２  ＲＬＣレイヤー
６４  ＭＡＣレイヤー
７２  送信時間間隔（ＴＴＩ）
７４  トランスポート・ブロック・セット
７０４  トランスポート・ブロック
７５  ＲＬＣ  ＰＤＵ
８１  ＳＮフィールド
８２  拡張ビットＥ
８３  長さ表示部
８４  拡張ビットＥ
８６  パッディング
９０  受信局
９１、９３、９４  ＰＤＵ
４００〜４０３  ＳＮ
【図１】
2006087097.tif 000003
【図２】
2006087097.tif 000004
【図３】
2006087097.tif 000005
【図４】
2006087097.tif 000006
【図５】
2006087097.tif 000007
【図６】
2006087097.tif 000008
【図７】
2006087097.tif 000009
【図８】
2006087097.tif 000010
【図９】
2006087097.tif 000011
【図１０】
2006087097.tif 000012
【図１１】
2006087097.tif 000013