基地局及び発呼受付方法
【課題】発呼受付にかかる処理負荷を低減し処理時間を短縮する。
【解決手段】一実施形態による発呼受付方法は、第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて論理リソースを払い出す第２のレイヤが、払い出し可能な論理リソースを第１のレイヤに通知する段階と、第１のレイヤが、ユーザ端末からの発呼受付に応じて、第２のレイヤから払い出された払い出し可能な論理リソースを払い出す段階とを含む。
【解決手段】一実施形態による発呼受付方法は、第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて論理リソースを払い出す第２のレイヤが、払い出し可能な論理リソースを第１のレイヤに通知する段階と、第１のレイヤが、ユーザ端末からの発呼受付に応じて、第２のレイヤから払い出された払い出し可能な論理リソースを払い出す段階とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は移動体通信ネットワークに関し、特に基地局及びその発呼受付方法に関する。
【背景技術】
【０００２】
移動体通信ネットワークでは、基地局は、ユーザ端末が発した呼設定要求を受け付け、それに対して論理リソース番号を払い出し、払い出した論理リソース番号をユーザ端末に通知する。
【０００３】
図１は、従来の発呼受付方法１０を示すフロー図である。図１において、ユーザ端末（ＵＥ）が発した発呼受付（呼設定）要求信号は、発呼受付信号として基地局（ｅＮｏｄｅＢ）の下位のプラットフォーム（ＰＦ）レイヤにより受け付けられ、そのまま上位のアプリケーション（ＡＰ）レイヤに送られる。アプリケーション（ＡＰ）レイヤは、発呼受付要求ごとに払い出す論理リソースを管理している。プラットフォーム（ＰＦ）レイヤから発呼受付信号を受信すると、アプリケーション（ＡＰ）レイヤはそれに対して払い出す論理リソース番号を決定して、発呼受付応答信号としてプラットフォーム（ＰＦ）レイヤを介してユーザ端末（ＵＥ）に通知する。
【０００４】
ここで、プラットフォームレイヤとは、受信信号を解析して各機能部に振り分け、基地局全体の制御し、ユーザ端末の監視制御を行うレイヤである。一方、アプリケーションレイヤは、呼処理を行い、それに係わる論理リソースを管理するレイヤである。
【０００５】
図１に示すとおり、ユーザ端末（ＵＥ）から短期間に多数の発呼受付信号（１１）を受信した場合、ＰＦレイヤはその多数の発呼受付信号（１１）をＡＰレイヤに送り、ＡＰレイヤはその多数の発呼受付信号（１１）に対して論理リソース番号の払い出し処理を行い（１２）、ＰＦレイヤを介してユーザ端末（ＵＥ）に発呼受付応答（１３）を返す。
【０００６】
ＡＰレイヤが輻輳状態であると判断した場合（１４）、ＡＰレイヤは、その後、ユーザ端末（ＵＥ）からＰＦレイヤを介して受信する発呼受付信号を破棄する（１５、１６）ことにより輻輳制御を行う。ＰＦレイヤは、輻輳状態であるかないかに係わらず、ユーザ端末（ＵＥ）からの呼設定要求はすべて受け付け、ＡＰレイヤに送る。
【０００７】
図２は、従来の基地局２０を示すブロック図である。基地局２０は、図１のアプリケーション（ＡＰ）レイヤに対応するアプリケーション（ＡＰ）機能部２１と、プラットフォーム（ＰＦ）レイヤに対応するプラットフォーム（ＰＦ）機能部２２とを有する。
【０００８】
ＡＰ機能部２１は、ＰＦ機能部２２から受けた呼を処理する呼処理制御部２１１と、呼処理制御部２１１に論理リソース番号を通知する論理リソース処理部２１２と、論理リソース番号を管理して状態更新を行う論理リソース管理部２１３とを有する。
【０００９】
また、ＰＦ機能部２２は、ユーザ端末（ＵＥ）から受信した信号を解析する信号解析部２２１と、信号解析部２２１から出力された呼処理信号を受け付ける呼設定受付部２２２とを有する。ＰＦ機能部２２はさらに、基地局２０の構成要素全体を制御する装置制御部２２３と、信号解析部２２１から出力された保守監視信号に基づき監視制御する監視制御部２２４とを有する。
【００１０】
なお、移動体通信ネットワークにおける輻輳の判断について、交換機の呼処理プロセッサが輻輳か否かを判断する技術が知られている。
【特許文献１】特開平１−３１８３４３
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記の通り、従来の基地局においては、ＰＦレイヤはユーザ端末から受信した呼設定要求信号をすべてＡＰレイヤに送り、ＡＰレイヤが論理リソースを管理して発呼受付（呼設定）要求ごとに論理リソースを払い出している。ＡＰレイヤで輻輳が発生していても、ＰＦレイヤはユーザ端末から呼設定要求信号を受け付けると、それをＡＰレイヤに送ってしまっていた。これにより基地局の信号処理能力が費やされ、基地局全体としてのサービス品質の低下をきたしていた。特に、短時間に多数の発呼受付をした場合に、基地局内におけるＰＦレイヤとＡＰレイヤの間の信号の送受信に大きな処理能力が費やされ、これが他の機能にも影響を与えることがあった。
【課題を解決するための手段】
【００１２】
一実施形態による発呼受付方法は、第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて論理リソースを払い出す第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに払い出す段階と、前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから払い出された払い出し可能な論理リソースが残っているか判断し、残っていればその論理リソースを払い出す段階とを含む。
【００１３】
上記方法において、前記第１のレイヤが、前記第２のレイヤから払い出された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する段階をさらに含んでもよい。
【００１４】
また、他の実施形態による基地局は、ユーザ端末からの呼設定要求を受け付ける第１の機能部と、前記第１の機能部からの発呼受付に応じて論理リソースを払い出す第２の機能部とを有し、前記第２の機能部は、払い出し可能な論理リソースを前記第１の機能部に払い出す払い出し可能論理リソース処理部を有し、前記第１の機能部は、前記払い出し可能論理リソース処理部から払い出された論理リソースを管理する払い出し可能論理リソース管理部と、前記ユーザ端末からの発呼受付に応じて、前記払い出し可能な論理リソースが残っているか判断し、残っていればその論理リソースを払い出す論理リソース処理部とを有する。
【発明の効果】
【００１５】
発呼受付にかかる処理負荷を低減するとともに、処理時間を短縮することができる。
【発明を実施するための最良の形態】
【００１６】
図面を参照して本発明の実施形態を詳しく説明する。図面を通して同一または対応する構成要素には同じ参照記号を付した。
【００１７】
本実施形態は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）の無線基地局装置（以下、ｅＮｏｄｅＢ）における呼設定シーケンスにおいて、短時間に多数の発呼受付要求が発生した場合でも、基地局（ｅＮｏｄｅＢ）が輻輳すなわち過負荷状態に陥らないように論理リソースの払い出しをする発呼受付方法である。本実施形態は、ｅＮｏｄｅＢの無線基地局装置による発呼受付方法であるが、他の実施形態では、第３世代、第４世代、その他の無線基地局装置であってもよい。
【００１８】
図３は、一実施形態による発呼受付方法３００を示すフロー図である。このフロー図は、ユーザ端末（ＵＥ）と、基地局（ｅＮｏｄｅＢ）のプラットフォーム（ＰＦ）レイヤと、同じ基地局（ｅＮｏｄｅＢ）のアプリケーション（ＡＰ）レイヤの動作を示している。本実施形態では、様々なステップを一定の順序で生起するものとして説明するが、他の実施形態ではこれらのステップが本実施形態とは異なる順序で生起してもよい。また、これらのステップの一部が省略されてもよいし、他のステップが追加されてもよい。
【００１９】
本実施形態の発呼受付方法３００において、ＡＰレイヤは、装置の運用開始時に、払い出し可能な論理リソース数（ｍ）と論理リソース番号とを、ＰＦレイヤに通知する（ステップＳ３０１）。
【００２０】
ＡＰレイヤは、例えば、図４Ａに示す論理リソース払い出し管理テーブル４０をデータベースとして用いて、論理リソース番号とその論理リソースの状態とを対応付けて管理している。図４Ａに示した管理テーブル４０は、論理リソース番号１〜ｍがＰＦレイヤに「払い出し許可」したものであり、論理リソース番号ｍ＋１〜ｎが「未払い出し」であることを示している。ここで、ｍ≦ｎである。このように、ＡＰレイヤは管理している論理リソースの一部または全部をＰＦレイヤに払い出し許可することができる。
【００２１】
図３に戻り、ＰＦレイヤは、ＡＰレイヤから通知されたこれらのリソース情報により、ＰＦレイヤの論理リソース払い出し管理テーブルを更新する（ステップＳ３０３）。
【００２２】
ＰＦレイヤは、例えば、図４Ｂに示す論理リソース払い出し管理テーブル４５をデータベースとして用いて、論理リソース番号とその論理リソースの状態とを対応付けて管理している。図４Ｂに示した管理テーブル４５は、論理リソース１〜ｋがユーザ端末（ＵＥ）に「払い出し済み」であり、論理リソースｋ＋１〜ｍが「未払い出し（空き）」であることを示している。ここで、ｋ≦ｍである。
【００２３】
再び図３に戻り、ＰＦレイヤは、ユーザ端末（ＵＥ）から発呼受付要求を受信すると（ステップＳ３０５）、ＰＦレイヤの論理リソース払い出し管理テーブル４５を調べ、払い出し可能な（すなわち払い出しを許可する）論理リソースの有無を判断する（ステップＳ３０７）。
【００２４】
ステップＳ３０７において、払い出し可能な論理リソースが残っていなければ（Ｎｏ）、輻輳により論理リソースを払い出すことができない旨を発呼受付応答としてユーザ端末（ＵＥ）に返す（ステップＳ３０９）。すなわち、基地局（ｅＮｏｄｅＢ）が一時的に過負荷状態であり、ＰＦレイヤで管理している払い出し可能な論理リソースがなくなった場合は、ＰＦレイヤに対してＡＰレイヤから新たな論理リソース数と論理リソース番号が払い出されるまで、ＰＦレイヤはユーザ端末（ＵＥ）からの新たな発呼受付要求に応じない。その後、ＡＰレイヤにおける輻輳状態が解消され、ＰＦレイヤに対してＡＰレイヤから新たに払い出し可能な論理リソース数と論理リソース番号が通知（ステップＳ３２７）されることで、ＰＦレイヤはユーザ端末（ＵＥ）からの新たな発呼受付要求を受け付けることができるようになる。
【００２５】
ステップＳ３０７において、払い出し可能な論理リソースが残っていると判断した場合（Ｙｅｓ）、払い出す論理リソース番号（Ｃ−ＲＮＴＩ）を決定し（ステップＳ３１１）、払い出す論理リソース番号（Ｃ−ＲＮＴＩ＝ｘ）を発呼受付応答としてユーザ端末（ＵＥ）に返す（ステップＳ３１３）。ＰＦレイヤは、論理リソース払い出し管理テーブル４５（図４Ｂ参照）で管理している払い出し可能論理リソース数とリソース番号を更新する（ステップＳ３１５）。
【００２６】
ＰＦレイヤにより払い出された論理リソース番号（Ｃ−ＲＮＴＩ＝ｘ）は、ユーザ端末（ＵＥ）が呼設定要求を送信すると（ステップＳ３１７）、ＰＦレイヤを介して、ＡＰレイヤに通知される（ステップＳ３１９）。
【００２７】
ＡＰレイヤは、この呼設定要求によりＰＦレイヤが論理リソースを払い出したことを認識し、新たに払い出し可能な論理リソースがあるか判断する（ステップＳ３２１）。
【００２８】
ステップＳ３２１で払い出し可能な論理リソースがなく、輻輳状態であると判断すると（Ｎｏ）、ＡＰレイヤはユーザ端末（ＵＥ）から次の呼設定開始要求を受信するまで、論理リソースの払い出しに関しては何もしない。
【００２９】
ステップＳ３２１で払い出し可能な論理リソースがあると判断すると（Ｙｅｓ）、ＡＰレイヤは、払い出し可能な論理リソース数を算出し（ステップＳ３２５）、新たに払い出し可能な論理リソース数と論理リソース番号をＰＦレイヤに通知する（ステップＳ３２７）。これにより、ＰＦレイヤの払い出し可能論理リソースを動的に更新することができる。
【００３０】
ＰＦレイヤは、新たに払い出し可能な論理リソース数と論理リソース番号の通知を受けると、論理リソース払い出し管理テーブル４５（図４Ｂ参照）を更新する（ステップＳ３２９）。
【００３１】
このように、ＡＰレイヤは、輻輳状態を起こさずに一定時間内に同時に処理できる呼数分の論理リソース数と論理リソース番号を予めＰＦレイヤに通知し、ＰＦレイヤが発呼受付時に、その論理リソース数の呼数分だけ発呼受付処理を実施し、ＡＰレイヤには発呼受付要求を送らないことで、輻輳制御を行う。呼設定毎に払い出す論理リソースの管理の一部をＰＦレイヤが管理することで、ＡＰレイヤにおける輻輳や基地局装置（ｅＮｏｄｅＢ）全体の信号処理量の上昇による処理遅延やサービスへの影響を発生させることなく、安定した運用を可能とする。
【００３２】
なお、上記実施形態では、ユーザ端末（ＵＥ）からの呼設定開始要求（ステップＳ３１７、３１９）に応じて、ＡＰレイヤがさらにＰＦレイヤに払い出し可能な論理リソースがあるか判断した（ステップＳ３２１）。他の実施形態では、ＰＦレイヤが払い出し可能論理リソースが無いと判断したとき（ステップＳ３０７でＮｏ）、ＰＦレイヤがその旨ＡＰレイヤに通知し、ＡＰレイヤがその時点でＰＦレイヤに払い出し可能な論理リソースがあるか判断してもよい。
【００３３】
また、呼開放シーケンスの発生に応じて、ＡＰレイヤは開放された論理リソースの論理リソース払い出し管理テーブルの状態（図４Ａ参照）を「払い出し許可」から「未払い出し」に更新し、再びＡＰレイヤが管理する論理リソースとして管理することができる。一方、ＰＦレイヤは、開放された論理リソースをそのまま「払い出し済み」として管理し、再びＡＰレイヤから払い出し可能論理リソースとして通知された時に、「空き」に更新する。これにより、ＰＦレイヤは、開放された論理リソースをユーザ端末（ＵＥ）に再び払い出すことができる。
【００３４】
図５は、図３に示した発呼受付方法の変形例を示すフロー図である。図５に示した発呼受付方法５００は、Ｓ３０１からＳ３２９までは図３に示した発呼受付方法３００と同じであるが、払い出し可能論理リソースがあるか判断（ステップＳ３２１）するタイミングが異なる。具体的には、発呼受付方法３００では、ユーザ端末（ＵＥ）からの呼設定開始要求の受信に応じて払い出し可能論理リソースがあるか判断（ステップＳ３２１）していた。発呼受付方法５００では、ＡＰレイヤは、払い出し可能論理リソース数と論理リソース番号をＰＦレイヤに通知すると（ステップＳ３０１）、周期タイマーをスタートさせ（ステップＳ５０１）、その周期タイマーのタイムアウト通知の受信（ステップＳ５０３）に応じて払い出し可能論理リソースがあるか判断する（ステップＳ３２１）。
【００３５】
これにより、ＡＰレイヤは、ユーザ端末（ＵＥ）からの呼設定開始要求の受信にかかわらず、一定周期で払い出し可能論理リソースがあるか判断することができる。
【００３６】
図６は、図３に示した発呼受付方法の変形例を示すフロー図である。図６に示した発呼受付方法６００は、Ｓ３０１からＳ３２９までは図３に示した発呼受付方法３００と同じである。しかし、発呼受付方法６００では、ＡＰレイヤは、ユーザ端末（ＵＥ）から呼設定開始要求を受信すると（ステップＳ３１７、Ｓ３１９）、その呼設定開始要求に伴うリソース番号（Ｃ−ＲＮＴＩ＝ｘ）を取得し、ＡＰレイヤの論理リソース払い出し管理テーブル４０（図４Ａ参照）のその論理リソース番号の状態を「使用中」に変更する（ステップＳ６０１）。つまり、図３、図５にそれぞれ示した発呼受付方法３００、５００では、ＡＰレイヤは論理リソースを払い出したか否かしか管理していなかったが、図６に示す発呼受付方法６００では、ＡＰレイヤも論理リソースが使用中か否かを管理する。そして、呼開放シーケンスが発生して論理リソースが開放されると（ステップＳ６０３）、ＡＰレイヤは払い出し可能な論理リソースの有無を判断する（ステップＳ３２１）。
【００３７】
このように、ＡＰレイヤは、ＰＦレイヤとは別に、論理リソースが使用中か否かを管理することにより、呼開放シーケンスが発生したときに、使用中であった論理リソースが払い出し可能になったことを認識し、払い出し可能論理リソースの有無を判断することができる。これにより、発呼受付方法がよりいっそう動的かつ効率的になる。
【００３８】
図７は、一実施形態による基地局７０を示すブロック図である。図７に示した基地局（ｅＮｏｄｅＢ）７０は、図３、図５、図６を参照して説明した発呼受付方法を実施できる基地局であり、図３、図５、図６に示したアプリケーション（ＡＰ）レイヤに対応するアプリケーション（ＡＰ）機能部７１と、プラットフォーム（ＰＦ）レイヤに対応するプラットフォーム（ＰＦ）機能部７２とを有する。
【００３９】
ＡＰ機能部７１は、ＰＦ機能部７２から受信した発呼受付要求、呼設定開始要求を処理するとともに、ＰＦ機能部７２に発呼受付応答を送信する呼処理制御部２１１と、呼処理制御部２１１との間で論理リソース番号を通知する論理リソース処理部２１２と、論理リソースを管理して状態更新を行う論理リソース管理部２１３とを有する。
【００４０】
ＡＰ機能部７１はさらに、払い出し可能論理リソース処理部７１１を有する。この払い出し可能論理リソース処理部７１１は、論理リソース管理部２１３が管理しているＡＰレイヤの論理リソース払い出し管理テーブル４０（図４Ａ参照、図７には示さず）を参照し、ＰＦ機能部７２に払い出し可能論理リソース数とリソース番号を通知することができる。
【００４１】
ＰＦ機能部７２は、信号解析部２２１と、呼設定受付部２２２と、装置制御部２２３と、監視制御部２２４とを有する。信号解析部２２１は、ユーザ端末（ＵＥ）から受信した信号を解析して、その信号が関連する構成要素に送る。具体的には、ユーザ端末から受信した信号が呼処理信号である場合、その呼処理信号を処理する呼設定受付部２２２に送る。また、信号が装置制御信号である場合、その装置制御信号を処理して基地局（ｅＮｏｄｅＢ）７０全体を制御する装置制御部２２３に送る。また、信号が保守監視信号である場合、その保守監視信号に基づき監視制御する監視制御部２２４に送る。
【００４２】
ＰＦ機能部７２はさらに、ＡＰ機能部７１の払い出し可能論理リソース処理部７１１から通知された払い出し可能論理リソース数とリソース番号を、ＰＦレイヤの論理リソース払い出し管理テーブル４５（図４Ｂ参照、図７には示さず）を用いて管理する払い出し可能論理リソース管理部７２１を有する。
【００４３】
ＰＦ機能部７２はさらに、呼設定受付時に、払い出し可能論理リソース管理部７２１が管理する払い出し可能論理リソース番号を参照して、払い出し可能論理リソースがあるか否か判断し、あれば払い出す論理リソース番号を決定して呼設定受付部２２２に通知する論理リソース処理部７２２を有する。
【００４４】
以上説明したように、従来は発呼受付要求を受信するたびに上位層であるＡＰレイヤにおいて輻輳状態を判断し、輻輳状態であれば発呼受付要求を破棄していたため、下位層であるＰＦレイヤでは、輻輳状態であるにもかかわらず呼設定シーケンス処理をし続けていた。このため、基地局の処理能力が無駄に使用され、基地局装置全体のサービスを低下させていた。
【００４５】
本実施形態では、下位層であるＰＦレイヤにおいて論理リソースの払い出しを制御して、受け付ける発呼数をＡＰレイヤで同時処理が可能な呼数に制限できるため、輻輳状態を発生させることなく、また、基地局の処理能力を無駄にして処理遅延などを発生させることがなく、基地局装置全体としてのサービスを低下させることなく、安定した運用が可能となる。
【００４６】
同時に、従来はＡＰレイヤにおいて発呼受付ごとに論理リソース番号の払い出しを行っていた為、呼設定シーケンスにおいて、ユーザ端末（ＵＥ）への論理リソース番号の通知に時間がかかっていた。しかし、本実施形態では、ユーザ端末（ＵＥ）に対してＰＦレイヤが論理リソースを払い出すことで、呼設定シーケンスにかかる時間を短縮でき、合わせて無線リソースの有効利用できるとの効果も期待できる。
【００４７】
なお、上記の通り、本発明における輻輳制御方式は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に準拠した無線基地局装置のみではなく、Ｗ−ＣＤＭＡやＣＤＭＡ２０００に準拠した無線基地局や、第４世代の無線基地局等における一時的な過負荷による輻輳制御にも適用が可能である。
【００４８】
また、図３、図５、図６にそれぞれ示した発呼受付方法を、無線基地局装置に設けたマイクロプロセッサ、コントローラ、コンピュータ等により実行できることは当業者には明らかである。
【００４９】
以上、本発明の実施の形態について詳述したが、本発明は特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形及び変更が可能である。
【００５０】
なお、上記の実施形態について、以下の付記を記す。
（付記１）
受信信号を解析して振り分ける第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて、呼処理を行う第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知する段階と、
前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから通知された払い出し可能な論理リソースを払い出す段階とを含む発呼受付方法。
（付記２）
前記第１のレイヤが、前記第２のレイヤから通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する段階をさらに含む、付記１に記載の方法。
（付記３）
前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから通知された払い出し可能な論理リソースを払い出したとき、前記第２のレイヤから通知された払い出し可能な論理リソースを管理する第１のデータベースを更新する段階をさらに含む、付記１に記載の方法。
（付記４）
前記第２のレイヤが、すでに払い出した論理リソース以外に払い出し可能な論理リソースがあるか判断する段階と、
払い出し可能な論理リソースがあれば、それを前記第１のレイヤに通知する段階とを含む、付記１に記載の方法。
（付記５）
前記第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知してから、ユーザ端末からの呼設定開始要求の受信に応じて、すでに払い出した論理リソース以外に払い出し可能な論理リソースがあるか判断する、付記４に記載の方法。
（付記６）
前記第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに払い出して所定時間が経過してから、すでに通知した論理リソース以外に払い出し可能な論理リソースがあるか判断する、付記４に記載の方法。
（付記７）
前記第２のレイヤが、前記ユーザ端末からの呼設定開始要求に応じて、前記第１のレイヤに通知した払い出し可能な論理リソースを管理する第２のデータベースを更新する段階をさらに含む、付記１に記載の方法。
（付記８）
前記第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知してから呼開放シーケンスが発生し、払い出し可能な論理リソースがあるか判断する、付記４に記載の方法。
（付記９）
ユーザ端末からの受信信号を解析して振り分ける第１の機能処理部と、前記第１の機能処理部からの発呼受付に応じて論理リソースを払い出す、呼処理を行う第２の機能処理部とを有し、
前記第２の機能処理部は、払い出し可能な論理リソースを前記第１の機能処理部に通知する払い出し可能論理リソース処理部を有し、
前記第１の機能処理部は、前記払い出し可能論理リソース処理部から通知された論理リソースを管理する払い出し可能論理リソース管理部と、前記ユーザ端末からの発呼受付に応じて、前記払い出し可能な論理リソースが残っているか判断し、残っていればその論理リソースを払い出す論理リソース処理部とを有する基地局。
（付記１０）
前記論理リソース処理部は、前記払い出し可能論理リソース管理部が管理する、前記払い出し可能論理リソース処理部から通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する、付記９に記載の基地局。
【図面の簡単な説明】
【００５１】
【図１】従来の発呼受付方法を示すフロー図である。
【図２】従来の基地局を示すブロック図である。
【図３】一実施形態による発呼受付方法を示すフロー図である。
【図４Ａ】ＡＰレイヤの論理リソース払い出し管理テーブルを示す図である。
【図４Ｂ】ＰＦレイヤの論理リソース払い出し管理テーブルを示す図である。
【図５】図３に示した発呼受付方法の変形例を示すフロー図である。
【図６】図３に示した発呼受付方法の他の変形例を示すフロー図である。
【図７】一実施形態による基地局を示すブロック図である。
【符号の説明】
【００５２】
７０ 基地局
７１ ＡＰ機能部
７２ ＰＦ機能部
２１１ 呼処理制御部
２１２ 論理リソース処理部
２１３ 論理リソース管理部
２２１ 信号解析部
２２２ 呼設定受付部
２２３ 装置制御部
２２４ 監視制御部
７１１ 払い出し可能論理リソース処理部
７２１ 払い出し可能論理リソース管理部
７２２ 論理リソース処理部
【技術分野】
【０００１】
本発明は移動体通信ネットワークに関し、特に基地局及びその発呼受付方法に関する。
【背景技術】
【０００２】
移動体通信ネットワークでは、基地局は、ユーザ端末が発した呼設定要求を受け付け、それに対して論理リソース番号を払い出し、払い出した論理リソース番号をユーザ端末に通知する。
【０００３】
図１は、従来の発呼受付方法１０を示すフロー図である。図１において、ユーザ端末（ＵＥ）が発した発呼受付（呼設定）要求信号は、発呼受付信号として基地局（ｅＮｏｄｅＢ）の下位のプラットフォーム（ＰＦ）レイヤにより受け付けられ、そのまま上位のアプリケーション（ＡＰ）レイヤに送られる。アプリケーション（ＡＰ）レイヤは、発呼受付要求ごとに払い出す論理リソースを管理している。プラットフォーム（ＰＦ）レイヤから発呼受付信号を受信すると、アプリケーション（ＡＰ）レイヤはそれに対して払い出す論理リソース番号を決定して、発呼受付応答信号としてプラットフォーム（ＰＦ）レイヤを介してユーザ端末（ＵＥ）に通知する。
【０００４】
ここで、プラットフォームレイヤとは、受信信号を解析して各機能部に振り分け、基地局全体の制御し、ユーザ端末の監視制御を行うレイヤである。一方、アプリケーションレイヤは、呼処理を行い、それに係わる論理リソースを管理するレイヤである。
【０００５】
図１に示すとおり、ユーザ端末（ＵＥ）から短期間に多数の発呼受付信号（１１）を受信した場合、ＰＦレイヤはその多数の発呼受付信号（１１）をＡＰレイヤに送り、ＡＰレイヤはその多数の発呼受付信号（１１）に対して論理リソース番号の払い出し処理を行い（１２）、ＰＦレイヤを介してユーザ端末（ＵＥ）に発呼受付応答（１３）を返す。
【０００６】
ＡＰレイヤが輻輳状態であると判断した場合（１４）、ＡＰレイヤは、その後、ユーザ端末（ＵＥ）からＰＦレイヤを介して受信する発呼受付信号を破棄する（１５、１６）ことにより輻輳制御を行う。ＰＦレイヤは、輻輳状態であるかないかに係わらず、ユーザ端末（ＵＥ）からの呼設定要求はすべて受け付け、ＡＰレイヤに送る。
【０００７】
図２は、従来の基地局２０を示すブロック図である。基地局２０は、図１のアプリケーション（ＡＰ）レイヤに対応するアプリケーション（ＡＰ）機能部２１と、プラットフォーム（ＰＦ）レイヤに対応するプラットフォーム（ＰＦ）機能部２２とを有する。
【０００８】
ＡＰ機能部２１は、ＰＦ機能部２２から受けた呼を処理する呼処理制御部２１１と、呼処理制御部２１１に論理リソース番号を通知する論理リソース処理部２１２と、論理リソース番号を管理して状態更新を行う論理リソース管理部２１３とを有する。
【０００９】
また、ＰＦ機能部２２は、ユーザ端末（ＵＥ）から受信した信号を解析する信号解析部２２１と、信号解析部２２１から出力された呼処理信号を受け付ける呼設定受付部２２２とを有する。ＰＦ機能部２２はさらに、基地局２０の構成要素全体を制御する装置制御部２２３と、信号解析部２２１から出力された保守監視信号に基づき監視制御する監視制御部２２４とを有する。
【００１０】
なお、移動体通信ネットワークにおける輻輳の判断について、交換機の呼処理プロセッサが輻輳か否かを判断する技術が知られている。
【特許文献１】特開平１−３１８３４３
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記の通り、従来の基地局においては、ＰＦレイヤはユーザ端末から受信した呼設定要求信号をすべてＡＰレイヤに送り、ＡＰレイヤが論理リソースを管理して発呼受付（呼設定）要求ごとに論理リソースを払い出している。ＡＰレイヤで輻輳が発生していても、ＰＦレイヤはユーザ端末から呼設定要求信号を受け付けると、それをＡＰレイヤに送ってしまっていた。これにより基地局の信号処理能力が費やされ、基地局全体としてのサービス品質の低下をきたしていた。特に、短時間に多数の発呼受付をした場合に、基地局内におけるＰＦレイヤとＡＰレイヤの間の信号の送受信に大きな処理能力が費やされ、これが他の機能にも影響を与えることがあった。
【課題を解決するための手段】
【００１２】
一実施形態による発呼受付方法は、第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて論理リソースを払い出す第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに払い出す段階と、前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから払い出された払い出し可能な論理リソースが残っているか判断し、残っていればその論理リソースを払い出す段階とを含む。
【００１３】
上記方法において、前記第１のレイヤが、前記第２のレイヤから払い出された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する段階をさらに含んでもよい。
【００１４】
また、他の実施形態による基地局は、ユーザ端末からの呼設定要求を受け付ける第１の機能部と、前記第１の機能部からの発呼受付に応じて論理リソースを払い出す第２の機能部とを有し、前記第２の機能部は、払い出し可能な論理リソースを前記第１の機能部に払い出す払い出し可能論理リソース処理部を有し、前記第１の機能部は、前記払い出し可能論理リソース処理部から払い出された論理リソースを管理する払い出し可能論理リソース管理部と、前記ユーザ端末からの発呼受付に応じて、前記払い出し可能な論理リソースが残っているか判断し、残っていればその論理リソースを払い出す論理リソース処理部とを有する。
【発明の効果】
【００１５】
発呼受付にかかる処理負荷を低減するとともに、処理時間を短縮することができる。
【発明を実施するための最良の形態】
【００１６】
図面を参照して本発明の実施形態を詳しく説明する。図面を通して同一または対応する構成要素には同じ参照記号を付した。
【００１７】
本実施形態は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）の無線基地局装置（以下、ｅＮｏｄｅＢ）における呼設定シーケンスにおいて、短時間に多数の発呼受付要求が発生した場合でも、基地局（ｅＮｏｄｅＢ）が輻輳すなわち過負荷状態に陥らないように論理リソースの払い出しをする発呼受付方法である。本実施形態は、ｅＮｏｄｅＢの無線基地局装置による発呼受付方法であるが、他の実施形態では、第３世代、第４世代、その他の無線基地局装置であってもよい。
【００１８】
図３は、一実施形態による発呼受付方法３００を示すフロー図である。このフロー図は、ユーザ端末（ＵＥ）と、基地局（ｅＮｏｄｅＢ）のプラットフォーム（ＰＦ）レイヤと、同じ基地局（ｅＮｏｄｅＢ）のアプリケーション（ＡＰ）レイヤの動作を示している。本実施形態では、様々なステップを一定の順序で生起するものとして説明するが、他の実施形態ではこれらのステップが本実施形態とは異なる順序で生起してもよい。また、これらのステップの一部が省略されてもよいし、他のステップが追加されてもよい。
【００１９】
本実施形態の発呼受付方法３００において、ＡＰレイヤは、装置の運用開始時に、払い出し可能な論理リソース数（ｍ）と論理リソース番号とを、ＰＦレイヤに通知する（ステップＳ３０１）。
【００２０】
ＡＰレイヤは、例えば、図４Ａに示す論理リソース払い出し管理テーブル４０をデータベースとして用いて、論理リソース番号とその論理リソースの状態とを対応付けて管理している。図４Ａに示した管理テーブル４０は、論理リソース番号１〜ｍがＰＦレイヤに「払い出し許可」したものであり、論理リソース番号ｍ＋１〜ｎが「未払い出し」であることを示している。ここで、ｍ≦ｎである。このように、ＡＰレイヤは管理している論理リソースの一部または全部をＰＦレイヤに払い出し許可することができる。
【００２１】
図３に戻り、ＰＦレイヤは、ＡＰレイヤから通知されたこれらのリソース情報により、ＰＦレイヤの論理リソース払い出し管理テーブルを更新する（ステップＳ３０３）。
【００２２】
ＰＦレイヤは、例えば、図４Ｂに示す論理リソース払い出し管理テーブル４５をデータベースとして用いて、論理リソース番号とその論理リソースの状態とを対応付けて管理している。図４Ｂに示した管理テーブル４５は、論理リソース１〜ｋがユーザ端末（ＵＥ）に「払い出し済み」であり、論理リソースｋ＋１〜ｍが「未払い出し（空き）」であることを示している。ここで、ｋ≦ｍである。
【００２３】
再び図３に戻り、ＰＦレイヤは、ユーザ端末（ＵＥ）から発呼受付要求を受信すると（ステップＳ３０５）、ＰＦレイヤの論理リソース払い出し管理テーブル４５を調べ、払い出し可能な（すなわち払い出しを許可する）論理リソースの有無を判断する（ステップＳ３０７）。
【００２４】
ステップＳ３０７において、払い出し可能な論理リソースが残っていなければ（Ｎｏ）、輻輳により論理リソースを払い出すことができない旨を発呼受付応答としてユーザ端末（ＵＥ）に返す（ステップＳ３０９）。すなわち、基地局（ｅＮｏｄｅＢ）が一時的に過負荷状態であり、ＰＦレイヤで管理している払い出し可能な論理リソースがなくなった場合は、ＰＦレイヤに対してＡＰレイヤから新たな論理リソース数と論理リソース番号が払い出されるまで、ＰＦレイヤはユーザ端末（ＵＥ）からの新たな発呼受付要求に応じない。その後、ＡＰレイヤにおける輻輳状態が解消され、ＰＦレイヤに対してＡＰレイヤから新たに払い出し可能な論理リソース数と論理リソース番号が通知（ステップＳ３２７）されることで、ＰＦレイヤはユーザ端末（ＵＥ）からの新たな発呼受付要求を受け付けることができるようになる。
【００２５】
ステップＳ３０７において、払い出し可能な論理リソースが残っていると判断した場合（Ｙｅｓ）、払い出す論理リソース番号（Ｃ−ＲＮＴＩ）を決定し（ステップＳ３１１）、払い出す論理リソース番号（Ｃ−ＲＮＴＩ＝ｘ）を発呼受付応答としてユーザ端末（ＵＥ）に返す（ステップＳ３１３）。ＰＦレイヤは、論理リソース払い出し管理テーブル４５（図４Ｂ参照）で管理している払い出し可能論理リソース数とリソース番号を更新する（ステップＳ３１５）。
【００２６】
ＰＦレイヤにより払い出された論理リソース番号（Ｃ−ＲＮＴＩ＝ｘ）は、ユーザ端末（ＵＥ）が呼設定要求を送信すると（ステップＳ３１７）、ＰＦレイヤを介して、ＡＰレイヤに通知される（ステップＳ３１９）。
【００２７】
ＡＰレイヤは、この呼設定要求によりＰＦレイヤが論理リソースを払い出したことを認識し、新たに払い出し可能な論理リソースがあるか判断する（ステップＳ３２１）。
【００２８】
ステップＳ３２１で払い出し可能な論理リソースがなく、輻輳状態であると判断すると（Ｎｏ）、ＡＰレイヤはユーザ端末（ＵＥ）から次の呼設定開始要求を受信するまで、論理リソースの払い出しに関しては何もしない。
【００２９】
ステップＳ３２１で払い出し可能な論理リソースがあると判断すると（Ｙｅｓ）、ＡＰレイヤは、払い出し可能な論理リソース数を算出し（ステップＳ３２５）、新たに払い出し可能な論理リソース数と論理リソース番号をＰＦレイヤに通知する（ステップＳ３２７）。これにより、ＰＦレイヤの払い出し可能論理リソースを動的に更新することができる。
【００３０】
ＰＦレイヤは、新たに払い出し可能な論理リソース数と論理リソース番号の通知を受けると、論理リソース払い出し管理テーブル４５（図４Ｂ参照）を更新する（ステップＳ３２９）。
【００３１】
このように、ＡＰレイヤは、輻輳状態を起こさずに一定時間内に同時に処理できる呼数分の論理リソース数と論理リソース番号を予めＰＦレイヤに通知し、ＰＦレイヤが発呼受付時に、その論理リソース数の呼数分だけ発呼受付処理を実施し、ＡＰレイヤには発呼受付要求を送らないことで、輻輳制御を行う。呼設定毎に払い出す論理リソースの管理の一部をＰＦレイヤが管理することで、ＡＰレイヤにおける輻輳や基地局装置（ｅＮｏｄｅＢ）全体の信号処理量の上昇による処理遅延やサービスへの影響を発生させることなく、安定した運用を可能とする。
【００３２】
なお、上記実施形態では、ユーザ端末（ＵＥ）からの呼設定開始要求（ステップＳ３１７、３１９）に応じて、ＡＰレイヤがさらにＰＦレイヤに払い出し可能な論理リソースがあるか判断した（ステップＳ３２１）。他の実施形態では、ＰＦレイヤが払い出し可能論理リソースが無いと判断したとき（ステップＳ３０７でＮｏ）、ＰＦレイヤがその旨ＡＰレイヤに通知し、ＡＰレイヤがその時点でＰＦレイヤに払い出し可能な論理リソースがあるか判断してもよい。
【００３３】
また、呼開放シーケンスの発生に応じて、ＡＰレイヤは開放された論理リソースの論理リソース払い出し管理テーブルの状態（図４Ａ参照）を「払い出し許可」から「未払い出し」に更新し、再びＡＰレイヤが管理する論理リソースとして管理することができる。一方、ＰＦレイヤは、開放された論理リソースをそのまま「払い出し済み」として管理し、再びＡＰレイヤから払い出し可能論理リソースとして通知された時に、「空き」に更新する。これにより、ＰＦレイヤは、開放された論理リソースをユーザ端末（ＵＥ）に再び払い出すことができる。
【００３４】
図５は、図３に示した発呼受付方法の変形例を示すフロー図である。図５に示した発呼受付方法５００は、Ｓ３０１からＳ３２９までは図３に示した発呼受付方法３００と同じであるが、払い出し可能論理リソースがあるか判断（ステップＳ３２１）するタイミングが異なる。具体的には、発呼受付方法３００では、ユーザ端末（ＵＥ）からの呼設定開始要求の受信に応じて払い出し可能論理リソースがあるか判断（ステップＳ３２１）していた。発呼受付方法５００では、ＡＰレイヤは、払い出し可能論理リソース数と論理リソース番号をＰＦレイヤに通知すると（ステップＳ３０１）、周期タイマーをスタートさせ（ステップＳ５０１）、その周期タイマーのタイムアウト通知の受信（ステップＳ５０３）に応じて払い出し可能論理リソースがあるか判断する（ステップＳ３２１）。
【００３５】
これにより、ＡＰレイヤは、ユーザ端末（ＵＥ）からの呼設定開始要求の受信にかかわらず、一定周期で払い出し可能論理リソースがあるか判断することができる。
【００３６】
図６は、図３に示した発呼受付方法の変形例を示すフロー図である。図６に示した発呼受付方法６００は、Ｓ３０１からＳ３２９までは図３に示した発呼受付方法３００と同じである。しかし、発呼受付方法６００では、ＡＰレイヤは、ユーザ端末（ＵＥ）から呼設定開始要求を受信すると（ステップＳ３１７、Ｓ３１９）、その呼設定開始要求に伴うリソース番号（Ｃ−ＲＮＴＩ＝ｘ）を取得し、ＡＰレイヤの論理リソース払い出し管理テーブル４０（図４Ａ参照）のその論理リソース番号の状態を「使用中」に変更する（ステップＳ６０１）。つまり、図３、図５にそれぞれ示した発呼受付方法３００、５００では、ＡＰレイヤは論理リソースを払い出したか否かしか管理していなかったが、図６に示す発呼受付方法６００では、ＡＰレイヤも論理リソースが使用中か否かを管理する。そして、呼開放シーケンスが発生して論理リソースが開放されると（ステップＳ６０３）、ＡＰレイヤは払い出し可能な論理リソースの有無を判断する（ステップＳ３２１）。
【００３７】
このように、ＡＰレイヤは、ＰＦレイヤとは別に、論理リソースが使用中か否かを管理することにより、呼開放シーケンスが発生したときに、使用中であった論理リソースが払い出し可能になったことを認識し、払い出し可能論理リソースの有無を判断することができる。これにより、発呼受付方法がよりいっそう動的かつ効率的になる。
【００３８】
図７は、一実施形態による基地局７０を示すブロック図である。図７に示した基地局（ｅＮｏｄｅＢ）７０は、図３、図５、図６を参照して説明した発呼受付方法を実施できる基地局であり、図３、図５、図６に示したアプリケーション（ＡＰ）レイヤに対応するアプリケーション（ＡＰ）機能部７１と、プラットフォーム（ＰＦ）レイヤに対応するプラットフォーム（ＰＦ）機能部７２とを有する。
【００３９】
ＡＰ機能部７１は、ＰＦ機能部７２から受信した発呼受付要求、呼設定開始要求を処理するとともに、ＰＦ機能部７２に発呼受付応答を送信する呼処理制御部２１１と、呼処理制御部２１１との間で論理リソース番号を通知する論理リソース処理部２１２と、論理リソースを管理して状態更新を行う論理リソース管理部２１３とを有する。
【００４０】
ＡＰ機能部７１はさらに、払い出し可能論理リソース処理部７１１を有する。この払い出し可能論理リソース処理部７１１は、論理リソース管理部２１３が管理しているＡＰレイヤの論理リソース払い出し管理テーブル４０（図４Ａ参照、図７には示さず）を参照し、ＰＦ機能部７２に払い出し可能論理リソース数とリソース番号を通知することができる。
【００４１】
ＰＦ機能部７２は、信号解析部２２１と、呼設定受付部２２２と、装置制御部２２３と、監視制御部２２４とを有する。信号解析部２２１は、ユーザ端末（ＵＥ）から受信した信号を解析して、その信号が関連する構成要素に送る。具体的には、ユーザ端末から受信した信号が呼処理信号である場合、その呼処理信号を処理する呼設定受付部２２２に送る。また、信号が装置制御信号である場合、その装置制御信号を処理して基地局（ｅＮｏｄｅＢ）７０全体を制御する装置制御部２２３に送る。また、信号が保守監視信号である場合、その保守監視信号に基づき監視制御する監視制御部２２４に送る。
【００４２】
ＰＦ機能部７２はさらに、ＡＰ機能部７１の払い出し可能論理リソース処理部７１１から通知された払い出し可能論理リソース数とリソース番号を、ＰＦレイヤの論理リソース払い出し管理テーブル４５（図４Ｂ参照、図７には示さず）を用いて管理する払い出し可能論理リソース管理部７２１を有する。
【００４３】
ＰＦ機能部７２はさらに、呼設定受付時に、払い出し可能論理リソース管理部７２１が管理する払い出し可能論理リソース番号を参照して、払い出し可能論理リソースがあるか否か判断し、あれば払い出す論理リソース番号を決定して呼設定受付部２２２に通知する論理リソース処理部７２２を有する。
【００４４】
以上説明したように、従来は発呼受付要求を受信するたびに上位層であるＡＰレイヤにおいて輻輳状態を判断し、輻輳状態であれば発呼受付要求を破棄していたため、下位層であるＰＦレイヤでは、輻輳状態であるにもかかわらず呼設定シーケンス処理をし続けていた。このため、基地局の処理能力が無駄に使用され、基地局装置全体のサービスを低下させていた。
【００４５】
本実施形態では、下位層であるＰＦレイヤにおいて論理リソースの払い出しを制御して、受け付ける発呼数をＡＰレイヤで同時処理が可能な呼数に制限できるため、輻輳状態を発生させることなく、また、基地局の処理能力を無駄にして処理遅延などを発生させることがなく、基地局装置全体としてのサービスを低下させることなく、安定した運用が可能となる。
【００４６】
同時に、従来はＡＰレイヤにおいて発呼受付ごとに論理リソース番号の払い出しを行っていた為、呼設定シーケンスにおいて、ユーザ端末（ＵＥ）への論理リソース番号の通知に時間がかかっていた。しかし、本実施形態では、ユーザ端末（ＵＥ）に対してＰＦレイヤが論理リソースを払い出すことで、呼設定シーケンスにかかる時間を短縮でき、合わせて無線リソースの有効利用できるとの効果も期待できる。
【００４７】
なお、上記の通り、本発明における輻輳制御方式は、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に準拠した無線基地局装置のみではなく、Ｗ−ＣＤＭＡやＣＤＭＡ２０００に準拠した無線基地局や、第４世代の無線基地局等における一時的な過負荷による輻輳制御にも適用が可能である。
【００４８】
また、図３、図５、図６にそれぞれ示した発呼受付方法を、無線基地局装置に設けたマイクロプロセッサ、コントローラ、コンピュータ等により実行できることは当業者には明らかである。
【００４９】
以上、本発明の実施の形態について詳述したが、本発明は特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形及び変更が可能である。
【００５０】
なお、上記の実施形態について、以下の付記を記す。
（付記１）
受信信号を解析して振り分ける第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて、呼処理を行う第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知する段階と、
前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから通知された払い出し可能な論理リソースを払い出す段階とを含む発呼受付方法。
（付記２）
前記第１のレイヤが、前記第２のレイヤから通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する段階をさらに含む、付記１に記載の方法。
（付記３）
前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから通知された払い出し可能な論理リソースを払い出したとき、前記第２のレイヤから通知された払い出し可能な論理リソースを管理する第１のデータベースを更新する段階をさらに含む、付記１に記載の方法。
（付記４）
前記第２のレイヤが、すでに払い出した論理リソース以外に払い出し可能な論理リソースがあるか判断する段階と、
払い出し可能な論理リソースがあれば、それを前記第１のレイヤに通知する段階とを含む、付記１に記載の方法。
（付記５）
前記第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知してから、ユーザ端末からの呼設定開始要求の受信に応じて、すでに払い出した論理リソース以外に払い出し可能な論理リソースがあるか判断する、付記４に記載の方法。
（付記６）
前記第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに払い出して所定時間が経過してから、すでに通知した論理リソース以外に払い出し可能な論理リソースがあるか判断する、付記４に記載の方法。
（付記７）
前記第２のレイヤが、前記ユーザ端末からの呼設定開始要求に応じて、前記第１のレイヤに通知した払い出し可能な論理リソースを管理する第２のデータベースを更新する段階をさらに含む、付記１に記載の方法。
（付記８）
前記第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知してから呼開放シーケンスが発生し、払い出し可能な論理リソースがあるか判断する、付記４に記載の方法。
（付記９）
ユーザ端末からの受信信号を解析して振り分ける第１の機能処理部と、前記第１の機能処理部からの発呼受付に応じて論理リソースを払い出す、呼処理を行う第２の機能処理部とを有し、
前記第２の機能処理部は、払い出し可能な論理リソースを前記第１の機能処理部に通知する払い出し可能論理リソース処理部を有し、
前記第１の機能処理部は、前記払い出し可能論理リソース処理部から通知された論理リソースを管理する払い出し可能論理リソース管理部と、前記ユーザ端末からの発呼受付に応じて、前記払い出し可能な論理リソースが残っているか判断し、残っていればその論理リソースを払い出す論理リソース処理部とを有する基地局。
（付記１０）
前記論理リソース処理部は、前記払い出し可能論理リソース管理部が管理する、前記払い出し可能論理リソース処理部から通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する、付記９に記載の基地局。
【図面の簡単な説明】
【００５１】
【図１】従来の発呼受付方法を示すフロー図である。
【図２】従来の基地局を示すブロック図である。
【図３】一実施形態による発呼受付方法を示すフロー図である。
【図４Ａ】ＡＰレイヤの論理リソース払い出し管理テーブルを示す図である。
【図４Ｂ】ＰＦレイヤの論理リソース払い出し管理テーブルを示す図である。
【図５】図３に示した発呼受付方法の変形例を示すフロー図である。
【図６】図３に示した発呼受付方法の他の変形例を示すフロー図である。
【図７】一実施形態による基地局を示すブロック図である。
【符号の説明】
【００５２】
７０ 基地局
７１ ＡＰ機能部
７２ ＰＦ機能部
２１１ 呼処理制御部
２１２ 論理リソース処理部
２１３ 論理リソース管理部
２２１ 信号解析部
２２２ 呼設定受付部
２２３ 装置制御部
２２４ 監視制御部
７１１ 払い出し可能論理リソース処理部
７２１ 払い出し可能論理リソース管理部
７２２ 論理リソース処理部
【特許請求の範囲】
【請求項１】
受信信号を解析して振り分ける第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて、呼処理を行う第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知する段階と、
前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから通知された払い出し可能な論理リソースを払い出す段階とを含む発呼受付方法。
【請求項２】
前記第１のレイヤが、前記第２のレイヤから通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する段階をさらに含む、請求項１に記載の方法。
【請求項３】
前記第２のレイヤが、すでに払い出した論理リソース以外に払い出し可能な論理リソースがあるか判断する段階と、
払い出し可能な論理リソースがあれば、それを前記第１のレイヤに通知する段階とを含む、請求項１または２に記載の方法。
【請求項４】
ユーザ端末からの受信信号を解析して振り分ける第１の機能処理部と、前記第１の機能処理部からの発呼受付に応じて論理リソースを払い出す、呼処理を行う第２の機能処理部とを有し、
前記第２の機能処理部は、払い出し可能な論理リソースを前記第１の機能処理部に通知する払い出し可能論理リソース処理部を有し、
前記第１の機能処理部は、前記払い出し可能論理リソース処理部から通知された論理リソースを管理する払い出し可能論理リソース管理部と、前記ユーザ端末からの発呼受付に応じて、前記払い出し可能な論理リソースを払い出す論理リソース処理部とを有する基地局。
【請求項５】
前記論理リソース処理部は、前記払い出し可能論理リソース管理部が管理する、前記払い出し可能論理リソース処理部から通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する、請求項４に記載の基地局。
【請求項１】
受信信号を解析して振り分ける第１のレイヤを介してユーザ端末から受け付けた発呼受付に応じて、呼処理を行う第２のレイヤが、払い出し可能な論理リソースを前記第１のレイヤに通知する段階と、
前記第１のレイヤが、ユーザ端末からの発呼受付に応じて、前記第２のレイヤから通知された払い出し可能な論理リソースを払い出す段階とを含む発呼受付方法。
【請求項２】
前記第１のレイヤが、前記第２のレイヤから通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する段階をさらに含む、請求項１に記載の方法。
【請求項３】
前記第２のレイヤが、すでに払い出した論理リソース以外に払い出し可能な論理リソースがあるか判断する段階と、
払い出し可能な論理リソースがあれば、それを前記第１のレイヤに通知する段階とを含む、請求項１または２に記載の方法。
【請求項４】
ユーザ端末からの受信信号を解析して振り分ける第１の機能処理部と、前記第１の機能処理部からの発呼受付に応じて論理リソースを払い出す、呼処理を行う第２の機能処理部とを有し、
前記第２の機能処理部は、払い出し可能な論理リソースを前記第１の機能処理部に通知する払い出し可能論理リソース処理部を有し、
前記第１の機能処理部は、前記払い出し可能論理リソース処理部から通知された論理リソースを管理する払い出し可能論理リソース管理部と、前記ユーザ端末からの発呼受付に応じて、前記払い出し可能な論理リソースを払い出す論理リソース処理部とを有する基地局。
【請求項５】
前記論理リソース処理部は、前記払い出し可能論理リソース管理部が管理する、前記払い出し可能論理リソース処理部から通知された払い出し可能論理リソースが残っているか判断し、残っていなければ、前記ユーザ端末に輻輳状態を通知する、請求項４に記載の基地局。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−８１０７６（Ｐ２０１０−８１０７６Ａ）
【公開日】平成２２年４月８日（２０１０．４．８）
【国際特許分類】
【出願番号】特願２００８−２４４６１７（Ｐ２００８−２４４６１７）
【出願日】平成２０年９月２４日（２００８．９．２４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年４月８日（２０１０．４．８）
【国際特許分類】
【出願日】平成２０年９月２４日（２００８．９．２４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]