(57)【要約】【課題】移動通信システムにおけるＰＤＣＰレイヤのパケットの通信について、当該レイヤでは検出できない異常を検出することを可能とする。【解決手段】ユーザ装置と基地局とを有する移動通信システムにおける前記基地局において、前記ユーザ装置から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備える。【選択図】図７
2016021726.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ装置と基地局とを有する移動通信システムにおける前記基地局であって、
前記ユーザ装置から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、
前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、
前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と
を備えることを特徴とする基地局。
【請求項２】
ユーザ装置と基地局とを有する移動通信システムにおける前記基地局であって、
前記ユーザ装置から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、
前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と
を備えることを特徴とする基地局。
【請求項３】
前記異常検出手段は、前記ＰＤＣＰレイヤのパケットが所定の受信ウィンドウ外で受信された回数をカウントし、当該回数が所定閾値を超えた場合に、当該ＰＤＣＰレイヤに異常が発生したことを検出する
ことを特徴とする請求項１又は２に記載の基地局。
【請求項４】
前記異常検出手段は、前記ユーザ装置において前記ＰＤＣＰレイヤのパケットのペイロードの秘匿処理に用いられた所定の値と、当該パケットのヘッダに基づいて前記所定の値として推定される値とが異なることを前記異常として検出する
ことを特徴とする請求項１ないし３のうちいずれか１項に記載の基地局。
【請求項５】
前記異常検出手段により前記異常が検出された場合に、前記所定の値を前記ユーザ装置と前記基地局との間で一致させるための制御を行う状態一致制御手段
を備えることを特徴とする請求項４に記載の基地局。
【請求項６】
ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、
前記基地局から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、
前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、
前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と
を備えることを特徴とするユーザ装置。
【請求項７】
ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、
前記基地局から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、
前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と
を備えることを特徴とするユーザ装置。
【請求項８】
前記異常検出手段は、前記ＰＤＣＰレイヤのパケットが所定の受信ウィンドウ外で受信された回数をカウントし、当該回数が所定閾値を超えた場合に、当該ＰＤＣＰレイヤに異常が発生したことを検出する
ことを特徴とする請求項６又は７に記載のユーザ装置。
【請求項９】
前記異常検出手段は、前記基地局において前記ＰＤＣＰレイヤのパケットのペイロードの秘匿処理に用いられた所定の値と、当該パケットのヘッダに基づいて前記所定の値として推定される値とが異なることを前記異常として検出する
ことを特徴とする請求項６ないし８のうちいずれか１項に記載のユーザ装置。
【請求項１０】
前記異常検出手段により前記異常が検出された場合に、前記所定の値を前記ユーザ装置と前記基地局との間で一致させるための制御を行う状態一致制御手段
を備えることを特徴とする請求項９に記載のユーザ装置。
【請求項１１】
ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、
前記基地局から所定の異常判定条件を受信する受信手段と、
前記基地局から受信するパケットに誤りがあるか否かを判定する誤り検出手段と、
前記誤り検出手段により誤りがあると判定されたパケットである誤りパケットの個数が前記所定の異常判定条件を満たす場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と、
前記基地局へ前記異常検出手段による検出を通知する通知手段と
を備えることを特徴とするユーザ装置。
【請求項１２】
前記所定の異常判定条件は、前記ＰＤＣＰレイヤにおける異常を検出するための閾値となる誤りパケットの個数を示す
ことを特徴とする請求項１１に記載のユーザ装置。
【請求項１３】
前記ＰＤＣＰレイヤにおける異常はＨＦＮ同期外れである
ことを特徴とする請求項１１又は１２に記載のユーザ装置。
【請求項１４】
前記受信手段は、ユーザ装置単位、ＲＬＣモード単位、又はベアラ単位で前記所定の異常判定条件を前記基地局から受信する
ことを特徴とする請求項１１ないし１３のうちいずれか１項に記載のユーザ装置。
【請求項１５】
前記受信手段は、ＲＬＣ−ＵＭベアラに対して用いるＰＤＣＰシーケンス番号のビット長として特定のビット長を受信することにより、暗黙的に前記所定の異常判定条件を受信する
ことを特徴とする請求項１１ないし１４のうちいずれか１項に記載のユーザ装置。
【請求項１６】
前記通知手段は、前記ユーザ装置が、前記ＰＤＣＰレイヤにおける異常を検出する能力を有することを示す能力情報を明示的又は暗黙的に前記基地局に通知する
ことを特徴とする請求項１１ないし１５のうちいずれか１項に記載のユーザ装置。
【請求項１７】
ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置が実行する異常検出方法であって、
前記基地局から所定の異常判定条件を受信する受信ステップと、
前記基地局から受信するパケットに誤りがあるか否かを判定する誤り検出ステップと、
前記誤り検出ステップにより誤りがあると判定されたパケットである誤りパケットの個数が前記所定の異常判定条件を満たす場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出ステップと、
前記基地局へ前記異常検出ステップによる検出を通知する通知ステップと
を備えることを特徴とする異常検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ等の移動通信システムにおいて、ユーザ装置と基地局との間のパケット通信の異常を検出する技術に関連するものである。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムでは、パケットベースの無線通信が利用される。このようなパケットベース無線通信では、無線通信のための各種機能を階層化された複数のレイヤが実行することによって、無線通信が実現される。ＬＴＥシステムでは、図１に示されるようなレイヤ構造により、ユーザ装置ＵＥと基地局ｅＮＢ間の無線通信を実現することが規定されている。図１に示されるように、ＰＨＹ（Ｐｈｙｓｉｃａｌ）レイヤ、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ、ＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤ及びＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤが使用される。
【０００３】
このうち、ＰＤＣＰレイヤは、その上位のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットの秘匿処理、改ざん検出及びヘッダ圧縮等の機能を提供している（非特許文献１）。秘匿処理及び改ざん検出には、ＨＦＮ（Ｈｙｐｅｒ  Ｆｒａｍｅ  Ｎｕｍｂｅｒ）とＰＤＣＰ  ＳＮ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）とから構成されるＣＯＵＮＴ値が利用される。
【０００４】
ＰＤＣＰ  ＳＮは、ＰＤＣＰレイヤからＲＬＣレイヤにＰＤＣＰパケットを送出する毎にインクリメントされ、例えば"０"から"４０９５"までの範囲のＰＤＣＰ  ＳＮが、ＰＤＣＰパケットに巡回的に付与される。例えば、シーケンス番号"４０９５"のＰＤＣＰパケットの次にＲＬＣレイヤに送出されるＰＤＣＰパケットには、シーケンス番号"０"が付与される。ＨＦＮは、ＰＤＣＰ  ＳＮが周回する毎にインクリメントされ、例えば"０"から"１０４８５７６"までの範囲のＨＦＮが用いられる。
【０００５】
ＣＯＵＮＴ値は、上位ビットにＨＦＮを有し、下位ビットにＰＤＣＰ  ＳＮを有するよう構成される。ＬＴＥシステムでは、ＨＦＮはＰＤＣＰパケットに付与されないため、パケットの受信側は、ＰＤＣＰ  ＰＤＵのヘッダ内のＰＤＣＰ  ＳＮに基づいてＨＦＮを決定（推定）する。
【０００６】
ＰＤＣＰレイヤの動作について概要を説明すると、送信側では、ＰＤＣＰエンティティが、上位レイヤから受信したパケット、すなわち、ＰＤＣＰ  ＳＤＵ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）に対して、ＣＯＵＮＴ値を用いて秘匿処理、改ざん検出及びヘッダ圧縮を実行し、ＰＤＣＰ  ＳＮをヘッダに付与してＰＤＣＰ  ＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）としてＲＬＣレイヤに送出する。
【０００７】
一方、受信側では、ＲＬＣ−ＡＭが指定されているＰＤＣＰエンティティは、図２に示されるように、受信したパケットの順序を補正するための受信ｗｉｎｄｏｗ（ウィンドウ）を管理する。ＬＴＥシステムでは、受信ウィンドウのサイズは、ＰＤＣＰ  ＳＮの上限値"４０９５"の１／２である２０４７に設定される。送信側から受信したパケットのＰＤＣＰ  ＳＮが受信ウィンドウの範囲内である場合、ＰＤＣＰエンティティは、現在の受信状況から当該パケットの解匿処理に用いるＨＦＮを推定し、推定したＨＦＮとヘッダのＰＤＣＰ  ＳＮとから構成されるＣＯＵＮＴ値に基づき受信したパケットのペイロード（ＰＤＣＰ  ＳＤＵ）に対して解匿処理を実行する。その後、ＰＤＣＰエンティティは、処理後のパケットを上位レイヤに送出し、受信ウィンドウを更新する。他方、送信側から受信したパケットのＰＤＣＰ  ＳＮが受信ウィンドウの範囲外である場合、ＰＤＣＰエンティティは、当該パケットを破棄する。
【０００８】
ＲＬＣ−ＵＭが指定されているＰＤＣＰエンティティは、上記ＲＬＣ−ＡＭとは異なり、受信ウィンドウを管理せず、最後に受信したＰＤＣＰ  ＰＤＵのＰＤＣＰ  ＳＮの値と、受信したＰＤＣＰ  ＰＤＵのＰＤＣＰ  ＳＮとの大小関係から、管理している（秘匿解除に用いる）ＨＦＮをインクリメントする必要があるかを判定し（具体的には、最後に受信したＰＤＣＰ  ＰＤＵのＰＤＣＰ  ＳＮ＞受信したＰＤＣＰ  ＰＤＵのＰＤＣＰ  ＳＮであるか否かを判定し）、必要に応じてＨＦＮをインクリメントしている。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】３ＧＰＰ  ＴＳ  ３６．３２３  Ｖ１１．２．０  （２０１３−０３）
【非特許文献２】ＲＦＣ３０９５
【非特許文献３】３ＧＰＰ  ＴＳ  ３６．３３１  Ｖ１２．１．０  （２０１４−０３）
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上記のように、ＰＤＣＰレイヤでは、送信側でＣＯＵＮＴ値を用いてパケットに秘匿処理を施し、受信側では、ＣＯＵＮＴ値を用いてパケットの解匿処理を行う。従って、秘匿処理に用いるＣＯＵＮＴ値と解匿処理に用いるＣＯＵＮＴ値とが同じでなければ、受信側で正しいデータを抽出することができない。
【００１１】
しかし、上述したように、ＣＯＵＮＴ値を構成するＨＦＮとＰＤＣＰ  ＳＮのうち、ＨＦＮは送信側から受信側に送信されず、受信側で推定するので、ＨＦＮのミスマッチが生じる可能性がある。例えば、パケットサイズが小さい場合には、非常に多数のＰＤＣＰ  ＰＤＵがＲＬＣレイヤで多重されるため、ＰＤＣＰ  ＳＮが周回し易い。その場合、例えばハンドオーバ（ＨＯ）もしくは再接続手順実行を契機に、送信側−受信側のＨＦＮにミスマッチが発生する可能性がある。或いは、大量のＰＤＣＰ  ＰＤＵが送信側エンティティで破棄される場合や、ＲＬＣ−ＵＭにおいてはＲＬＣ再送がなく、ｉｎ−ｓｅｑｕｅｎｃｅ  ｄｅｌｉｖｅｒｙが担保されないため、無線での大量欠落が発生するような場合においても同様にミスマッチが発生する。
【００１２】
図３は、ＨＯ／再接続手順においてＨＦＮのミスマッチが発生する場合の例を示している。一般に、ＨＯ／再接続手順完了時において、送信側は、ＨＯ／再接続手順起動時にＲＬＣレイヤで送達確認がとれていないパケットから送信を開始するが、受信側では、送信側での送達確認の有無にかかわらず受信処理を行う。
【００１３】
図３の例では、ＨＯ／再接続手順起動時に、送信側が４０９６個のＰＤＣＰ  ＰＤＵ（ＨＦＮ：０）を１つのＲＬＣ  ＰＤＵで送信するが、ＲＬＣ送達確認は未受信である。このとき、受信側では、４０９６個のＰＤＣＰ  ＰＤＵを受信し、ＨＦＮを０から１に更新する。
【００１４】
ＨＯ／再接続手順完了時において、送信側は、ＲＬＣ送達確認未受信であるＨＦＮ：０．ＳＮ：０のＰＤＣＰ  ＰＤＵから送信を開始する。一方、受信側では、ＳＮ：０のＰＤＣＰ  ＰＤＵからパケットを受信するが、ＨＦＮは１とする。つまり、送信側と受信側との間にＨＦＮのミスマッチが生じる。この場合、受信側の解匿処理が失敗し、正しいパケットを得ることができないため、スループットの低下が生じる可能性がある。
【００１５】
また、ＨＯ／再接続手順以外において、例えば、送信側で所定の破棄契機により、連続的にパケットの破棄が生じると、送信側でＨＦＮがインクリメントされるが、受信側ではＨＦＮがインクリメントされずにＨＦＮのミスマッチが生じる場合もある。この場合も受信側の解匿処理が失敗し、正しいパケットを得ることができないため、スループットの低下が生じる可能性がある。
【００１６】
なお、これまではＰＤＣＰ  ＳＮ  ｓｐａｃｅで表現できるＳＮが０−４０９５のケースを例に説明したが、ＲＬＣ−ＵＭの場合には、ＰＤＣＰヘッダのオーバヘッド削減の観点で、より短いＰＤＣＰ  ＳＮ長（Ｓｈｏｒｔ  ＰＤＣＰ  ＳＮ  ｌｅｎｇｔｈ）を用いることが可能である。しかし、前述の内容から類推できるように、ＰＤＣＰ  ＳＮ  ｓｐａｃｅが小さい程ＨＦＮのミスマッチは発生しやすい。
【００１７】
上記のようなＨＦＮのミスマッチはＨＦＮ  ｄｅ−ｓｙｎｃ（送信側と受信側間で同期が外れていることであり、ＨＦＮ同期外れとも称する）と呼ばれる。ＨＦＮ  ｄｅ−ｓｙｎｃが発生した場合、ＰＤＣＰレイヤでは、これを検出することができない。例えば、ユーザ装置ＵＥが受信側である場合において上記のようなＨＦＮ  ｄｅ−ｓｙｎｃが発生した場合、ユーザ装置ＵＥのユーザがこれを認識して再発信を行わない限り、誤ったＣＯＵＮＴ値で解匿されたＩＰパケットが継続して受信されることとなり、サービス観点はもとより、課金観点やリソース利用効率観点からも、そのような通信を継続することは望ましくない。
【００１８】
本発明は上記の点に鑑みてなされたものであり、移動通信システムにおけるＰＤＣＰレイヤのパケットの通信について、当該レイヤでは検出できない異常を検出することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明の実施の形態によれば、ユーザ装置と基地局とを有する移動通信システムにおける前記基地局であって、
前記ユーザ装置から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、
前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、
前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備える基地局が提供される。
【００２０】
また、本発明の実施の形態によれば、ユーザ装置と基地局とを有する移動通信システムにおける前記基地局であって、
前記ユーザ装置から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、
前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備える基地局が提供される。
【００２１】
また、本発明の実施の形態によれば、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、
前記基地局から受信する受信パケットのサイズに基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、
前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、
前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備えるユーザ装置が提供される。
【００２２】
また、本発明の実施の形態によれば、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、前記基地局から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備えるユーザ装置が提供される。
【００２３】
また、本発明の実施の形態によれば、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、
前記基地局から所定の異常判定条件を受信する受信手段と、
前記基地局から受信するパケットに誤りがあるか否かを判定する誤り検出手段と、
前記誤り検出手段により誤りがあると判定されたパケットである誤りパケットの個数が前記所定の異常判定条件を満たす場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と、
前記基地局へ前記異常検出手段による検出を通知する通知手段とを備えるユーザ装置が提供される。
【００２４】
また、本発明の実施の形態によれば、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置が実行する異常検出方法であって、
前記基地局から所定の異常判定条件を受信する受信ステップと、
前記基地局から受信するパケットに誤りがあるか否かを判定する誤り検出ステップと、
前記誤り検出ステップにより誤りがあると判定されたパケットである誤りパケットの個数が前記所定の異常判定条件を満たす場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出ステップと、
前記基地局へ前記異常検出ステップによる検出を通知する通知ステップとを備える異常検出方法が提供される。
【発明の効果】
【００２５】
本発明の実施の形態によれば、移動通信システムにおけるＰＤＣＰレイヤのパケットの通信について、当該レイヤでは検出できない異常を検出することを可能とする技術が提供される。
【図面の簡単な説明】
【００２６】
【図１】ＬＴＥにおける無線インタフェースプロトコルのレイヤ構造を示す図である。
【図２】ＰＤＣＰレイヤの基本的な動作を説明するための図である。
【図３】ＨＦＮのミスマッチの例を説明するための図である。
【図４】本発明の実施の形態に係る移動通信システムの構成図である。
【図５】ＲＯＨＣを説明するための図である。
【図６】ＲＯＨＣパケットの構成を示す図である。
【図７】本発明の実施の形態におけるＨＦＮ  ｄｅ−ｓｙｎｃ検出方法例を説明するための図である。
【図８】ＩＲパケットとＰＤＣＰ  ＰＤＵとの関係を説明するための図である。
【図９】エラーパケット数の閾値を通知するシグナリングシーケンスを示す図である。
【図１０】ＵＥ単位でエラーパケット数の閾値を通知する場合の３ＧＰＰ仕様書の変更例を示す図である。
【図１１】ＲＬＣモード単位でエラーパケット数の閾値を通知する場合の３ＧＰＰ仕様書の変更例を示す図である。
【図１２】ベアラ単位でエラーパケット数の閾値を通知する場合の３ＧＰＰ仕様書の変更例を示す図である。
【図１３】ＵＥ能力を通知するシグナリングシーケンスを示す図である。
【図１４】ＰＤＣＰ状態一致制御例を説明するための図である。
【図１５】ＰＤＣＰ状態一致制御例を説明するための図である。
【図１６】ＰＤＣＰ状態一致制御例を説明するための図である。
【図１７】基地局ｅＮＢの機能構成図である。
【図１８】基地局ｅＮＢの動作例を示すフローチャートである。
【図１９】ユーザ装置ＵＥの機能構成図である。
【図２０】ユーザ装置ＵＥの動作例を示すフローチャートである。
【発明を実施するための形態】
【００２７】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る移動通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのリリース８、又は９に対応する通信方式のみならず、３ＧＰＰのリリース１０、１１、又は１２もしくはそれ以降に対応する通信方式も含む広い意味で使用する。
【００２８】
また、本実施の形態では、後述するように、ＰＤＣＰ  ＰＤＵにおける異常（ＨＦＮ  ｄｅ−ｓｙｎｃ）を、それよりも上位レイヤのパケットであるＩＲパケットのＣＲＣに基づき検出することとしているが、これは例であり、これに限定されない。上位レイヤのパケットとしてＩＲパケット以外のパケット（例：ＵＤＰパケット）を用いてもよいし、異常検出対象の下位レイヤのパケットもＰＤＣＰ  ＰＤＵに限られるわけではない。
【００２９】
（システム構成）
図４に、本発明の実施の形態に係る移動通信システムの構成図を示す。図４に示すように、本実施の形態に係る移動通信システムは、セルを形成する基地局ｅＮＢと、セルに在圏して基地局ｅＮＢと無線通信を行うユーザ装置ＵＥを含む。図４には、基地局ｅＮＢとユーザ装置ＵＥが１台ずつ示されているが、これらは代表を示しており、それぞれ複数であってもよい。本実施の形態では、当該移動通信システムは、少なくともＬＴＥに準拠した動作が可能である。すなわち、無線インターフェースプロトコルとしてＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰ、ＲＲＣ等を使用して通信を行う。
【００３０】
また、本実施の形態では、ＲＯＨＣ（ＲＯｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ、非特許文献２）の技術を適用してパケットのヘッダ圧縮を行うこととしている。ただし、本発明においてＲＯＨＣを適用することは必須ではなく、ＲＯＨＣを適用しなくても本発明を実施することは可能である。以下ではまず、ＲＯＨＣについて説明する。
【００３１】
（ＲＯＨＣについて）
ＩＰベースのネットワークで音声通信を行う場合に送受信される音声パケットは、ペイロードに対するＲＴＰ／ＵＤＰ／ＩＰヘッダの割合が多く、リソース利用効率やカバレッジの観点で懸念がある。そこで、ＬＴＥで音声通信を行う方式（ＶｏＬＴＥ）においては、ＰＤＣＰレイヤで音声パケットにＲＯＨＣによるヘッダ圧縮を適用することが想定されている。ＲＯＨＣでは、ＲＴＰ／ＵＤＰ／ＩＰヘッダフィールドの内で、パケット間で変化のある部分のみを送信することで、実際に無線で送信するビット数を低減している。
【００３２】
例えば、変化しないフィールド（Ｓｔａｔｉｃ  ｐａｒｔ）として、ＳＳＲＣ（ＲＴＰレイヤの識別子）、ＩＰアドレス等があり、変化するフィールド（ｄｙｎａｍｉｃ  ｐａｒｔ）として、ＲＴＰ  ｔｉｍｅｓｔａｍｐやＲＴＰ−Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ、ＵＤＰ  ｃｈｅｃｋｓｕｍ等がある。図５に示すように、ほぼ変化しないフィールドを圧縮することで、ヘッダのビット数を大幅に削減することができる。
【００３３】
ＲＯＨＣを実行する装置は、例えば各ＲＴＰセッション（パケットストリーム）の変化パターンを記憶し、当該変化パターンに基づいてパケットのヘッダを圧縮／復元する。この変化パターンはコンテクストと呼ばれる。
【００３４】
ＲＯＨＣが行われる場合のヘッダ圧縮を行う側（例：下りでの基地局ｅＮＢ、上りでのユーザ装置ＵＥ）をＣｏｍｐｒｅｓｓｏｒと呼び、圧縮されたヘッダを復元する側（例：上りでの基地局ｅＮＢ、下りでのユーザ装置ＵＥ）をＤｅｃｏｍｐｒｅｓｓｏｒと呼ぶ。
【００３５】
ＲＯＨＣにおいてＣｏｍｐｒｅｓｓｏｒからＤｅｃｏｍｐｒｅｓｓｏｒに送信されるパケット（ＲＯＨＣパケット）の基本的な構成を図６に示す。図６に示すように、ＲＯＨＣパケットは、少なくともＲＯＨＣヘッダとペイロードを有する。例えば圧縮／復元が行われている状態において、ＲＯＨＣヘッダには、ＲＴＰ／ＩＰ／ＵＤＰヘッダの圧縮後の情報が含まれる。ペイロードには、例えばＲＴＰペイロードが含まれる。
【００３６】
ＲＯＨＣでは、上記の圧縮／復元を可能とするために、まずはＣｏｍｐｒｅｓｓｏｒからＤｅｃｏｍｐｒｅｓｓｏｒに対して、圧縮していないヘッダの全ての情報を送信する初期化／リフレッシュ処理が行われる。このときの状態は、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  ａｎｄ  Ｒｅｆｒｅｓｈ（ＩＲ）  ｓｔａｔｅと呼ばれ、この状態のときに送信されるＲＯＨＣパケットをＩＲパケットと呼ぶ。ＩＲパケットにより初期化／リフレッシュ処理が行われ、コンテクストが確立された後に、圧縮／復元を行う状態に移行するのである。
【００３７】
ＩＲパケットは、Ｓｔａｔｉｃ  ｐａｒｔ（例：ＩＰ  ａｄｄｒｅｓｓ）、Ｄｙｎａｍｉｃ  ｐａｒｔ（例：ＲＴＰ  ＳＮ／ＴＳ）等の基本的にＲＴＰ／ＵＤＰ／ＩＰヘッダの全フィールドを送信できる最大パケットである。ただし、Ｄｙｎａｍｉｃ  ｐａｒｔ等を省くことは可能である。ＩＲパケットのヘッダ（ＩＲヘッダ）には、当該Ｓｔａｔｉｃ  ｐａｒｔ等のヘッダの内容を含むボディ（Ｂｏｄｙ）部がある。また、ＩＲパケットはＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）値を含み、ＩＲパケットの受信側は、ＣＲＣ値のチェックにより誤り検出を行うことが可能である。ＣＲＣは、ビット列のデータをある生成多項式で割った余りを検査用のＣＲＣ符号（誤り検査値）としてデータに付加して送信し、受信側は、受信したデータが同じ生成多項式で割り切れるか否かで誤りの発生を検出するものである。ＣＲＣは誤り検査方式の一例であり、本発明において誤り検査方式はＣＲＣに限られない。
【００３８】
なお、ＲＯＨＣパケットとしては、ＩＲパケットの他に、ＩＲ−ＤＹＮパケット、パケットタイプ０、パケットタイプ１、パケットタイプ２等がある。これらのうち、Ｓｔａｔｉｃ  ｐａｒｔ等を圧縮せずに送信するＩＲパケットが最大のサイズのパケットとなる。
【００３９】
（ＨＦＮ  ｄｅ−ｓｙｎｃの検出方法）
本実施の形態では、一例として、上記ＣＲＣによるＩＲパケットの誤り検出を行うことで、ＩＲパケットよりも下位レイヤのパケットであるＰＤＣＰ  ＰＤＵに関するＨＦＮ  ｄｅ−ｓｙｎｃの有無の検出を行うこととしている。以下、その方法を図７を参照して説明する。
【００４０】
図７に示す例では、Ｃｏｍｐｒｅｓｓｏｒを送信装置１０とし、Ｄｅｃｏｍｐｒｅｓｓｏｒを受信装置２０としている。送信装置１０は、上りでのユーザ装置ＵＥもしくは下りでの基地局ｅＮＢに相当する。受信装置２０は、下りでのユーザ装置ＵＥもしくは上りでの基地局ｅＮＢに相当する。
【００４１】
図７の例において、送信装置１０から受信装置２０へのデータ送信には、ＲＯＨＣが適用されており、送信装置１０から受信装置２０へ送信されるデータ（パケット）には、初期化のためのＩＲパケット、圧縮／復元を行うタイプ０のパケット等、種々のパケットが存在する。
【００４２】
各種パケットを受信する受信装置２０は、受信する各種パケットのうちのＩＲパケットのＣＲＣのＮＧ回数をカウントする（ステップ１０１）。
【００４３】
受信装置２０は、各種のパケットからＩＲパケットを判別する必要がある。ＩＲパケットを判別する方法は特定の方法に限定されないが、本実施の形態においては、以下のようにして、当該パケットがＩＲパケットか否かを判定する。
【００４４】
本実施の形態では、受信装置２０は、受信したＰＤＣＰ  ＰＤＵ（又はＰＤＣＰ  ＳＤＵ）のサイズを計測し、所定閾値以上のサイズであれば、受信したパケット（ＰＤＣＰ  ＳＤＵ）はＩＲパケットであると判定する。図８に、ＩＲパケットとＰＤＣＰ  ＰＤＵとの関係例を示す。図８に示すように、ＣＲＣ値を含むＩＲパケットに秘匿処理等が施されてＰＤＣＰ  ＳＤＵとなり、ヘッダ（Ｈ）が付されることによりＰＤＣＰ  ＰＤＵとなる。ＰＤＣＰ  ＰＤＵ（又はＰＤＣＰ  ＳＤＵ）のサイズが大きい場合、収容されるパケットのサイズも大きく、それはＩＲパケットであると推測できる。
【００４５】
ただし、実音声と背景雑音とではパケットサイズ（ＲＴＰペイロードサイズ）が異なるため、ＩＲパケットを受信したか否かを判定するための上記所定閾値は、実音声が流れているかどうかを示すパラメータであるＴａｌｋ  ｓｐｕｒｔ＝ＯＮ／ＯＦＦで異なる値を用いてもよい。Ｔａｌｋ  ｓｐｕｒｔ＝ＯＮであれば、ＯＦＦの場合よりも大きな所定閾値を使用する。なお、受信装置２０は、送受信するパケットサイズ等により、Ｔａｌｋ  ｓｐｕｒｔをＯＮ／ＯＦＦする機能を有するものとする。
【００４６】
図７のステップ１０１において、受信装置２００は、ＩＲパケットを受信したと判定した場合に、当該パケットに対してＣＲＣの演算（誤り検査）を行って、ＣＲＣがＯＫかＮＧかを判定し、ＮＧ回数をカウントする。ＣＲＣ等の判定がＮＧとなった誤りのあるパケットをエラーパケットと呼ぶ。
【００４７】
ステップ１０２において、受信装置２０は、ＣＲＣのＮＧ回数（エラーパケットの個数）が所定閾値を超過したか否かを判定し、超過していない場合（ステップ１０２のＮｏ）はステップ１０１に戻る。超過している場合（ステップ１０２のＹｅｓ）はステップ１０３に進み、受信装置２０は、ＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判断する。
【００４８】
所定閾値を超過する前にＩＲパケットのＣＲＣがＯＫとなる場合には、ＣＲＣのＮＧ回数をリセットし（０にする）、最初からカウントを行う。このように連続的にエラーパケットをカウントすることの他、ＣＲＣがＯＫとなってもＮＧ回数をリセットせず、エラーパケットの数を加算していき、エラーパケット数が閾値を超過した場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判断してもよい。また、受信したｎ個のＩＲパケットのうち、所定閾値を超える数のエラーパケットを検出した場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判断してもよい。これらのカウント方法のバリエーションは、ＩＲパケットのＣＲＣ以外の方法でエラーパケット判定を行う場合にも同様に適用される。
【００４９】
なお、ＣＲＣのＮＧ回数をカウントし、ＣＲＣのＮＧ回数が所定閾値を超過するか否かの判断は、所定期間内で行うこととしてよい。つまり、ＣＲＣのＮＧ回数が所定閾値を超過しないまま所定期間が経過する度に、ＣＲＣのＮＧ回数をリセットし（０にする）、最初からカウントを行うこととしてよい。
【００５０】
所定期間（比較的短い期間）内に所定閾値（比較的多い回数）を超過する回数のＣＲＣのＮＧが発生することは、より低位レイヤの異常であるＨＦＮ  ｄｅ−ｓｙｎｃが発生し、ＩＲパケットの再送等によってもＣＲＣの正常性を回復できていないと考えられることから、所定期間内に所定閾値を超過する回数のＣＲＣのＮＧが発生した場合に、ＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判断している。
【００５１】
エラーパケットの検出数に係る上記の所定閾値は、ユーザ装置ＵＥもしくは基地局ｅＮＢの処理遅延やＭＡＣの再送超過率、ＢＬＥＲや干渉等に基づいて算出されてもよい。
【００５２】
また、当該所定閾値は、対象とするパケットのベアラ（パケットの論理的通信路）毎の値を用いることとしてもよく、当該閾値は、例えば、ユーザ装置ＵＥがＤｅｃｏｍｐｒｅｓｓｏｒである場合には、基地局ｅＮＢからＲＲＣシグナリング等で通知するものを用いることができる。ＲＲＣシグナリングについての詳細は後述する。
【００５３】
閾値の大きさに関しては、例えば、音声通信の場合には、早期にＨＦＮ  ｄｅ−ｓｙｎｃを回復することが望ましいため、ＮＧ回数閾値を小さくし、ベストエフォート型のサービスの場合には、音声通信の場合よりも大きなＮＧ回数閾値とすることが考えられる。
【００５４】
受信装置２０は、図７のステップ１０３でＨＦＮ  ｄｅ−ｓｙｎｃ発生を検出すると、ＨＦＮ  ｄｅ−ｓｙｎｃを解消するために、ＰＤＣＰ状態一致のための制御を行う（ステップ１０４）。
【００５５】
上記の例では、エラーパケットの数として、ＩＲパケットのＣＲＣのＮＧ回数をカウントすることとしたが、これは一例に過ぎない。その他のパケットについてもＮＧ回数をカウントしてもよい。
【００５６】
例えば、ＣＲＣの付与されているその他のＲＯＨＣパケット（例：ＵＯ−０等）についてＣＲＣのＮＧ回数をカウント対象としてもよい。この場合、受信装置２０は、解匿処理後のパケットにおけるＲＯＨＣのＰａｃｋｅｔ  ｔｙｐｅを示すフィールドの値に基づき、当該パケットがＣＲＣの付与されているその他のＲＯＨＣパケットであるかどうかを判定し、ＣＲＣの付与されているその他のＲＯＨＣパケットである場合に、ＣＲＣチェックを行って、ＮＧ回数をカウントする。Ｐａｃｋｅｔ  ｔｙｐｅを示すフィールドを使用すること以外、ＮＧ回数判定に係る処理内容は図７で説明したものと同じである。本例では、Ｐａｃｋｅｔ  ｔｙｐｅを示すフィールドの値は正しく、その他のフィールドやデータ部分が正しくなくなる場合を想定している。
【００５７】
ＣＲＣ  ＮＧ要因が送信側と受信側との間でＲＯＨＣコンテクストが不一致になったことではなく、不正な秘匿解除処理によるものである場合、本パケットをカウントしておくことにより、早期に通信を復帰することが可能である。なお、本カウントはＲＯＨＣが適用されているベアラ（例：音声通信）に対してのみ適用されてもよい。
【００５８】
また、他の例として、特定のフィールドが不正な値であるパケットについてもＮＧカウント対象としてもよい。例えば、受信装置２０は、解匿処理後のパケットに対して、予め定めた特定のフィールド（例：ＣＩＤフィールド）に対応するビット位置の値が、取り得る値（例：１〜１５）の範囲にない場合にＮＧ判定を行って、ＮＧ回数をカウントする。ＣＲＣと特定フィールドチェックとの違いを除いて、ＮＧ回数判定に係る処理内容は図７で説明したものと同じである。
【００５９】
特定のフィールドとは、例えば、上記のようにコンテクストの識別子を示すＣＩＤフィールドでもよいし、Ｐａｃｋｅｔ  ｔｙｐｅ  ｆｉｅｌｄ（ＲＯＨＣパケットのフォーマットタイプを示すフィールド）であってもよい。
【００６０】
また、エラー判定の対象とするパケットはＲＯＨＣパケットに限られるわけではない。エラー判定の対象とするパケットを、ＩＰパケット、ＵＤＰパケット、もしくはＲＴＰパケットとし、当該パケットのヘッダ内の特定のフィールドに不正値（例：取り得ない値）が入っている場合に当該パケットは、誤りのあるエラーパケットであると判定し、ＮＧ回数をカウントすることとしてもよい。この手法では、受信パケットがＩＲパケットか否かの判定は不要であり、また、この手法は、ＲＯＨＣが適用されていない場合でも使用することができる。
【００６１】
すなわち、不正な解匿処理により出力されたＰＤＣＰ  ＳＤＵは、基本的にランダムなビット列になるため、正常な圧縮ヘッダのヘッダフィールドでは取り得ない値が設定されている可能性があり、下位レイヤの残留誤りがある程度小さい想定の場合には、本事象はＨＦＮ  ｄｅ−ｓｙｎｃによるものであることいえる。これにより、実際にｄｅｃｏｍｐｒｅｓｓｉｏｎを行わずともＨＦＮ  ｄｅ−ｓｙｎｃを早期に検出することが可能である。なお、本例についても、ＲＯＨＣが適用されているベアラに対してのみ適用することとしてもよい。
【００６２】
特定のフィールドのチェックにより、ＨＦＮ  ｄｅ−ｓｙｎｃを検出する受信装置２０は、送信装置１０から順次受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備える。
【００６３】
更に、ＲＬＣ−ＡＭベアラの場合、ＰＤＣＰの受信ウィンドウ外で受信されたＰＤＣＰ  ＰＤＵについてもＮＧカウント対象とされてもよい。すなわち、受信装置２０は、ＲＬＣ−ＡＭベアラの通信を行う場合において、ＰＤＣＰの受信ウィンドウ外で受信されたＰＤＣＰ  ＰＤＵをＮＧとしてカウントし、ＮＧ回数が所定閾値を超過した場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定する。ここでの処理内容は、図７に示す処理において、「ＩＲパケットのＣＲＣのＮＧ回数」を、「ＰＤＣＰの受信ウィンドウ外でＰＤＣＰ  ＰＤＵを受信した回数」に置き換えたものに相当する。
【００６４】
前述したように、ＲＬＣ−ＡＭでは受信側ＰＤＣＰエンティティにおいて受信ウィンドウを管理し、ウィンドウ外のＰＤＣＰ  ＳＮを持つＰＤＣＰ  ＰＤＵを破棄している。仮に多数のＰＤＣＰ  ＰＤＵがウィンドウ外で受信される場合、送信側において受信ウィンドウ内のＰＤＣＰ  ＳＮを持つＰＤＣＰ  ＰＤＵが既に破棄されていることが想定される。そのため、次に受信ウィンドウ内にＰＤＣＰ  ＰＤＵを受信する際には既に送信側ＨＦＮは周回していることが想定される。よって、本例は、先の例にあるように実際にｄｅｃｏｍｐｒｅｓｓｉｏｎに基づくＣＲＣ  ＮＧを検出するよりも早期にＨＦＮ  ｄｅ−ｓｙｎｃの発生を予期し、早期に復帰することが可能である。本カウント自体はＲＬＣ−ＡＭに対してのみ実施されてもよいし、モードを区別せずに実施してもよい。
【００６５】
ＰＤＣＰ受信ウィンドウ外受信回数によりＨＦＮ  ｄｅ−ｓｙｎｃを検出する受信装置２０は、送信装置１０から順次受信するＰＤＣＰレイヤのパケットが所定の受信ウィンドウ外で受信された回数をカウントし、当該回数が所定閾値を超えた場合に、当該ＰＤＣＰレイヤに異常が発生したことを検出する異常検出手段を備える。
【００６６】
なお、これまでに説明した４種類の方法（ＩＲパケットＣＲＣ、ＩＲ以外ＲＯＨＣパケットＣＲＣ、特定フィールドチェック、ウィンドウ外受信）は、そのいずれか１つを実施することとしてよい。また、複数（全部を含む）を実施し、ＮＧカウント値の合計が所定閾値を超えた場合にＨＦＮ  ｄｅ−ｓｙｎｃであると判定してもよい。この場合、単一のカウンタを持つことに相当する。また、複数（全部を含む）を実施し、個別のカウンタ（即ち、カウント対象種別毎、或いはその組み合わせ毎のカウンタ）が用いられて、いずれかのカウンタが閾値を超過した場合に、ＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定してもよい。また、カウンタの管理方法はベアラ（パケットの論理的通信路）毎に異なっていても良いし、ＤＬ／ＵＬで異なっていても良い。
【００６７】
（エラーパケット検出数の閾値を通知するシグナリング等を行う例）
上述した手法によって、ユーザ装置ＵＥがＨＦＮ  ｄｅ−ｓｙｎｃ検出を行う場合において、ＨＦＮ  ｄｅ−ｓｙｎｃ検出判断のためのエラーパケット検出数の閾値を各ユーザ装置ＵＥが任意に設定してしまうと、ユーザ装置ＵＥ毎にＨＦＮ  ｄｅ−ｓｙｎｃ検出までのパフォーマンスが異なってしまい、ＮＷが意図したパフォーマンスを実現することができない可能性がある。
【００６８】
そこで、本例では、図９に示すように、ＨＦＮ  ｄｅ−ｓｙｎｃ検出判定のためのエラーパケット検出数の閾値（異常判定条件）をＲＲＣシグナリングにより基地局ｅＮＢからユーザ装置ＵＥに通知し（ステップ１１０１）、当該通知を受けたユーザ装置ＵＥは、通知された閾値を用いてＨＦＮ  ｄｅ−ｓｙｎｃ検出を行う。閾値を用いたＨＦＮ  ｄｅ−ｓｙｎｃ検出の方法自体はこれまでに説明したとおりである。
【００６９】
通知の単位としては、ユーザ装置ＵＥ単位でもよいし、ＲＬＣモード単位でもよいし、ベアラ単位でもよい。ただし、ＲＬＣモード単位の場合には、ＲＬＣ−ＡＭとＲＬＣ−ＵＭが対象となりＲＬＣ−ＴＭは対象外である。また、ベアラ単位で通知を行う際には、ＲＯＨＣを適応しているベアラのみを対象としてもよい。
【００７０】
シグナリングメッセージの中には、ＨＦＮ  ｄｅ−ｓｙｎｃであると判定する閾値となるエラーパケット検出数が少なくとも含まれる。既に説明したように、ユーザ装置ＵＥは、当該閾値を超える（もしくは当該閾値以上の）数のエラーパケットを検出した場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定する。
【００７１】
また、シグナリングメッセージの中に、ＨＦＮ  ｄｅ−ｓｙｎｃ検出を行うか否かを指定するＯＮ／ＯＦＦの情報を含めてもよい。つまり、「ＯＮ／ＯＦＦ＋閾値」という形の情報を異常判定条件として通知してもよい。また、閾値のみが異常判定条件として通知されてもよい。閾値のみを通知する場合には、閾値として０もしくはＩｎｆｉｎｉｔｙ（無限大）が指定されることでＯＦＦが通知されてもよい。
【００７２】
また、「連続ｋ個のエラーパケットを検出した場合にＨＦＮ  ｄｅ−ｓｙｎｃ発生と判定する」、「離散的でもよいからｋ個のエラーパケットを検出した場合にＨＦＮ  ｄｅ−ｓｙｎｃ発生と判定する」、「受信したｎ個のパケットのうち、ｋ個のエラーパケットを検出した場合のＨＦＮ  ｄｅ−ｓｙｎｃ発生と判定する」等のように、ＨＦＮ  ｄｅ−ｓｙｎｃ発生判定方法を指定する情報を異常判定条件としてシグナリングメッセージの中に含めてもよい。
【００７３】
図１０に、ユーザ装置ＵＥ単位でエラーパケット検出数の閾値を通知する場合における３ＧＰＰ仕様書（非特許文献３）の変更例を示す。なお、図１０は、仕様書の該当箇所の抜粋であり、下線を引いた部分が新たに追加される内容を示す。この点は図１１、図１２も同様である。
【００７４】
図１０（ａ）に示すとおり、「ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄ  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ」において、「ｎｕｍＨＦＮｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎ−ｒ１２」が追加される。図１０（ｂ）において説明されているとおり、「ｎｕｍＨＦＮｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎ−ｒ１２」は、ネットワーク（Ｅ−ＵＴＲＡＮ）への通知をトリガし得るエラーパケットの（連続的な）検出数を示す。
【００７５】
図１１に、ＲＬＣモード単位でエラーパケット検出数の閾値を通知する場合における３ＧＰＰ仕様書（非特許文献３）の変更例を示す。
【００７６】
図１１（ａ）に示すとおり、「ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄ  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ」において、「ＨＦＮ−ｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎＰａｒａｍｅｔｅｒ−ｒ１２」が追加される。「ＨＦＮ−ｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎＰａｒａｍｅｔｅｒ−ｒ１２」は、ＲＬＣ−ＡＭでの閾値を示す「ｎｕｍＨＦＮｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎＡＭ−ｒ１２」、及びＲＬＣ−ＵＭでの閾値を示す「ｎｕｍＨＦＮｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎＵＭ−ｒ１２」を含む。図１１（ｂ）において説明されているとおり、「ＨＦＮ−ｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎＰａｒａｍｅｔｅｒ−ｒ１２」は、対応するＲＬＣモードにおける無線ベアラのＨＦＮ  ｄｅ−ｓｙｎｃを検出するために使用されるパラメータを示す。
【００７７】
図１２に、ベアラ単位でエラーパケット検出数の閾値を通知する場合における３ＧＰＰ仕様書（非特許文献３）の変更例を示す。
【００７８】
図１２（ａ）に示すとおり、「ＰＤＣＰ−Ｃｏｎｆｉｇ  ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ」において、「ｎｕｍＨＦＮｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎ−ｒ１２」が追加される。図１２（ｂ）において説明されているとおり、「ｎｕｍＨＦＮｄｅｓｙｎｃＤｅｔｅｃｔｉｏｎ−ｒ１２」は、該当ベアラにおけるＨＦＮ  ｄｅ−ｓｙｎｃの検出をトリガする、当該ベアラにおけるエラーパケットの（連続的な）検出数を示す。
【００７９】
上述したように基地局ｅＮＢからＲＲＣシグナリングを受信し、当該ＲＲＣシグナリングにより通知される閾値に基づいてＨＦＮ  ｄｅ−ｓｙｎｃ検出を行い、検出したことを基地局ｅＮＢに通知するユーザ装置ＵＥは、前記基地局から所定の異常判定条件を受信する受信手段と、前記基地局から受信するパケットに誤りがあるか否かを判定する誤り検出手段と、前記誤り検出手段により誤りがあると判定されたパケットである誤りパケットの個数が前記所定の異常判定条件を満たす場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と、前記基地局へ前記異常検出手段による検出を通知する通知手段とを有する。
【００８０】
＜変形例＞
ところで、ＲＬＣ−ＵＭベアラの場合には、当該ベアラに対して用いるＰＤＣＰ  ＳＮのビット長として、１２ｂｉｔと７ｂｉｔから基地局ｅＮＢが選択してユーザ装置ＵＥに指示することが規定されている（非特許文献３におけるｐｄｃｐ−ＳＮ−Ｓｉｚｅ、図１２（ｂ）にも示されている）。なお、ＰＤＣＰ  ＳＮの長さが１２ｂｉｔであれば、バルクパケットロスに対する耐性は強くなるが、ＰＤＣＰヘッダが１ｂｙｔｅ増えるため、オーバヘッドが増える。一方、ＰＤＣＰ  ＳＮの長さが５ｂｉｔであれば、オーバヘッドの増加は回避できるが、バルクパケットロスに対する耐性は弱くなる。
【００８１】
本例では、ユーザ装置ＵＥにＲＬＣ−ＵＭのベアラが設定される場合において、ユーザ装置ＵＥが基地局ｅＮＢからＰＤＣＰ  ＳＮの長さとして、「１２ｂｉｔ」の指示を受信した場合、ユーザ装置ＵＥは、ＨＦＮ  ｄｅ−ｓｙｎｃ検出判断のためのエラーパケット検出数の閾値として「１」を設定する。すなわち、１つでもエラーパケットを検出した場合に、ＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判断される。なお、エラーパケット数が閾値を超えた場合にＨＦＮ  ｄｅ−ｓｙｎｃ発生と判定する場合においては、当該閾値は「０」であってもよい。これらは実質的に同じであり、要するに、１つでもエラーパケットを検出した場合に、ＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判断されればよい。
【００８２】
「１２ｂｉｔ」の指示を受信したことによる上記閾値の設定は、ユーザ装置ＵＥがＨＦＮ  ｄｅ−ｓｙｎｃ検出を行う場合（例：基地局ｅＮＢから本機能ＯＮの指示を受けた場合）にのみ行うこととしてもよい。本例では、エラーパケット検出数の閾値はｅｘｐｌｉｃｉｔに通知されず、ＰＤＣＰ  ＳＮの長さ「１２ｂｉｔ」としてＩｍｐｌｉｃｉｔに通知されるのである。
【００８３】
なお、ＰＤＣＰ  ＳＮの長さ「１２ｂｉｔ」の通知と、エラーパケット検出数の閾値のｅｘｐｌｉｃｉｔの通知の両方があった場合には、ｅｘｐｌｉｃｉｔの通知に従ってもよいし、ＰＤＣＰ  ＳＮの長さ「１２ｂｉｔ」（閾値「１」）に従ってもよいし、どちらに従うかを基地局ｅＮＢからユーザ装置ＵＥに通知し、当該通知に従うこととしてもよい。ＰＤＣＰ  ＳＮの長さ「１２ｂｉｔ」の場合に、閾値「１」とする理由は以下のとおりである。
【００８４】
ＰＤＣＰ  ＳＮの長さが７ｂｉｔである場合には、１２８個のパケットロスによりＨＦＮ  ｄｅ−ｓｙｎｃが発生するが、この程度のロスは、一時的な品質劣化により生じた可能性が高く、通信を継続しても、その後復帰できる可能性もある。よって、エラーパケット検出数の閾値としていくらかマージンを見込んでもよい。一方、ＰＤＣＰ  ＳＮの長さが１２ｂｉｔである場合には、４０９６個のパケットロスによりＨＦＮ  ｄｅ−ｓｙｎｃが発生するが、これは一時的な要因ではなく、無線での何らかの異常が発生した可能性が高いため、すぐにでも状態一致を図るための動作（例：ＨＦＮ  ｄｅ−ｓｙｎｃをｅＮＢへ報告）を行ったほうがよい。このような理由から、本例では、ユーザ装置ＵＥが基地局ｅＮＢからＰＤＣＰ  ＳＮの長さとして、「１２ｂｉｔ」の指示を受信した場合、ユーザ装置ＵＥは、ＨＦＮ  ｄｅ−ｓｙｎｃ検出判断のためのエラーパケット検出数の閾値として１を設定することとしている。このようにＩｍｐｌｉｃｉｔに閾値の通知を行うことにより、シグナリングのオーバヘッドを削減することができる。
【００８５】
＜ＵＥ  ｃａｐａｂｉｌｉｔｙ通知について＞
ＲＲＣシグナリングに関連して、図１３に示すように、ユーザ装置ＵＥが、本実施の形態におけるＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力を有することをＵＥ  ｃａｐａｂｉｌｉｔｙとして明示的に基地局ｅＮＢに通知することとしてもよい。
【００８６】
ＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力は、ユーザ装置単位で通知しても良いし、ＲＬＣモード単位で通知しても良い。また、いくつのベアラを同時に制御できるかを示す値をＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力として基地局ｅＮＢに通知してもよい。例えば基地局ｅＮＢは、ＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力有りを通知したユーザ装置ＵＥに対してのみ、前述したエラーパケット検出数の閾値を通知することとしてもよい。
【００８７】
上記のようにＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力を明示的（ｅｘｐｌｉｃｉｔ）に通知することの他、暗黙的（ｉｍｌｉｃｉｔ）に通知してもよい。例えば、基地局ｅＮＢは、特定のＵＥ  ｃａｔｅｇｏｒｙ（例：Ｒｅｌ−１２）、もしくは、特定のｃａｐａｂｉｌｉｔｙ（例：ＲＯＨＣ）を通知したユーザ装置ＵＥはＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力を有すると見なすこととしてもよい。また、ＨＦＮ  ｄｅ−ｓｙｎｃ検出の能力有りを暗黙的に示す特定のＵＥ  ｃａｔｅｇｏｒｙや特定のｃａｐａｂｉｌｉｔｙを通知したユーザ装置ＵＥは必ず本機能に対応しなければならないものとする。
【００８８】
なお、上述したＲＲＣシグナリング、ＵＥ  ｃａｐａｂｉｌｉｔｙ等に係る機能は組み合わせて実施することが可能である。
【００８９】
（ＰＤＣＰ状態一致制御の例）
以下、エラーパケット検出数が閾値を超えた（ｏｒ閾値以上になった）ことによりＨＦＮ  ｄｅ−ｓｙｎｃが検出された場合におけるＰＤＣＰ状態一致のための制御の各種の例について説明する。以下の制御例１〜制御例４は、基地局ｅＮＢがＤｅｃｏｍｐｒｅｓｓｏｒである場合の動作に対応し、制御例５〜制御例７は、ユーザ装置ＵＥがＤｅｃｏｍｐｒｅｓｓｏｒである場合の動作に対応する。
【００９０】
＜基地局ｅＮＢがＤｅｃｏｍｐｒｅｓｓｏｒである場合＞
制御例１は、Ｉｎｔｒａ−ｃｅｌｌハンドオーバを行い、レイヤ２リセットを図るものである。すなわち、図１４（ａ）に示すとおり、基地局ｅＮＢからユーザ装置ＵＥに対してＩｎｔｒａ−ｃｅｌｌハンドオーバ指示を送信し（ステップ２０１）、ユーザ装置ＵＥは当該指示に応じて同一基地局ｅＮＢに接続を行う（ステップ２０２）。このとき、ＲＬＣ−ＵＭが指定されている場合、基地局ｅＮＢとユーザ装置ＵＥにおけるＰＤＣＰ  ＳＮ及びＨＦＮはリセットされ、ＰＤＣＰ状態一致がなされる。
【００９１】
制御例１では、瞬断が発生する可能性があるが、ｉｎｔｒａ−ｅＮＢ内なので瞬断は小さいことが想定される。なお、ＲＬＣ−ＡＭベアラについてはｉｎｔｒａ−ｃｅｌｌ  ＨＯに伴うＰＤＣＰ  ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施されたとしても、ＨＦＮのリセットを行わないため、本制御例はＲＬＣ−ＵＭベアラに対してのみ適用可能である。
【００９２】
制御例２は、ＨＦＮ  ｄｅ−ｓｙｎｃが検出された対象ベアラの削除を行い、改めて当該ベアラを追加するものである。すなわち、図１４（ｂ）に示すように、基地局ｅＮＢはベアラを一旦リセットし（ステップ３０１）、改めて当該ベアラを追加する。制御例２では、滞留データが破棄されることになるが音声パケットのようにスモールパケットが周期的に到来する場合には大きな影響はないと考えられる。
【００９３】
制御例３は、Ｆｕｌｌ  ｃｏｆｉｇｕｒａｔｉｏｎを行うものである。すなわち、図１５（ａ）に示すように、基地局ｅＮＢはユーザ装置ＵＥに対してＦｕｌｌ  ｃｏｆｉｇｕｒａｔｉｏｎ指示を行い（ステップ４０１）、基地局ｅＮＢ及びユーザ装置ＵＥは、Ｆｕｌｌ  ｃｏｆｉｇｕｒａｔｉｏｎを行う（ステップ４０２）。Ｆｕｌｌ  ｃｏｆｉｇｕｒａｔｉｏｎ時には、ユーザ装置ＵＥと基地局ｅＮＢは、全無線ベアラを一旦削除し、改めて追加を行う。ただし、音声サービスと他サービスが同時に発生しているケースがそれほど多くないことが想定されることから、影響は制御例２と同等と考えられる。制御例２、３において、ベアラ削除／追加により、基地局ｅＮＢとユーザ装置ＵＥにおけるＰＤＣＰ  ＳＮ及びＨＦＮはリセットされ、ＰＤＣＰ状態一致がなされる。
【００９４】
制御例４では、図１５（ｂ）に示すように、ＲＲＣ  ｃｏｎｎｅｃｔｉｏｎ  ｒｅｌｅａｓｅを行い（ステップ５０１）、通信を一旦切断し、再接続をする（ステップ５０２）。これによってもＰＤＣＰ状態一致がなされる。
【００９５】
＜ユーザ装置ＵＥがＤｅｃｏｍｐｒｅｓｓｏｒである場合＞
制御例５は、ユーザ装置ＵＥがＤｅｃｏｍｐｒｅｓｓｏｒである場合において、図１６（ａ）に示すように、ＨＦＮ  ｄｅ−ｓｙｎｃを検知したユーザ装置ＵＥから基地局ｅＮＢに再接続を行い、レイヤ２リセットを図る。制御例１と同様に、瞬断が発生するが、ｉｎｔｒａ−ｅＮＢ内なので瞬断は大きくないことが想定できる。
【００９６】
制御例６は、ダミーのＭｅａｓｕｒｅｍｅｎｔ  ｒｅｐｏｒｔを報告するものである。すなわち、図１６（ｂ）に示すように、ステップ７０１において、ユーザ装置ＵＥは、現在のセルが品質劣化し、品質の良い隣接セルがあることを示す内容のダミーのＭｅａｓｕｒｅｍｅｎｔ  ｒｅｐｏｒｔを基地局ｅＮＢ−Ａに報告する。基地局ｅＮＢ−Ａは、ユーザ装置ＵＥに対して当該隣接セルへのハンドオーバを指示し（ステップ７０２）、ユーザ装置ＵＥは、隣接セル（基地局ｅＮＢ−Ｂ）に接続する（ステップ７０３）。これにより、結果的にハンドオーバに伴うレイヤ２リセットを図ることができる。なお、制御例６は、ハンドオーバ先セルが存在することが前提となる。
【００９７】
制御例７では、図１６（ｃ）に示すように、ユーザ装置ＵＥがＨＦＮ  ｄｅ−ｓｙｎｃの発生を基地局ｅＮＢに通知し（ステップ８０１）、基地局ｅＮＢが当該通知を契機としてＰＤＣＰ状態一致制御を行う（ステップ８０２）。ＨＦＮ  ｄｅ−ｓｙｎｃの発生を通知する信号は特定の信号に限定されないが、例えば、新規のＲＲＣメッセ−ジ、もしくは新規のＭＡＣ  ＣＥを定義し、これを用いることとしてよい。
【００９８】
ステップ８０２におけるＰＤＣＰ状態一致制御は、例えば、制御例１〜４のうちのいずれかの制御例による制御を行うこととしてよい。
【００９９】
なお、これまでに説明したようなＨＦＮ  ｄｅ−ｓｙｎｃの検知及びＰＤＣＰ状態一致の制御については全ての場合で行うこととしてもよいし、基地局ｅＮＢが当該検知・制御を行うか否かを決定（もしくは外部から設定）し、当該検知・制御を行うか否か（ＯＮ／ＯＦＦ）を示す指示（例：ＲＲＣシグナリングメッセージ）をユーザ装置ＵＥに送信し、基地局ｅＮＢ及びユーザ装置ＵＥは、当該指示がＯＮである場合にのみ当該検知・制御を行うようにしてもよい。
【０１００】
また、ユーザ装置ＵＥ／基地局ｅＮＢのＡＭＣ（Ａｄａｐｔｉｖｅ  Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ）において、ＨＦＮ  ｄｅ−ｓｙｎｃの回数によって、ＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｏｄｉｎｇ  Ｓｃｈｅｍｅ、変調符号化方式）を変更することとしてもよい。例えば、ＨＦＮ  ｄｅ−ｓｙｎｃが多い場合（例：ある期間内で所定の閾値よりも大きい場合）は、無線でのロスが大きいと推定できるから、より確実に受信できる（低い）ＭＣＳを選択する。
【０１０１】
（装置構成、処理フロー）
＜基地局ｅＮＢ＞
図１７に、本発明の実施の形態における基地局ｅＮＢ（Ｄｅｃｏｍｐｒｅｓｓｏｒ）の機能構成図を示す。図１７に示すように、本実施の形態の基地局ｅＮＢは、ＤＬ信号送信部１０１、ＵＬ信号受信部１０２、カウンタ管理部１０３、ＲＯＨＣ機能部１０４、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５、ＰＤＣＰ状態一致制御部１０６、ＲＲＣ管理部１０７を有する。なお、ＨＦＮ  ｄｅ−ｓｙｎｃ検出のためにＲＯＨＣパケットを使用しない場合（ＩＰ／ＵＤＰ／ＲＴＰパケット等を使用する場合）には、ＲＯＨＣ機能部１０４を有しないこととしてもよい。また、図１７は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１７に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【０１０２】
ＤＬ信号送信部１０１は、送信情報から無線信号を生成し、ユーザ装置ＵＥに送信する。ＵＬ信号受信部１０２は、ユーザ装置ＵＥから無線信号を受信し、無線信号から情報を抽出する。ＤＬ信号送信部１０１は、ユーザ装置ＵＥに送信するデータを一時的に格納するＤＬバッファを備える。ＵＬ信号受信部１０２は、ユーザ装置ＵＥから受信したデータを一時的に格納するＵＬバッファを備える。
【０１０３】
カウンタ管理部１０３は、カウンタ（具体的には変数）を持ち、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５によるエラーパケット検出時（例：ＩＲパケットのＣＲＣ判定等がＮＧのとき）にカウンタをインクリメント（１加える）する動作を行う。なお、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、前述したように、４種類の方法（ＩＲパケットＣＲＣ、ＩＲ以外ＲＯＨＣパケットＣＲＣ、特定フィールドチェック、ウィンドウ外受信）のいずれか又は複数（全部を含む）でＨＦＮ  ｄｅ−ｓｙｎｃ検出を行うことができ、カウンタ管理部１０３は、単一のカウンタあるいは個別のカウンタ（カウント対象種別毎、或いはその組み合わせ毎のカウンタ）を動作させることができる。
【０１０４】
ＲＯＨＣ機能部１０４は、ＲＯＨＣの制御を行うものであり、ＩＲパケット等のＲＯＣＨパケットの生成、送受信等を行うとともに、パケットのヘッダ圧縮／復元処理を行う。
【０１０５】
ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、ＵＬ信号受信部１０２により受信したパケットにおけるエラー判定を行い、エラーパケットの検出数が閾値を超える（あるいは閾値以上の）場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定する。より具体的には、例えば、ＵＬ信号受信部１０２により受信したパケット（本実施の形態ではＰＤＣＰ  ＰＤＵ又はＰＤＣＰ  ＳＤＵ）のサイズに基づき、受信パケットがＩＲパケットか否かを判定し、ＩＲパケットである場合にＣＲＣ判定を行い、カウンタ管理部１０３におけるカウンタを参照することで、ＣＲＣ  ＮＧ回数が所定の閾値を超えた場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定する。つまり、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、ユーザ装置ＵＥから受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを含む。
【０１０６】
また、前記のように、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、上記ＩＲパケットＣＲＣのＮＧカウント方式の他、ＩＲ以外ＲＯＨＣパケットのＣＲＣのＮＧカウント方式、特定フィールドＮＧカウント方式、ウィンドウ外受信カウント方式のいずれも実施できる。
【０１０７】
ＰＤＣＰ状態一致制御部１０６は、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５によりＨＦＮ  ｄｅ−ｓｙｎｃの発生が検知された場合に、例えば前述した制御例１〜４、７に示したＰＤＣＰ状態一致の制御を行う。
【０１０８】
ＲＲＣ管理部１０７は、ユーザ装置ＵＥに対してエラーパケット検出数の閾値等（所定の異常判定条件）をシグナリングメッセージで通知する。また、ＲＲＣ管理部１０７は、ユーザ装置ＵＥからＵＥ  ｃａｐａｂｉｌｉｔｙを受信し、保持する。
【０１０９】
図１８を参照して、図１７に示すように構成される基地局ｅＮＢの動作例を説明する。この動作例は、ＩＲパケットＣＲＣのＮＧカウント方式の例であるが、ＮＧカウント値に基づきＨＦＮ  ｄｅ−ｓｙｎｃを判定する処理内容は、他の３つの方式においても同様である。
【０１１０】
まず、ステップ９０１において、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５によりカウンタ管理部１０３におけるカウンタがリセットされる（ｋ＝０）。ステップ９０２において、ＵＬ信号受信部１０２がパケットを受信すると、ステップ９０３に進み、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、当該パケット（本実施の形態ではＰＤＣＰ  ＰＤＵ又はＰＤＣＰ  ＳＤＵ）のサイズが、所定の閾値よりも大きいか否かを判定する。ステップ９０３での判定結果がＮｏの場合、今回の処理を終了し、ステップ９０１に戻る。
【０１１１】
ステップ９０３での判定結果がＹｅｓの場合、つまり、パケットサイズが所定の閾値よりも大きい場合、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、受信パケットがＩＲパケットであると判断し、ステップ９０４に進み、ＩＲパケットにおけるＣＲＣの判定を行う。
【０１１２】
ステップ９０４の判定結果がＹｅｓ、つまり、ＣＲＣがＯＫである場合、今回の処理を終了し、ステップ９０１に戻る。
【０１１３】
ステップ９０４の判定結果がＮｏ、つまり、ＣＲＣがＮＧである場合、ステップ９０５に進み、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、カウンタ管理部１０３におけるカウンタに１を加え（ｋ＋＋）、ステップ９０６に進む。ステップ９０６において、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部１０５は、カウンタ（ｋ）が、所定の閾値（ｋ＿ｍａｘ）を超えるか否かを判定する。ステップ９０６での判定結果がＮｏの場合はステップ９０２に戻る。
【０１１４】
ステップ９０６での判定結果がＹｅｓの場合、つまり、カウンタの値（ＣＲＣ  ＮＧ回数）が所定の閾値を超えた場合、ステップ９０７に進み、ＰＤＣＰ状態一致制御部１０６が、例えば前述した制御例１〜４等の制御を行うことでレイヤ２リセットを行う。これにより、ＰＤＣＰ状態一致がなされ、ＨＦＮ  ｄｅ−ｓｙｎｃが解消する。
【０１１５】
＜ユーザ装置ＵＥ＞
図１９に、本発明の実施の形態におけるユーザ装置ＵＥ（Ｄｅｃｏｍｐｒｅｓｓｏｒ）の機能構成図を示す。図１９に示すように、本実施の形態のユーザ装置ＵＥは、ＵＬ信号送信部２０１、ＤＬ信号受信部２０２、カウンタ管理部２０３、ＲＯＨＣ機能部２０４、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５、ＰＤＣＰ状態一致制御部２０６、ＲＲＣ管理部２０７を有する。なお、ＨＦＮ  ｄｅ−ｓｙｎｃ検出のためにＲＯＨＣパケットを使用しない場合（ＩＰ／ＵＤＰ／ＲＴＰパケット等を使用する場合）には、ＲＯＨＣ機能部２０４を有しないこととしてもよい。図１９は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１９に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【０１１６】
ＵＬ信号送信部２０１は、送信情報から無線信号を生成し、基地局ｅＮＢに送信する。ＤＬ信号受信部２０２は、基地局ｅＮＢから無線信号を受信し、無線信号から情報を抽出する。ＵＬ信号送信部２０１は、基地局ｅＮＢに送信するデータを一時的に格納するＵＬバッファを備える。ＤＬ信号受信部２０２は、基地局ｅＮＢから受信したデータを一時的に格納するＤＬバッファを備える。
【０１１７】
カウンタ管理部２０３は、カウンタ（具体的には変数）を持ち、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５によるエラーパケット検出時（例：ＩＲパケットのＣＲＣ判定等がＮＧのとき）にカウンタをインクリメント（１加える）する動作を行う。なお、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、前述したように、４種類の方法（ＩＲパケットＣＲＣ、ＩＲ以外ＲＯＨＣパケットＣＲＣ、特定フィールドチェック、ウィンドウ外受信）のいずれか又は複数（全部を含む）でＨＦＮ  ｄｅ−ｓｙｎｃ検出を行うことができ、カウンタ管理部２０３は、単一のカウンタあるいは個別のカウンタ（カウント対象種別毎、或いはその組み合わせ毎のカウンタ）を動作させることができる。ＲＯＨＣ機能部２０４は、ＲＯＨＣの制御を行うものであり、ＩＲパケット等のＲＯＣＨパケットの生成、送受信等を行うとともに、パケットのヘッダ圧縮／復元処理を行う。
【０１１８】
ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、ＤＬ信号受信部２０２により受信したパケットにおけるエラー判定を行い、エラーパケットの検出数が閾値を超える（あるいは閾値以上の）場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定する。より具体的には、例えば、ＤＬ信号受信部２０２により受信したパケット（本実施の形態ではＰＤＣＰ  ＰＤＵ又はＰＤＣＰ  ＳＤＵ）のサイズに基づき、受信パケットがＩＲパケットか否かを判定し、ＩＲパケットである場合にＣＲＣ判定を行い、カウンタ管理部２０３におけるカウンタを参照することで、ＣＲＣ  ＮＧ回数が所定の閾値を超えた場合にＨＦＮ  ｄｅ−ｓｙｎｃが発生したと判定する。つまり、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、基地局ｅＮＢから順次受信する受信パケットのサイズに基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを含む。
【０１１９】
また、前記のように、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、上記ＩＲパケットＣＲＣのＮＧカウント方式の他、ＩＲ以外ＲＯＨＣパケットのＣＲＣのＮＧカウント方式、特定フィールドＮＧカウント方式、ウィンドウ外受信カウント方式のいずれも実施できる。
【０１２０】
ＰＤＣＰ状態一致制御部２０６は、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５によりＨＦＮ  ｄｅ−ｓｙｎｃの発生が検知された場合に、例えば前述した制御例５〜７に示したＰＤＣＰ状態一致の制御を行う。
【０１２１】
ＲＲＣ管理部２０７は、基地局ｅＮＢからエラーパケット検出数の閾値等（所定の異常判定条件）をシグナリングメッセージにより受信し、保持する。ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、当該閾値を用いてＨＦＮ  ｄｅ−ｓｙｎｃ検出を行うことができる。また、ＲＲＣ管理部２０７は、ＵＥ  ｃａｐａｂｉｌｉｔｙを基地局ｅＮＢに通知する。
【０１２２】
図２０を参照して、図１９に示すように構成されるユーザ装置ＵＥの動作例を説明する。この動作例は、ＩＲパケットＣＲＣのＮＧカウント方式の例であるが、ＮＧカウント値に基づきＨＦＮ  ｄｅ−ｓｙｎｃを判定する処理内容は、他の３つの方式においても同様である。
【０１２３】
まず、ステップ１００１において、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５によりカウンタ管理部２０３におけるカウンタがリセットされる（ｋ＝０）。ステップ１００２において、ＤＬ信号受信部２０２がパケットを受信すると、ステップ１００３に進み、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、当該パケット（本実施の形態ではＰＤＣＰ  ＰＤＵ又はＰＤＣＰ  ＳＤＵ）のサイズが、所定の閾値よりも大きいか否かを判定する。ステップ１００３での判定結果がＮｏの場合、今回の処理を終了し、ステップ１００１に戻る。
【０１２４】
ステップ１００３での判定結果がＹｅｓの場合、つまり、パケットサイズが所定の閾値よりも大きい場合、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、受信パケットがＩＲパケットであると判断し、ステップ１００４に進み、ＩＲパケットにおけるＣＲＣの判定を行う。
【０１２５】
ステップ１００４の判定結果がＹｅｓ、つまり、ＣＲＣがＯＫである場合、今回の処理を終了し、ステップ１００１に戻る。
【０１２６】
ステップ１００４の判定結果がＮｏ、つまり、ＣＲＣがＮＧである場合、ステップ１００５に進み、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、カウンタ管理部２０３におけるカウンタに１を加え（ｋ＋＋）、ステップ１００６に進む。ステップ１００６において、ＨＦＮ  ｄｅ−ｓｙｎｃ検出部２０５は、カウンタ（ｋ）が、所定の閾値（ｋ＿ｍａｘ）を超えるか否かを判定する。ステップ１００６での判定結果がＮｏの場合はステップ１００２に戻る。
【０１２７】
ステップ１００６での判定結果がＹｅｓの場合、つまり、カウンタの値（ＣＲＣ  ＮＧ回数）が所定の閾値を超えた場合、ステップ１００７に進み、ＰＤＣＰ状態一致制御部２０６が、例えば前述した制御例５〜７等の制御を行うことでレイヤ２リセットを行う。これにより、ＰＤＣＰ状態一致がなされ、ＨＦＮ  ｄｅ−ｓｙｎｃが解消する。
【０１２８】
以上、説明したように、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記基地局であって、前記ユーザ装置から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備える基地局が提供される。この構成により、ＰＤＣＰレイヤのパケット（例：ＰＤＣＰ  ＰＤＵ）の通信について、当該レイヤでは検出できない異常を検出することが可能となる。
【０１２９】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記基地局であって、前記ユーザ装置から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備える基地局が提供される。この構成により、ＰＤＣＰレイヤのパケット（例：ＰＤＣＰ  ＰＤＵ）の通信について、当該レイヤでは検出できない異常を検出することが可能となる。
【０１３０】
前記異常検出手段は、前記ＰＤＣＰレイヤのパケットが所定の受信ウィンドウ外で受信された回数をカウントし、当該回数が所定閾値を超えた場合に、当該ＰＤＣＰレイヤに異常が発生したことを検出することも可能である。この構成により、所定のパケットの誤り検出等を行うことにより異常を検出する場合よりも早期に異常を検出できる。
【０１３１】
前記異常検出手段は、例えば、前記ユーザ装置において前記ＰＤＣＰレイヤのパケットのペイロードの秘匿処理に用いられた所定の値と、当該パケットのヘッダに基づいて前記所定の値として推定される値とが異なることを前記異常として検出する。この構成により、ＰＤＣＰレイヤのパケットについて、当該レイヤでは検出できない異常が、秘匿処理に用いられる所定の値の送信側と受信側間での不一致である場合において、これを検出することができる。
【０１３２】
前記基地局は、前記異常検出手段により前記異常が検出された場合に、前記所定の値を前記ユーザ装置と前記基地局との間で一致させるための制御を行う状態一致制御手段を備えてもよい。この構成により、秘匿処理に用いられる所定の値の送信側と受信側間での不一致を解消でき、受信側（基地局）では正常に解匿処理を行うことができるようになる。
【０１３３】
前記所定のパケットは、例えば、ＲＯＨＣにおけるＩＲパケットやＲＯＨＣのその他のパケットであり、前記ＰＤＣＰレイヤにおけるパケットはＰＤＣＰ  ＰＤＵである。この構成により、ＰＤＣＰ  ＰＤＵのペイロードの秘匿処理に用いられる所定の値（例：ＨＦＮ、ＣＯＵＮＴ値）の送信側と受信側間での不一致を検出することができ、また、上記の状態一致制御手段を用いることで当該不一致を解消できる。
【０１３４】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、前記基地局から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定手段と、前記判定手段により前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査手段と、前記誤り検査手段により前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備えるユーザ装置が提供される。この構成により、ＰＤＣＰレイヤのパケット（例：ＰＤＣＰ  ＰＤＵ）の通信について、当該レイヤでは検出できない異常を検出することが可能となる。
【０１３５】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、前記基地局から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定手段と、前記不正値判定手段により前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段とを備えるユーザ装置が提供される。この構成により、ＰＤＣＰレイヤのパケット（例：ＰＤＣＰ  ＰＤＵ）の通信について、当該レイヤでは検出できない異常を検出することが可能となる。
【０１３６】
前記異常検出手段は、前記ＰＤＣＰレイヤのパケットが所定の受信ウィンドウ外で受信された回数をカウントし、当該回数が所定閾値を超えた場合に、当該ＰＤＣＰレイヤに異常が発生したことを検出することもできる。この構成により、所定のパケットの誤り検出等を行うことにより異常を検出する場合よりも早期に異常を検出できる。
【０１３７】
前記異常検出手段は、例えば、前記基地局において前記ＰＤＣＰレイヤのパケットのペイロードの秘匿処理に用いられた所定の値と、当該パケットのヘッダに基づいて前記所定の値として推定される値とが異なることを前記異常として検出する。この構成により、ＰＤＣＰレイヤのパケットについて、当該レイヤでは検出できない異常が、秘匿処理に用いられる所定の値の送信側と受信側間での不一致である場合において、これを検出することができる。
【０１３８】
前記ユーザ装置は、前記異常検出手段により前記異常が検出された場合に、前記所定の値を前記ユーザ装置と前記基地局との間で一致させるための制御を行う状態一致制御手段を備えてもよい。この構成により、秘匿処理に用いられる所定の値の送信側と受信側間での不一致を解消でき、受信側（ユーザ装置）では正常に解匿処理を行うことができるようになる。
【０１３９】
前記所定のパケットは、例えば、ＲＯＨＣにおけるＩＲパケットやＲＯＨＣのその他のパケットであり、前記ＰＤＣＰレイヤにおけるパケットはＰＤＣＰ  ＰＤＵである。この構成により、ＰＤＣＰ  ＰＤＵのペイロードの秘匿処理に用いられる所定の値（例：ＨＦＮ、ＣＯＵＮＴ値）の送信側と受信側間での不一致を検出することができ、また、上記の状態一致制御手段を用いることで当該不一致を解消できる。
【０１４０】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置であって、前記基地局から所定の異常判定条件を受信する受信手段と、前記基地局から受信するパケットに誤りがあるか否かを判定する誤り検出手段と、前記誤り検出手段により誤りがあると判定されたパケットである誤りパケットの個数が前記所定の異常判定条件を満たす場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出手段と、前記基地局へ前記異常検出手段による検出を通知する通知手段とを備えるユーザ装置が提供される。この構成により、ＰＤＣＰレイヤのパケット（例：ＰＤＣＰ  ＰＤＵ）の通信について、当該レイヤでは検出できない異常を検出することが可能となる。
【０１４１】
前記所定の異常判定条件は、例えば、前記ＰＤＣＰレイヤにおける異常を検出するための閾値となる誤りパケットの個数を示す。所定の異常判定条件として閾値となる誤りパケットの個数を基地局から指定することで、ユーザ装置は的確に異常判定を行うことができる。
【０１４２】
前記ＰＤＣＰレイヤにおける異常は例えばＨＦＮ同期外れである。このようにＨＦＮ同期外れを異常として検出することで、適切にＰＤＣＰ状態一致等の対策をとることができる。
【０１４３】
前記受信手段は、例えば、ユーザ装置単位、ＲＬＣモード単位、又はベアラ単位で前記所定の異常判定条件を前記基地局から受信する。このように種々の単位で所定の異常判定条件を受信することができるので、ＲＬＣモードの種別や、ベアラの種別に応じた適切な異常判定条件を設定できる。
【０１４４】
前記受信手段は、ＲＬＣ−ＵＭベアラに対して用いるＰＤＣＰシーケンス番号のビット長として特定のビット長を受信することにより、暗黙的に前記所定の異常判定条件を受信することとしてもよい。これにより、シグナリングのオーバヘッドを削減できる。
【０１４５】
前記通知手段は、前記ユーザ装置が、前記ＰＤＣＰレイヤにおける異常を検出する能力を有することを示す能力情報を明示的又は暗黙的に前記基地局に通知することとしてもよい。このように能力情報と通知することで、基地局は、ユーザ装置における異常検出能力を把握でき、当該能力に応じた適切な制御を行うことが可能となる。
【０１４６】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記基地局が実行する異常検出方法であって、前記ユーザ装置から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定ステップと、前記判定ステップにより前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査ステップと、前記誤り検査ステップにより前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出ステップとを備える異常検出方法が提供される。
【０１４７】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記基地局が実行する異常検出方法であって、前記ユーザ装置から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定ステップと、前記不正値判定ステップにより前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出ステップとを備える異常検出方法が提供される。
【０１４８】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置が実行する異常検出方法であって、前記基地局から受信する受信パケットのサイズ又は所定のフィールドの値に基づいて、当該受信パケットが、誤り検査値を有する所定のパケットであるか否かを判定する判定ステップと、前記判定ステップにより前記受信パケットが前記所定のパケットであると判定された場合において、前記誤り検査値を用いて当該所定のパケットに対する誤り検査を行う誤り検査ステップと、前記誤り検査ステップにより前記所定のパケットの誤りを検出した回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出ステップとを備える異常検出方法が提供される。
【０１４９】
また、本実施の形態により、ユーザ装置と基地局とを有する移動通信システムにおける前記ユーザ装置が実行する異常検出方法であって、前記基地局から受信する所定のパケットにおける特定のフィールドの値が不正な値であるか否かを判定する不正値判定ステップと、前記不正値判定ステップにより前記特定のフィールドの値が不正な値であると判定された回数が所定閾値を超えた場合に、ＰＤＣＰレイヤにおいて異常が発生したことを検出する異常検出ステップとを備える異常検出方法が提供される。
【０１５０】
本実施の形態で説明したユーザ装置ＵＥは、ＣＰＵとメモリを備え、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。
【０１５１】
本実施の形態で説明した基地局ｅＮＢは、ＣＰＵとメモリを備え、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。
【０１５２】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、ユーザ装置及び基地局は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置が有するプロセッサにより動作するソフトウェア、及び、基地局が有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【０１５３】
ＵＥ  ユーザ装置
ｅＮＢ  基地局
１０  送信装置
２０  受信装置
１０１  ＤＬ信号送信部
１０２  ＵＬ信号受信部
１０３  カウンタ管理部
１０４  ＲＯＨＣ機能部
１０５  ＨＦＮ  ｄｅ−ｓｙｎｃ検出部
１０６  ＰＤＣＰ状態一致制御部
１０７  ＲＲＣ管理部
２０１  ＵＬ信号送信部
２０２  ＤＬ信号受信部
２０３  カウンタ管理部
２０４  ＲＯＨＣ機能部
２０５  ＨＦＮ  ｄｅ−ｓｙｎｃ検出部
２０６  ＰＤＣＰ状態一致制御部
２０７  ＲＲＣ管理部
【図１】
2016021726.tif 000003
【図２】
2016021726.tif 000004
【図３】
2016021726.tif 000005
【図４】
2016021726.tif 000006
【図５】
2016021726.tif 000007
【図６】
2016021726.tif 000008
【図７】
2016021726.tif 000009
【図８】
2016021726.tif 000010
【図９】
2016021726.tif 000011
【図１０】
2016021726.tif 000012
【図１１】
2016021726.tif 000013
【図１２】
2016021726.tif 000014
【図１３】
2016021726.tif 000015
【図１４】
2016021726.tif 000016
【図１５】
2016021726.tif 000017
【図１６】
2016021726.tif 000018
【図１７】
2016021726.tif 000019
【図１８】
2016021726.tif 000020
【図１９】
2016021726.tif 000021
【図２０】
2016021726.tif 000022