(57)【特許請求の範囲】
【請求項１】
サービスエリアが重なり、異なる種類の通信を行なう第１の無線アクセスシステムと第２の無線アクセスシステムとを収容する移動通信システムにおける第１の無線アクセスシステムの無線基地局であって、
該無線基地局の通信リソースの状態を格納するリソース管理部と、
該リソース管理部を参照して該無線基地局が複数の端末との無線通信を行なうための通信リソースの不足を検出し、該通信リソース不足を検出したとき、該無線基地局を使用して通信中の端末の中から、使用されている通信サービスの種別に基づいて、該使用されている通信サービスが前記第２の無線アクセスシステムの通信サービスで代替可能かどうかを判定し、該判定に基づいて代替可能な端末を選択し、
前記選択された端末を前記第２の無線アクセスシステムにハンドオフさせる、システム間ハンドオフを起動させるハンドオフ制御部とを有することを特徴とする無線基地局。
【請求項２】
請求項１に記載の無線基地局であって、
前記ハンドオフ制御部は、該無線基地局と通信する保守装置からの閉塞指示を受信したとき、通信リソースが無くなったとしてリソース不足を検出したとみなすことを特徴とする無線基地局。
【請求項３】
請求項１に記載の無線基地局であって、
前記ハンドオフ制御部は、該無線基地局と通信する保守装置からの、特定の通信サービスの提供中止指示を受信したとき、通信リソースが無くなったとしてリソース不足を検出したとみなすことを特徴とする無線基地局。
【請求項４】
請求項１に記載の無線基地局であって、
前記ハンドオフ制御部は、該無線端末における単位時間あたりのＱｏＳ制御失敗数が所定の閾値を超えた場合に通信リソースが不足していると判断することを特徴とする無線基地局。
【請求項５】
請求項１に記載の無線基地局であって、
前記ハンドオフ制御部は、単位時間あたりのハンドオフ回数が所定の閾値を超えた端末をシステム間ハンドオフの対象として選択することを特徴とする無線基地局。
【請求項６】
請求項１に記載の無線基地局であって、
前記ハンドオフ制御部は、単位時間あたりのＱｏＳ制御失敗数が所定の閾値を超えた端末をシステム間ハンドオフの対象として選択することを特徴とする無線基地局。
【請求項７】
請求項１から６のいずれかに記載の無線基地局であって、
前記ハンドオフ制御部は、端末が複数の無線基地局と通信するソフトハンドオフ状態から単一の無線基地局との通信状態に遷移するときに前記単一の無線基地局において通信リソースが不足していることを検出した場合に、前記システム間ハンドオフを起動することを特徴とする、無線基地局。
【請求項８】
請求項１記載の無線基地局であって、前記ハンドオフ制御部は、前記第１の無線アクセスシステムに属する他の無線基地局と通信を行っている端末が、自局にハンドオフされてきたことをトリガとして前記通信リソースが不足しているか否かの判定を行なうことを特徴とする無線基地局。
【請求項９】
請求項１記載の無線基地局であって、前記ハンドオフ制御部は、周期的に前記通信リソースが不足しているか否かの判定を行なうことを特徴とする無線基地局。
【請求項１０】
サービスエリアが重なり、異なる種類の通信を行なう第１の無線アクセスシステムと第２の無線アクセスシステムとを収容する移動通信システムにおける第１の無線アクセスシステムであって、
該第１の無線アクセスシステムの無線基地局が複数の端末との無線通信を行なうための通信リソースの不足を検出するリソース不足検出手段と、
該通信リソース不足を検出したとき、前記無線基地局を使用して通信中の端末の中から、使用されている通信サービスの種別に基づいて、該使用されている通信サービスが前記第２の無線アクセスシステムの通信サービスで代替可能かどうかを判定し、該判定に基づいて代替可能な端末を選択する、システム間ハンドオフ対象選択手段と、
前記選択された端末を前記第２の無線アクセスシステムにハンドオフさせる、システム間ハンドオフ起動手段とを有することを特徴とする無線アクセスシステム。
【請求項１１】
請求項１０に記載の無線アクセスシステムであって、
前記リソース不足検出手段は、前記無線基地局と通信する保守装置からの閉塞指示を受信したとき、通信リソースが無くなったとしてリソース不足を検出することを特徴とする無線アクセスシステム。
【請求項１２】
請求項１０に記載の無線アクセスシステムであって、
前記リソース不足検出手段は、前記無線基地局と通信する保守装置から特定の通信サービスの提供中止指示を受信したとき、リソース不足を検出したと判断することを特徴とする無線アクセスシステム。
【請求項１３】
請求項１０に記載の無線アクセスシステムであって、
前記リソース不足検出手段は、単位時間あたりのＱｏＳ制御失敗数が閾値を超えたとき、通信リソース不足を検出したと判断することを特徴とする無線アクセスシステム。
【請求項１４】
請求項１０に記載の無線アクセスシステムであって、
前記システム間ハンドオフ対象選択手段は、単位時間あたりのハンドオフ回数が閾値を超えた端末を選択することを特徴とする無線アクセスシステム。
【請求項１５】
請求項１０に記載の無線アクセスシステムであって、
前記システム間ハンドオフ対象選択手段は、単位時間あたりのＱｏＳ制御失敗数が閾値を超えた端末を選択することを特徴とする無線アクセスシステム。
【請求項１６】
請求項１０から１５のいずれかに記載の無線アクセスシステムであって、
前記リソース不足検出手段は、端末が複数の無線基地局と通信するソフトハンドオフ状態から単一の無線基地局との通信状態に遷移するときに前記単一の無線基地局において通信リソースが不足していることを検出した場合に、システム間ハンドオフを起動することを特徴とする無線アクセスシステム。
【請求項１７】
請求項１０記載の無線アクセスシステムであって、前記リソース不足検出手段は、前記第１の無線アクセスシステムに属する第１の無線基地局と通信を行っている端末が、第２の無線基地局にハンドオフされてきたことをトリガとして前記通信リソースが不足しているか否かの判定を行なうことを特徴とする無線アクセスシステム。
【請求項１８】
サービスエリアが重なり、異なる種類の通信を行なう第１の無線アクセスシステムと第２の無線アクセスシステムとを収容する移動通信システムにおけるシステム間ハンドオフ起動方法であって、
各無線基地局の通信リソースの状態を測定する第１のステップと、
該測定された各無線基地局の通信リソース状態に基づいて、該無線基地局が複数の端末との無線通信を行なうための通信リソースの不足を検出する第２のステップと、
該通信リソース不足を検出したとき、該無線基地局を使用して通信中の端末の中から、使用されている通信サービスの種別に基づいて、該使用されている通信サービスが前記第２の無線アクセスシステムの通信サービスで代替可能かどうかを判定し、該判定に基づいて代替可能な端末を選択する第３のステップと、
前記選択された端末を前記第２の無線アクセスシステムにハンドオフさせる、システム間ハンドオフを起動させる第４のステップとを有することを特徴とするシステム間ハンドオフ起動方法。
【発明の詳細な説明】
【参照による取り込み】
【０００１】
本出願は、２００６年５月１０日に出願された日本特許出願第２００６−１３０９６７号の優先権を主張し、その内容を参照することにより本出願に取り込む。
【技術分野】
【０００２】
本発明は、システム間ハンドオフをサポートする無線アクセスネットワークに関するものである。
【背景技術】
【０００３】
携帯電話システムの国際標準化組織３ＧＰＰ２では、パケット通信用無線アクセス技術であるＥＶ−ＤＯ  Ｒｅｖ．Ａ（以下、Ｒｅｖ．Ａと略す）システムを用いた、ＶｏＩＰ音声通話サービスの標準化作業が進行中である。Ｒｅｖ．Ａの音声通話サービスは、そのサービスエリアがＲｅｖ．Ａ基地局の敷設エリアに限定される。そのため、敷設開始当初は、サービスエリアが限定的かつスポット的になることが予想される。その場合でも、ユーザの使い勝手が悪くならないよう、３ＧＰＰ２では、Ｒｅｖ．Ａから従来の回線交換用無線アクセス技術である１ｘシステムへのハンドオフ方式を検討している。Ｒｅｖ．Ａエリアで音声通話を開始したユーザが、Ｒｅｖ．Ａエリア外に移動した場合、１ｘにシステム間ハンドオフすることで、通話を継続することが可能になる。（３ＧＰＰ２寄書Ａ４０−２００６０１１１−００２ｒ２”ＨＨＯ  ｏｆ  ＶｏＩＰ  ｏｎ  ＨＲＰＤ  ｔｏ  １ｘ  Ｃｉｒｃｕｉｔ  Ｖｏｉｃｅ  Ｓｔａｇｅ  ２／３  Ｃｏｍｐｒｏｍｉｓｓ”（非特許文献１））
具体的手順を図１１を用いて説明する。端末１１０１はアクセスネットワークＡＮ１１０２、パケット制御機能ＰＣＦ１１０４を介してＶｏＩＰ通信中とする（ステップ１１０６）。端末１１０１はＡＮ１１０２から送信されるＲｅｖ．Ａ信号の受信レベルを測定しＡＮ１１０２に報告する（ステップ１１０７）。ＡＮ１１０２は報告された受信レベルが一定以下になった場合、Ｒｅｖ．Ａシステムでの音声通話の継続は困難であると判断し、１ｘへのハンドオフを端末１１０１に指示する（ステップ１１０８）。端末１１０１はＡＮ１１０２に１ｘハンドオフ開始を通知する（ステップ１１０９）。ＡＮ１１０２はＰＣＦ１１０４に通知する。ＰＣＦ１１０４はＭＳＣ１１０５に対し、１ｘシステムの基地局を擬似して発信要求を送信する（ステップ１１１０）。ＭＳＣ１１０５は発信処理を行い接続通知をＰＣＦ１１０４に送信する（ステップ１１１１）。次に、ＰＣＦ１１０４は１ｘ基地局間のハンドオフ要求をＭＳＣ１１０５に送信する（ステップ１１１２）。ＭＳＣ１１０５にはＰＣＦ１１０４が１ｘの基地局として見えており、かつ端末１１０１はその基地局配下で通話中として認識している。そのため、通常の１ｘ基地局間のハンドオフ処理を実行する。ＭＳＣ１１０５は移動先に当たる１ｘ基地局である１ｘＢＳ１１０３にハンドオフ要求を送信する（ステップ１１１３）。１ｘＢＳ１１０３は基地局のリソースを確保し、ハンドオフ要求応答をＭＳＣ１１０５に送信する（ステップ１１１４）。ＭＳＣ１１０５はＰＣＦ１１０４、ＡＮ１１０２を介して端末１１０１にハンドオフ指示を送信する（ステップ１１１５）。端末１１０１は１ｘＢＳ１１０３との間に無線リンクを確立する（ステップ１１１６）。そしてハンドオフ完了を１ｘＢＳ１１０３に送信する（ステップ１１１７）。１ｘＢＳ１１０３はＭＳＣ１１０５に送信する。以上でＲｅｖ．Ａから１ｘへのシステム間ハンドオフが完了する（ステップ１１１８）。【０００４】
システム間ハンドオフの別の従来技術には、特許文献１がある。これによると、ＰＤＣ、ＰＨＳ、ｃｄｍａ−Ｏｎｅなどの複数のシステムが利用可能なエリアにおいて、品質のよいシステムを選択して通信することが可能になる。【０００５】
具体的手順を説明する。端末は複数システムからの無線信号をほぼ同時に受信する。それぞれのシステムのＱｏＳ品質を受信レベル等から算出し、利用する上での優先順位を決めて通信中基地局に通知する。通信中基地局は、通知を受けたＱｏＳ品質のうち、自己に関するものだけは装置リソースなどを考慮して再計算し、優先順位を修正する。そしてその序列を移動関門交換機に通知する。移動関門交換機はＱｏＳ品質の序列で一番高いシステムの移動関門交換機に、空きチャネルの有無を問い合わせる。問い合わせを受けた移動関門交換機は、端末の現在位置をカバーする、当システム内の基地局を何らかの手段で特定し、空きチャネルの有無を問い合わせる。その結果を、問い合わせ元の移動関門交換機に通知する。問い合わせ結果が空きチャネル無の場合は、ＱｏＳ品質の序列で次のシステムの移動関門交換機に再度問い合わせを行う。このようにして空きチャネルのあるシステムが見つかると、それをハンドオフ先システムに決定する。ハンドオフ先システムでは基地局から移動関門交換機までの通話路設定を行う。【０００６】
また、特許文献２はＷ−ＣＤＭＡ、ＧＳＭ／ＧＰＲＳ、無線ＬＡＮを例に、特許文献１とほぼ同様の技術でシステム間ハンドオフを実現している。特許文献１と異なる主な点は、複数のシステムに接続した無線リソース管理装置を設けたことである。無線リソース管理装置は、端末の現在位置に応じて測定すべきシステムの周波数を測定制御コマンドで端末に通知する。これにより、端末が複数システムの受信レベルを測定するのが容易になる。また、無線リソース管理装置は、端末の受信レベル、移動速度、アプリケーション、セルの負荷状況などの評価項目毎に、端末とシステムの適正度を求めるための対応表を事前に持つ（特許文献２記載の例：受信レベルがランク５のとき、適正度＝１０、など）。各評価項目毎に算出した適正度の合計が、その端末とシステムの通信適正度であり、この値が最も大きいシステムにハンドオフさせる。【０００７】
【特許文献１】特開２００１−５４１６８号公報
【特許文献２】特開２００４−３４９９７６号公報
【非特許文献１】３ＧＰＰ２寄書Ａ４０−２００６０１１１−００２ｒ２”ＨＨＯ  ｏｆ  ＶｏＩＰ  ｏｎ  ＨＲＰＤ  ｔｏ  １ｘ  Ｃｉｒｃｕｉｔ  Ｖｏｉｃｅ  Ｓｔａｇｅ  ２／３  Ｃｏｍｐｒｏｍｉｓｓ”
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、受信レベルが十分なＲｅｖ．Ａエリア内でも、セクタ、時刻によっては端末が集中し、十分な品質で通信を行えないことがある。そのような場合に、システムが端末を強制的に１ｘにシステム間ハンドオフさせることができれば、ハンドオフさせた呼も、Ｒｅｖ．Ａシステムに留まる呼も、結果的に品質が改善してサービス性が良くなることが期待できる。【０００９】
しかし、３ＧＰＰ２の案では、Ｒｅｖ．Ａの受信レベルが弱くなりサービスエリア外となりそうなことを検出してシステム間ハンドオフを実行するため、Ｒｅｖ．Ａエリア内での通信負荷状況に応じてシステム間ハンドオフを行うことはできないという問題がある。【００１０】
また特許文献１記載の技術では、より良いシステムを望む端末が、システムの優先順位を基地局に通知することで、システム間ハンドオフを開始する。そのため、ネットワーク側が主体的にハンドオフさせる端末を選択できない、意図するタイミングでハンドオフさせられないという問題がある。また、端末の要求ベースでハンドオフを実行するのでシステム間ハンドオフが頻発し、システムの制御負荷が高くなるという問題がある。また、ハンドオフ先システムを決定するのは移動関門交換機であり、移動交換機が行う従来の基地局間ハンドオフとは独立の制御である。そのため、基地局間ハンドオフした後、許容できない通信品質しか提供できず、すぐさま通信を回復しなくてはならない場合に、即時の対応ができないという問題がある。【００１１】
一方、特許文献２記載の技術では、ネットワーク内の無線リソース管理装置が端末に測定制御コマンドを送信することでハンドオフを開始する。しかし、それが意図したシステム間ハンドオフになるとは限らないという問題がある。なぜなら、ハンドオフ先の決定方法が、対象端末にとっての通信適正度に基くものだからである。対象端末をシステム間ハンドオフさせれば他の複数の端末の品質が改善する場合でも、対象端末にとって最適な基地局が現在通信中の基地局であると、それができない。また、通信適正度は評価項目毎に算出した値の合計であるので、システム間ハンドオフを起こさせるという目的に照らしつつ、評価項目間で同じ値が同じ価値を持つよう対応表をチューニングする必要がある。これが非常に難しいという問題がある。また、ソフトハンドオフのように端末が複数の基地局を同時使用するハンドオフ方式には適合しないという問題がある。なぜなら、ソフトハンドオフ開始時点ではひとつの基地局で要求品質を完全に満たす必要がないにも係わらず、特許文献２記載の技術では単一基地局で品質が満たせるものを選択する傾向がある。つまり、不要なシステム間ハンドオフが発生する。【００１２】
本発明は、複数の無線アクセスシステムのサービスエリアが重なっている地域において、システム制御のために強制的に端末をシステム間ハンドオフさせることを目的とする。つまり、端末が接続中の基地局またはアクセスネットワークの通信リソースの状態に応じて、端末に対して十分なＱｏＳが提供できないと判断される場合に、基地局またはアクセスネットワーク側の主導でシステム間ハンドオフ手順を開始させる方法を提供することが目的である。
【課題を解決するための手段】
【００１３】
本発明は、無線基地局の通信リソースが足りないことを検出するリソース不足検出手段と、検出したとき、前記無線基地局を使用して通信中の端末の中から、現在使用している通信サービスが別の無線アクセスシステムの通信サービスで代替可能な端末を選択する、システム間ハンドオフ対象選択手段と、前記端末を前記別の無線アクセスシステムにハンドオフさせる、システム間ハンドオフ起動手段とを、基地局に設けたことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、基地局の通信リソースが不足する場合に、基地局判断で特定の端末を強制的に他システムにハンドオフさせることができる。したがって、Ｒｅｖ．Ａサービスエリア内において端末が集中したためにＲｅｖ．Ａの基地局に接続中の端末に満足な通信品質が得られないという状況を、能動的に回避することができる。また、端末ではなく基地局判断でシステム間ハンドオフを起動するので、システム間ハンドオフの発生を必要最小限に抑えることができる。端末が複数基地局と通信するソフトハンドオフ状態では、ハンドオフ先基地局に対する依存度が大きくなるまでは、ハンドオフ先基地局での通信リソースの確保が不十分でもシステム間ハンドオフを起動しない。したがって、ハンドオフ状態の端末が最終的にハンドオフ元基地局に戻る場合には、システム間ハンドオフを実行せずにすむ。また、基地局を閉塞したいときに通信中の端末を他システムにハンドオフさせることができるので、迅速な閉塞が可能になる。また、特定の種類の通信以外はシステム間ハンドオフさせることで、例えばＴＶ電話などに限定して基地局を使用させることが可能になる。
本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。
【発明を実施するための最良の形態】
【００１５】
まず、本発明を適用する移動通信システムについて、図２を用いて説明する。端末１０１は、２つの無線アクセスシステムが利用できる。一つは基地局制御装置（ＢＳＣ：Ｂａｓｅ  Ｓｔａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ）２１２、基地局（ＢＴＳ：Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｙｓｔｅｍ）１０５で構成する１ｘシステムである。１ｘシステムはサービスエリア２０２を形成する。ＢＳＣ２１２は、移動交換機（ＭＳＣ：Ｍｏｂｉｌｅ  Ｓｗｉｔｃｈｉｎｇ  Ｃｅｎｔｅｒ）２１３に接続する。端末１０１、ＢＴＳ１０５、ＢＳＣ２１２、ＭＳＣ２１３は回線交換方式の携帯電話システムである。【００１６】
別の無線アクセスシステムは、ＰＣＦ（ＰＣＦ：Ｐａｃｋｅｔ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、パケット制御機能）１０４、ＡＮ（Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０２で構成するＲｅｖ．Ａシステムである。Ｒｅｖ．Ａシステムはサービスエリア２０１を形成する。ＡＮ１０２はアクセスネットワーク基地局ＡＮ−ＢＴＳ２０３、アクセスネットワーク基地局上位局ＡＮ−ＢＳＣ２０４のように複数装置として実装してもよい。ＡＮ−ＢＴＳ２０３は無線の物理レイヤを終端する。ＡＮ−ＢＳＣ２０４は無線のリンクレイヤを終端する。それぞれ１ｘシステムのＢＴＳ１０５、ＢＳＣ２１２に相当する。ＡＮ１０２、ＡＮ−ＢＳＣ２０４はＰＣＦ１０４に接続する。ＰＣＦ１０４はＰＤＳＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）２０５に接続する。ＰＤＳＮ２０５は端末１０１との間にＰＰＰリンクを確立し、ユーザ認証や課金情報収集を行う。ＰＣＦ１０４は、無線リンクの状態に応じて、ＰＤＳＮ２０５から受信した端末１０１宛パケットを必要に応じてバッファリングする。ＳＩＰ２０６はＶｏＩＰ通信のための呼制御サーバである。端末１０１、ＡＮ１０２、ＰＣＦ１０４、ＰＤＳＮ２０５、ＳＩＰ２０６は、ＶｏＩＰ方式の携帯電話システムである。【００１７】
ＶｏＩＰ方式の携帯電話システムと回線交換方式の携帯電話システムはゲートウエイ（ＧＷ）２１０を介して相互接続している。また、ＶｏＩＰ方式の携帯電話システムはＧＷ２０７を介して固定電話システムと相互接続している。固定交換機（ＬＳ：Ｌｏｃａｌ  Ｓｗｉｔｃｈ）２０８は固定端末２０９を収容する。ＧＷ２０７、２１０は、回線交換シグナリングおよびベアラをＳＩＰシグナリングおよびＶｏＩＰベアラに変換／逆変換する。端末１０１は、ＶｏＩＰでも回線交換でも通信ができる、複数システム対応の端末であるとする。同一の携帯電話事業者が両方のシステムを用いてサービスを提供しており、この事業者によって端末が一括管理されているので、事業者は、いずれのシステムを用いても端末へのサービス提供を行なうことができる。【００１８】
ここで、端末１０１がＲｅｖ．Ａシステムを利用して、固定端末２０９と通信中であるとする。通信パスは端末１０１、ＡＮ１０２、ＰＣＦ１０４、ＰＤＳＮ２０５、ＧＷ２０７、ＬＳ２０８、固定端末２０９である。このとき、ＡＮ１０２の通信リソースが何らかの原因で不足した場合や使用不可になった場合にシステム間ハンドオフを起動するのが本発明である。システム間ハンドオフを実行すると、端末１０１と固定端末２０９の通信パスは、Ｒｅｖ．Ａシステムではなく１ｘシステム経由となる。つまり、端末１０１、ＢＴＳ１０５、ＢＳＣ２１２、ＭＳＣ２１３、ＧＷ２１０、ＧＷ２０７、ＬＳ２０８、固定端末２０９となる。【００１９】
次に、図６を用いてＡＮ１０２の構成を示す。電波送受信部６０１は、無線のＲＦ処理を行う。ベースバンド処理部６０２は、電波送受信部６０１でディジタル化した信号から、パケットデータを抽出する。パケット転送／シグナリング処理部６０３は、パケットデータを解析し、制御信号であれば無線制御やシグナリング制御を行う。ユーザデータであればＰＣＦ１０４に転送するために有線回線終端部６０４に送信する。有線回線終端部６０４は、有線回線のデータリンクレイヤ、物理レイヤを処理し、ＰＣＦ１０４とのパケットの送受信を行う。リソース管理部６０５は、ＡＮ１０２の通信リソースの状況を管理し、ハンドオフ制御部６０６の指示でリソースの確保、解放を行う。図７、図８はリソース管理部６０５で管理するテーブルである。【００２０】
図７はトラヒック状態テーブル７００であり、ＡＮ１０２のトラヒック状態を示す。総受信電力量７０１は、ＡＮ１０２に接続する全ての端末（該ＡＮ１０２とのみ接続している端末も、ソフトハンドオーバ中の端末も含む）からの総受信電力量を示す。この値が無線通信を安定して行える閾値（例えば７ｄＢ）を超えている場合、あらたな端末の通信を受け入れないようにする。総固定レート（上り）７０２と総固定レート（下り）７０３は、固定帯域が必要な通信でどの程度上りあるいは下り帯域を消費しているかを示す。オペレータが設定した閾値以上の場合、あらたな固定レート通信を受け入れないようにする。ベストエフォートフロー数７０４は、ＡＮ１０２を経由しているベストエフォートフロー数を示す。オペレータが設定した閾値以上の場合、ベストエフォート通信がこれ以上圧迫されないよう、あらたな固定レート通信を受け入れないようにする。【００２１】
図８はＱｏＳ制御状態テーブル８００である。ＱｏＳ制御の必要なフロー（ハンドオフ状態ではない端末もハンドオフ状態にある端末も含む）に対して、結果的に制御が失敗したフローの数を単位時間毎に数えたものである。テーブルは遅延時間８０１、ジッタ８０２、帯域８０３からなる。遅延時間８０１は、ＡＮ１０２がユーザパケットを受信してから送信するまでの時間が、フロー毎に定められた許容値を超えてしまったフロー数を示す。図８の例では、ディレイ許容値が定められたフローが２０あるのに対し、直近の単位時間において許容値を超えてしまったフローが１０あったことを示している。ジッタ８０２は、ＡＮ１０２がユーザパケットを受信してから送信するまでの時間のばらつきが、フロー毎に定められた許容値を超えてしまったフロー数を示す。図８の例では、ジッタ許容値が定められたフローが１５あるのに対し、直近の単位時間において目標を守れなかったフローが９あったことを示す。帯域８０３は、フロー毎に定められた許容最低帯域が、直近の単位時間において守れなかったフロー数を示す。図８の例では、許容最低帯域値が定められたフローが１５あるのに対し、許容される最低帯域を下まわったフローは０であることを示している。【００２２】
図６に戻る。ＡＮ１０２のハンドオフ制御部６０６は、通信リソースの状況に基づいてハンドオフの実行を決定し、ハンドオフのためのシグナリング、例えば１ｘハンドオフ指示を端末に送信する。システム管理部６０７はＡＮ１０２全体のヘルスチェックや、保守装置６０８とのインタフェースを持つ。保守装置６０８はＡＮ１０２を保守するためにオペレータが使用する端末である。本例ではＡＮ１０２と保守装置６０８は直接接続しているが、通信ネットワーク経由での接続でもよい。【００２３】
次に、システム間ハンドオフを起動する例を図１のシーケンス図を用いて説明する。本例は、端末１０１がＲｅｖ．Ａシステム内のＡＮ間ハンドオフを行ったとき、ハンドオフ先のＡＮで通信リソースが確保できなかった場合を示す。ハンドオフ元のＡＮをソースＡＮ１０２ｓ、ハンドオフ先のＡＮをターゲットＡＮ１０２ｔとする。端末１０１はＡＮ１０２ｓ、ＰＣＦ１０４を介して固定端末２０９と音声通話中とする（ステップ１０６）。端末１０１は、ターゲットＡＮ１０２ｔからの無線の受信レベルが一定以上になると、ハンドオフ開始のメッセージであるＲｏｕｔｅＵｐｄａｔｅをソースＡＮ１０２ｓに送信する（ステップ１０７）。ソースＡＮ１０２ｓはターゲットＡＮ１０２ｔにハンドオフ要求を送信する（ステップ１０８）。このとき、音声通話のためのＱｏＳが必要であることを通知する。ターゲットＡＮ１０２ｔは、リソース状況判定処理を行う（ステップ１０９）。【００２４】
図３にリソース状況判定処理１０９のフローチャートを示す。本処理は図６のリソース管理部６０５で実施する。まず、ステップ３０１でハンドオフ対象の通信が受け入れ禁止呼種であるか判定する。例えば景観地など、写真メールやテレビ電話の需要が大きいエリアでは、音声通話呼はＲｅｖ．Ａを使用させないようにしたい場合がある。その場合、音声通話呼を禁止呼種としてＡＮ１０２に事前設定しておけば、ステップ３０１の判定で結果をリソース空き無（ステップ３０７）に導くことができる。【００２５】
ステップ３０１で受け入れ禁止呼種でない場合は、図７のトラヒック状態テーブルの総受信電力量７０１が閾値未満であるか判定する（ステップ３０２）。閾値以上であると、ハンドオフを受け入れた場合ＡＮ１０２の無線通信制御が不安定になるので、リソース空き無とする（ステップ３０７）。閾値未満の場合、トラヒック状態テーブルの総固定レート（上り）７０２、（下り）７０３が閾値未満であるか判定する（ステップ３０３）。閾値以上であると、ハンドオフしてくる端末のための帯域はないと判断してリソース空き無となる（ステップ３０７）。閾値未満の場合、トラヒック状態テーブルのベストエフォートフロー数７０４が閾値未満であるか判定する（ステップ３０４）。閾値以上であると、ハンドオフしてくる端末のための帯域はないと判断してリソース空き無となる（ステップ３０７）。閾値未満の場合、図８のＱｏＳ制御状態テーブルのＱｏＳ制御失敗フロー数が閾値未満であるか判定する。閾値以上であると、ハンドオフしてくる端末を受け入れると、既存のフローのＱｏＳ品質が許容できないレベルになると判断して、リソース空き無となる（ステップ３０７）。閾値未満の場合、ハンドオフしてくる端末のためのリソースはあると判定する（ステップ３０６）。【００２６】
図１に戻り、ステップ１０９の結果、リソースに空きが無い場合は端末１０１のためのリソースが確保できない（ステップ１１０）。ターゲットＡＮ１０２ｔはソースＡＮ１０２ｓにリソース確保失敗のハンドオフ応答を送信する（ステップ１１１）。これで、ターゲットＡＮ１０２ｔとソースＡＮ１０２ｓの間にハンドオフ用通信パスが確立する。ただし、ターゲットＡＮ１０２ｔはリソースが確保できなかったので端末１０１の通信に関しＱｏＳ制御は行わない（サービス品質を保証はしないものの、端末が接続することは許可する）。ハンドオフ応答を受信したソースＡＮ１０２ｓは、端末１０１に、ターゲットＡＮ１０２ｔが端末１０１と通信可能になったことを意味する通信用チャネル割当完了ＴｒａｆｆｉｃＣｈａｎｎｅｌＡｓｉｇｎｍｅｎｔを送信する（ステップ１１２）。以上で端末１０１はハンドオフ状態となる。すなわち、端末１０１はソースＡＮ１０２ｓ、ターゲットＡＮ１０２ｔのうち、受信品質の良い方をリアルタイムに選択しなおし、選択したＡＮとの間で無線通信を行う。端末１０１は選択したＡＮの情報をＤＲＣ（Ｄａｔａ  Ｒａｔｅ  Ｃｏｎｔｒｏｌ）カバーと呼ぶ情報でソースＡＮ１０２ｓに通知する。ソースＡＮ１０２ｓは、ＤＲＣカバーが自分を指していれば、ハンドオフ前と同様に、端末１０１と無線通信する（ステップ１１３ａ）。ＤＲＣカバーがターゲットＡＮ１０２ｔを指していれば、ＰＣＦ１０４から受信した端末宛パケットをターゲットＡＮ１０２ｔに転送し、ターゲットＡＮ１０２ｔから端末１０１に無線送信する。また、ターゲット１０２ｔが端末１０１から受信したパケットは、ソースＡＮ１０２ｓに転送し、ソースＡＮ１０２ｓがＰＣＦ１０４に送信する（ステップ１１３ｂ）。このように、ハンドオフ状態ではターゲット１０２ｔ経由の通信が端末判断のもと行える。ターゲット１０２ｔは端末１０１のためのリソースが未確保の場合、ハンドオフ端末用リソース確保失敗処理ステップ１１４の処理を行う。【００２７】
図４はハンドオフ端末用リソース確保失敗処理１１４のフローチャートである。本処理はＡＮ１０２のハンドオフ制御部６０６で実施する。まず、リソースの空きをつくるため、システム間ハンドオフ対象とする端末を選択する（ステップ４０１）。ここでは、図１０のフロー状態テーブルを参照して選択する。【００２８】
図１０を説明する。本テーブルは、ターゲットＡＮ１０２ｔのリソース管理部６０５で管理し、端末毎に設ける。１ｘハンドオフ１００６は、そのテーブルに対応する端末の通信が、１ｘシステムを利用した通信で代替可能かどうかを示す。本情報は、端末がそのＡＮ経由の通信を開始したとき、サービス種別（音声通話など）に基いて設定する。単位時間あたりＱｏＳ制御失敗数１００５は、そのテーブルに対応する端末の通信において、ＱｏＳ制御が失敗した回数を示す。遅延時間１００１はＡＮ１０２を通過するのに要した時間が目標値を越えたパケット数を示す。ジッタ１００２はＡＮ１０２を通過するのに要した時間のばらつきが目標値を超えたパケット数を示す。帯域１００３は単位時間をさらに複数の時間帯に分割して、目標最低帯域が満たせなかった時間帯数を示す。ハンドオフばたつき率１００４は、ハンドオフ状態の端末に関して、ＤＲＣカバーの単位時間あたり変化回数を示す。ＡＮは端末のＤＲＣカバーが変化する度、その端末へのパケット転送経路を変更するので、ハンドオフばたつきが多い端末ほど、ＡＮに負荷をかけている。また、端末はどのＡＮからの電波も十分受信できておらず、通信品質が悪いと予想できる。【００２９】
図４に戻る。ステップ４０１では、まず、各端末のフロー状態テーブルの１ｘハンドオフ１００６を参照し、ハンドオフＯＫのものに対象を絞る。その中から、例えば、単位時間当たりＱｏＳ制御失敗数１００５が一番大きな端末を選択する。これは、ＱｏＳ制御失敗数が大きいものは、１ｘシステムを使用したほうが通信品質がむしろ良い可能性があるからである。また、別の例としては、ハンドオフばたつき率１００４が高いものを選択する。これは、ハンドオフばたつき率が高いものは制御負荷が高く、１ｘシステムを使用した方が負荷が小さくなる可能性があるからである。このように、Ｒｅｖ．Ａシステムによって提供されているサービス品質が既にあまり良くない状態にある端末や、基地局やアクセスネットワークにとって制御負荷が高い端末を優先的にハンドオフするようにする。【００３０】
このようにして選択したシステム間ハンドオフ対象の端末について、ＡＮ１０２の位置等からシステム間ハンドオフ先の１ｘセクタを特定する（ステップ４０３）。そしてシステム間ハンドオフ手順を開始する（ステップ４０４）。具体的には図１１の１ｘハンドオフ指示をＡＮ１０２が端末１０１に送信することで、３ＧＰＰ２が検討したシステム間ハンドオフの手順を開始する。接続されていた端末の一部をシステム間ハンドオフさせた結果、通信リソースに余裕ができた後、リソース確保できずにハンドオフ状態にあった端末１０１が、この時点でまだハンドオフ状態であるか判定する（ステップ４０５）。ハンドオフ状態であれば、リソース確保し、確保成功したらリソース確保成功通知をソースＡＮ１０２ｓに送信する（ステップ４０６、４０７）。ステップ４０６において、まだ十分なリソースがなかった場合は、ステップ４０１に戻る。ステップ４０５においてリソース未確保のハンドオフ端末１０１がソースＡＮ１０２ｓに戻っていきハンドオフ状態でなくなれば、処理を終了する。【００３１】
図１に戻る。ソースＡＮ１０２ｓは、端末１０１がハンドオフ状態の間、ＤＲＣカバー、すなわち端末１０１の無線通信相手のＡＮがどれかを監視している。端末１０１がターゲットＡＮ１０２ｔに十分近づくと、ＤＲＣカバーはソースＡＮ１０２ｓを指すことがなくなる。ある閾値以上の時間、ＤＲＣカバーがターゲットＡＮ１０２ｔを指し続けていた場合（ステップ１１５）、ステップ１１６に移る。ステップ１１６では、ターゲットＡＮ１０２ｔからリソース確保成功通知を受信済みかチェックする。受信済みの場合はターゲットＡＮ１０２ｔでのリソース確保が成功したということであるから、端末の通信経路からソースＡＮ１０２ｓを切り離す処理を行い、ハンドオフ状態を終了する（ステップ１１７）。一方ステップ１１６にてリソース確保成功通知を受信していなければ、ＱｏＳ制御が行われないターゲットＡＮ１０２ｔ経由の通信のみに端末１０１が頼っていることになる。そこで、ＡＮ１０２ｔの位置等から端末１０１が無線通信できる１ｘセクタを特定し（ステップ１１８）、システム間ハンドオフを開始する（ステップ１１９）。具体的には図１１の１ｘハンドオフ指示をＡＮ１０２が端末１０１に送信することで、３ＧＰＰ２が検討したシステム間ハンドオフの手順を開始する。システム間ハンドオフが成功すると、端末１０１はＢＴＳ１０５経由で音声通信を行う（ステップ１２０）。ソースＡＮ１０２ｓはターゲットＡＮ１０２ｔにハンドオフ終了を送信し（ステップ１２１）、ターゲットＡＮ１０２ｔは終了応答をソースＡＮ１０２ｓに送信する（ステップ１２２）。【００３２】
図５は、図１のソースＡＮ１０２ｓが、リソース確保失敗のハンドオフ応答を受信したとき（ステップ１１１）の処理のフローチャートである。これは図６のハンドオフ制御部６０６で実施する。まず、端末１０１のハンドオフ状態が続いているか判定する（ステップ５０１）。継続していなければ処理は終了である。継続している場合、ＤＲＣカバーがターゲットＡＮ１０２ｔを連続して指し続けているか判定する（ステップ５０２）。指し続けていなければ、ターゲットＡＮ１０２ｔのみに端末通信を頼っているわけではないので、端末１０１の通信品質の観点からはシステム間ハンドオフの必要はまだない。ステップ５０９に移り、ばたつき率が閾値を超えているか判定する（ステップ５０９）。これは図１０のフロー状態テーブルのハンドオフばたつき率１００４を参照して行う。ばたつき率が閾値以下の場合は、ハンドオフ制御負荷の観点でもシステム間ハンドオフの必要はなく、ステップ５０１に戻る。ステップ５０９においてばたつき率が閾値を超えている場合、ステップ５１０で１ｘ通信で代替可能か判定する。これは図１０のフロー状態テーブルの１ｘハンドオフ１００６を参照して行う。代替可能でない場合は、システム間ハンドオフを起動せずにステップ５０１に戻る。【００３３】
代替可能な場合は、ターゲットＡＮ１０２ｔの位置等から１ｘシステムにおいて端末１０１が位置するセクタを特定し（ステップ５０６）、システム間ハンドオフを実施する（ステップ５０７）。その後、ターゲットＡＮ１０２ｔにハンドオフ終了を送信して処理を終了する（ステップ５０８）。ステップ５０２においてＤＲＣカバーがターゲットＡＮ１０２ｔを指し続けている場合は、ステップ５０３でリソース確保成功通知をターゲットＡＮ１０２ｔから受信済みか判定する。受信済みの場合は、Ｒｅｖ．Ａシステム内ハンドオフ処理を実施する（ステップ５０４）。ステップ５０３においてリソース確保成功通知を未受信の場合は、端末１０１の通信が１ｘで代替可能か判定する（ステップ５０５）。代替可能でない場合は、システム内ハンドオフを実施し（ステップ５０４）処理を終了する。１ｘ通信で代替可能な場合は、ステップ５０６に移行して、１ｘセクタ特定後、システム間ハンドオフを実施する。【００３４】
図９は、図６の保守装置６０８からＡＮ１０２に対し閉塞コマンドあるいは音声サービス停止コマンドを投入したときの、ＡＮ１０２の処理のフローチャートである。本処理は図６のハンドオフ制御部６０６で実施する。閉塞コマンドあるいは音声サービス停止コマンドがシステム管理部６０７を介してハンドオフ制御部６０６に送信されると、まず、通信中の端末があるか判定する（ステップ９０１）。なければシステム間ハンドオフに関する処理を終了する。端末がある場合、フロー状態テーブルの１ｘハンドオフ１００６を参照して、１ｘ通信で代替可能か判定する（ステップ９０２）。代替可能でなければ、ステップ９０１に戻り他の端末を処理する。代替可能であれば、１ｘシステムにおける端末位置のセクタを特定し（ステップ９０３）、システム間ハンドオフを実施する（ステップ９０４）。そしてステップ９０１に戻り、他の端末を処理する。こうすることで可能な限り通信中の端末をＡＮ１０２配下から追い出すことで、迅速にＡＮ１０２の閉塞あるいは音声サービスの停止を行うことが可能になる。【００３５】
図１２は、ＡＮ１０２のハンドオフ制御部６０６が、周期的にリソース管理部６０５のトラヒック状態テーブル７００、ＱｏＳ制御状態テーブル８００をチェックし、通信リソース不足を検出した場合の、ＡＮ１０２のフローチャートである。図４のハンドオフ端末用リソース確保失敗処理１１４とほぼ同じである。ステップ１２０１では、まず、各端末のフロー状態テーブルの１ｘハンドオフ１００６を参照し、ハンドオフＯＫのものに対象を絞る。その中から、例えば、単位時間当たりＱｏＳ制御失敗数１００５が一番大きな端末を選択する。これは、ＱｏＳ制御失敗数が大きいものは、１ｘシステムを使用したほうが通信品質がむしろ良い可能性があるからである。また、別の例としては、ハンドオフばたつき率１００４が高いものを選択する。これは、ハンドオフばたつき率が高いものは制御負荷が高く、１ｘシステムを使用した方が負荷が小さくなる可能性があるからである。このように、Ｒｅｖ．Ａシステムによって提供されているサービス品質が既にあまり良くない状態にある端末や、基地局やアクセスネットワークにとって制御負荷が高い端末を優先的にハンドオフするようにする。【００３６】
このようにして選択したシステム間ハンドオフ対象の端末について、ＡＮ１０２の位置等からシステム間ハンドオフ先の１ｘセクタを特定する（ステップ１２０３）。そしてシステム間ハンドオフ手順を開始する（ステップ１２０４）。具体的には図１１の１ｘハンドオフ指示をＡＮ１０２が端末１０１に送信することで、３ＧＰＰ２が検討したシステム間ハンドオフの手順を開始する。接続されていた端末の一部をシステム間ハンドオフさせた結果、トラヒック状態テーブル７００、ＱｏＳ制御状態テーブル８００の各値が閾値以下になったか判定する（ステップ１２０６）。閾値以下になっていれば処理を終了する。閾値以下になっていなければステップ１２０１に戻る。【００３７】
以上の実施例ではＲｅｖ．Ａシステムから１ｘシステムへのシステム間ハンドオフについて説明したが、１ｘシステムからＲｅｖ．Ａシステム、あるいはＷｉＭＡＸなど他のアクセスシステム間とのハンドオフでも同様に実施することができる。【００３８】
なお、基地局が通信リソース不足を検出したことを配下の端末に同報し、個々の端末が他端末への影響（すなわち送信電力の大きさ）や通信品質レベル（ジッタが許容値以下か等）、自局が受けている通信サービス等に基づき自局がシステム間ハンドオフを行なうべきか否かを半自律的に判断することでシステム間ハンドオフを開始することもできる。
上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者に明らかである。
【図面の簡単な説明】
【００３９】
【図１】システム間ハンドオフを起動する手順の説明図である。
【図２】本発明を適用する移動通信システムの構成図である。
【図３】リソース状況判定処理のフローチャートである。
【図４】ハンドオフ端末用リソース確保失敗処理のフローチャートである。
【図５】リソース未確保ハンドオフ監視処理のフローチャートである。
【図６】無線基地局の構成図である。
【図７】無線基地局が管理するトラヒック状態テーブルの説明図である。
【図８】無線基地局が管理するＱｏＳ制御状態テーブルの説明図である。
【図９】閉塞処理におけるシステム間ハンドオフ起動処理のフローチャートである。
【図１０】無線基地局が管理するフロー状態テーブルの説明図である。
【図１１】３ＧＰＰ２が検討したシステム間ハンドオフ手順の説明図である。
【図１２】周期チェックでリソース不足を検出した場合のシステム間ハンドオフ起動処理のフローチャートである。
【符号の説明】
【００４０】
１０１  端末
１０２ｔ  ハンドオフ先無線基地局
１０２ｓ  ハンドオフ元無線基地局
１０９  リソース状況判定処理
１１４  ハンドオフ端末用リソース確保失敗処理
６０５  リソース管理部
６０６  ハンドオフ制御部
７００  トラヒック状態テーブル
８００  ＱｏＳ制御状態テーブル
１０００  フロー状態テーブル
【図１】
0004843031.tif 000002
【図２】
0004843031.tif 000003
【図３】
0004843031.tif 000004
【図４】
0004843031.tif 000005
【図５】
0004843031.tif 000006
【図６】
0004843031.tif 000007
【図７】
0004843031.tif 000008
【図８】
0004843031.tif 000009
【図９】
0004843031.tif 000010
【図１０】
0004843031.tif 000011
【図１１】
0004843031.tif 000012
【図１２】
0004843031.tif 000013