(57)【要約】  或る実施例では、装置は、上りリンクサービスフローについて予約帯域割り当ての予約帯域量を含む動的サービス追加メッセージを受信するように適合された接続制御モジュールを含む。予約帯域割り当ては、２つ以上のVoIP（Voice  over  Internet  Protocol）呼に対応可能であり、上りリンクサービスフローは、IEEE（Institute  of  Electrical  and  ElectronicEngineers）802.16標準に実質的に従う。装置はまた、呼制御モジュールに結合され、VoIP接続の接続要求メッセージを生成するように適合された呼セッションモジュールを含む。接続制御モジュールは、接続要求メッセージに応じて、VoIP接続の予約帯域割り当ての呼セッション帯域部分を活性化する動的サービス変更要求メッセージを送信するように更に適合される。
2010519830.tif 000002
【特許請求の範囲】
【請求項１】
上りリンクサービスフローについて予約帯域割り当ての予約帯域量を含む動的サービス追加メッセージを受信するように適合された接続制御モジュールであり、前記予約帯域割り当ては、２つ以上のVoIP（Voice  over  Internet  Protocol）呼に対応可能であり、前記上りリンクサービスフローは、IEEE（Institute  of  Electrical  and  Electronic
Engineers）802.16標準に実質的に従う接続制御モジュールと、
前記呼制御モジュールに結合され、VoIP接続の接続要求メッセージを生成するように適合された呼セッションモジュールと
を有し、
前記接続制御モジュールは、前記接続要求メッセージに応じて、前記VoIP接続の前記予約帯域割り当ての呼セッション帯域部分を活性化する動的サービス変更要求メッセージを送信するように更に適合される装置。
【請求項２】
前記接続制御モジュールにより受信された前記動的サービス追加メッセージは、前記接続制御モジュールにより受信された動的サービス追加要求メッセージであり、
前記接続制御モジュールは、前記動的サービス追加要求メッセージに応じて、前記予約帯域割り当ての必要性を確認する動的サービス追加応答メッセージを送信するように更に適合される、請求項１に記載の装置。
【請求項３】
前記上りリンクサービスフローは、UGS（Unsolicited  Grant  Service）フロー又はrtPS（Real-Time  Polling  Service）フローのうち選択されたものである、請求項２に記載の装置。
【請求項４】
前記接続制御モジュールは、前記動的サービス変更要求メッセージを送信した後に、前記予約帯域割り当ての前記呼セッション帯域部分の活性化を示す動的サービス変更応答メッセージを受信するように更に適合される、請求項２に記載の装置。
【請求項５】
前記接続制御モジュールは、前記動的サービス追加要求メッセージを受信すると、前記予約帯域量で利用可能帯域量を初期化するように更に適合され、
前記接続制御モジュールは、前記接続要求メッセージを受信すると、前記利用可能帯域量が前記呼セッション帯域部分の帯域量以上であるか否かを決定し、前記呼セッション帯域部分の帯域量以上である場合、前記動的サービス変更要求メッセージを送信するように更に適合され、
前記接続制御モジュールは、前記動的サービス変更応答メッセージを受信すると、前記呼セッション帯域部分の帯域量だけ前記利用可能帯域量を減少させるように更に適合される、請求項４に記載の装置。
【請求項６】
前記呼セッションモジュールは、前記接続要求メッセージを生成した後に、前記VoIP接続について切断要求メッセージを生成するように更に適合され、
前記接続制御モジュールは、前記切断要求メッセージに応じて、他の動的サービス変更要求メッセージを送信し、前に活性化された呼セッション帯域部分を非活性化し、前に活性化された呼セッション帯域部分の非活性化を示す他の動的サービス変更応答を受信するように更に適合される、請求項５に記載の装置。
【請求項７】
前記接続制御モジュールは、前記他の動的サービス変更応答メッセージを受信すると、前記非活性化された呼セッション帯域部分の帯域量だけ前記利用可能帯域量を増加させるように更に適合される、請求項６に記載の装置。
【請求項８】
前記接続制御モジュールは、前記動的サービス追加応答メッセージを送信すると、初期状態から許可状態に遷移するように更に適合され、
前記接続制御モジュールは、前記動的サービス変更要求メッセージを送信すると、前記許可状態から活性化待機状態に遷移するように更に適合され、
前記接続制御モジュールは、前記動的サービス変更応答メッセージを受信すると、前記活性化待機状態からアクティブ状態に遷移するように更に適合され、
前記接続制御モジュールは、前記他の動的サービス変更要求メッセージを送信すると、前記アクティブ状態から非活性化待機状態に遷移するように更に適合され、
前記接続制御モジュールは、前記他の動的サービス応答メッセージを受信すると、前記非活性化待機状態から前記許可状態に遷移するように更に適合される、請求項６に記載の装置。
【請求項９】
前記接続制御モジュールは、前記接続制御モジュールが前記初期状態にあるときに、関連するプロビジョニング済の帯域を有し、前記プロビジョニング済の帯域は、前記予約帯域割り当て以上である、請求項８に記載の装置。
【請求項１０】
前記呼セッションモジュールは、前記VoIP接続の前記接続要求メッセージを生成した後に、他のVoIP接続の他の接続要求メッセージを生成するように適合され、
前記接続制御モジュールは、前記他の接続要求メッセージに応じて、他の動的サービス変更要求メッセージを送信し、前記他のVoIP接続について前記予約帯域割り当ての他の呼セッション帯域部分を活性化するように更に適合され、
前記上りリンクサービスフローは、前記接続制御モジュールが前記他の呼セッション帯域部分の活性化を示す他の動的サービス変更メッセージを受信したときに、前記２つのVoIP接続を含む、請求項４に記載の装置。
【請求項１１】
前記呼セッションモジュールは、SIP（Session  Initiation  Protocol）である、請求項１に記載の装置。
【請求項１２】
前記SIPモジュールはSIPプロキシであり、
前記装置は、前記SIPプロキシに結合された少なくとも２つのIP（Internet  Protocol）電話を更に有する、請求項１１に記載の装置。
【請求項１３】
前記SIPモジュールはSIPユーザエージェントであり、
前記装置は、前記SIPモジュールに結合された少なくとも２つのアナログ電話を更に有する、請求項１１に記載の装置。
【請求項１４】
前記接続制御モジュールは、基地局から前記動的サービス追加メッセージを受信し、前記基地局に前記動的サービス変更要求メッセージを送信するように更に適合される、請求項１に記載の装置。
【請求項１５】
複数のVoIP（Voice  over  Internet  Protocol）呼を含むことができる予約帯域割り当てを加入者局の上りリンクサービスフローに提供し、前記上りリンクサービスフローは、IEEE（Institute  of  Electrical  and  Electronic
Engineers）802.16標準に実質的に従い、
第１のVoIP呼の第１の接続要求メッセージに応じて、前記加入者局により前記予約帯域割り当ての第１の呼セッション帯域部分を活性化し、
少なくとも第２のVoIP呼の少なくとも第２の接続要求メッセージに応じて、前記予約帯域割り当ての第２の呼セッション帯域部分を活性化することを有する方法。
【請求項１６】
前記加入者局の前記上りリンクサービスフローの提供は、
前記加入者局により、前記予約帯域割り当ての量を含む動的サービス追加要求メッセージを受信し、
前記加入者局により、前記予約帯域割り当ての必要性を確認する動的サービス追加応答メッセージを送信することにより、前記動的サービス追加要求メッセージに応答することを含む、請求項１５に記載の方法。
【請求項１７】
前記第１の呼セッション帯域部分の活性化は、
前記加入者局により、動的サービス変更要求メッセージを送信し、前記第１の呼セッション帯域部分を活性化し、
前記加入者局により、前記第１の呼セッション帯域部分の活性化を示す動的サービス変更応答メッセージを受信することを含む、請求項１６に記載の方法。
【請求項１８】
前記第１の呼セッション帯域部分の活性化は、
前記加入者局により、前記予約帯域割り当ての量で利用可能帯域量を初期化し、
前記第１の接続要求メッセージを受信すると、前記加入者局により、前記利用可能帯域量が前記第１の呼セッション帯域部分の量以上であるか否かを決定し、前記第１の呼セッション帯域部分の量以上である場合、前記加入者局により、前記動的サービス変更要求メッセージを送信し、前記第１の呼セッション帯域部分を活性化し、
前記動的サービス変更応答メッセージを受信すると、前記加入者局により、前記呼セッション帯域部分の量だけ前記利用可能帯域量を減少させることを更に含む、請求項１７に記載の方法。
【請求項１９】
前記加入者局により、前に活性化された第１の呼セッション帯域部分を有するアクティブな第１のVoIP呼の切断要求メッセージを受信し、
前記切断要求メッセージに応じて、前記加入者局により、他の動的サービス変更要求メッセージを送信し、前に活性化された第１の呼セッション帯域部分を非活性化し、
前記加入者局により、前に活性化された第１の呼セッション帯域部分の非活性化を示す他の動的サービス変更応答メッセージを受信することを更に有する、請求項１８に記載の方法。
【請求項２０】
前記他の動的サービス変更要求メッセージを受信すると、前記加入者局により、前記第１の呼セッション帯域部分の量だけ前記利用可能帯域量を増加させることを更に有する、請求項１９に記載の方法。
【請求項２１】
前記第１及び第２の呼セッション帯域部分の活性化は、基地局で前記第１及び第２の呼セッション帯域部分を活性化することを含む、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施例は、電子装置の分野に関し、特に通信装置に関する。
【背景技術】
【０００２】
ブロードバンド無線アクセス（BWA：broadband  wireless  access）システムは、通信ネットワークでポイント・ツー・マルチポイント通信システムを提供する。典型的には、BWAシステムは、無線基地局（BS：base  station）から１つ以上の加入者局（SS：subscriber  station）に通信信号を送信するために、マイクロ波及びミリメートル波技術を使用する。BWAシステムは、ビデオ、音声、テレビ、インターネット及び他のデータ信号を含む様々な形式のデジタル信号を送信し得る。
【０００３】
802.16ファミリーの標準は、固定、ポータブル及び／又は移動BWAネットワーク（例えば、2004年に公開されたIEEE標準802.16及びその後の改訂等）を提供するために、IEEE（Institute  of  Electrical  and  Electronic  Engineers）により作成されている。WiMAX（Worldwide  Interoperability  for  Microwave  Access）フォーラムは、IEEE802.16標準に基づくブロードバンド無線ネットワークの展開を促進している。特に、WiMAXフォーラムは、ブロードバンド無線装置の互換性及び相互運用性を確保する。便宜的に、“802.16”及び“WiMAX”という用語は、この開示を通じて、IEEE802.16の一式の無線インタフェース標準を示すために同義的に使用され得る。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
WiMAXネットワークは、音声、ビデオ及びデータサービスを提供するように設計された無線ネットワークに集約（convergence）されてもよい。集約されたネットワーク（WiMAXネットワーク等）のかなりの利点は、異なるサービス間での最も貴重なリソース（無線スペクトル）の共有にある。しかし、WiMAXネットワークでの無線ネットワークの集約はまた、そのポイント・ツー・マルチポイント技術のため、いくつかの課題がある。BSから全てのSS（クライアント）への下りリンクトラヒックのブロードキャストはあまり問題にならない。課題は、複数のSSの間の上りリンク送信の仲裁（arbitration）と、異なるサービスに必要なサービス品質（QoS：Quality  of  Service）での上りリンク帯域の割り当てとにある。
【図面の簡単な説明】
【０００５】
【図１】本発明の様々な実施例によるBWAシステムの説明図
【図２】本発明の様々な実施例によるBWAシステムのブロック図
【図３】本発明の一実施例に従ってCPEに結合されたIP電話を有するBWAシステムのブロック図
【図４】本発明の一実施例に従ってCPEに結合されたアナログ電話を有するBWAシステムのブロック図
【図５】本発明の実施例による接続制御モジュールの状態遷移図
【図６】本発明の様々な実施例による初期状態から始まる接続制御モジュールのフローチャート
【図７】本発明の様々な実施例による許可状態から始まる接続制御モジュールのフローチャート
【図８】本発明の様々な実施例による活性化待機状態から始まる接続制御モジュールのフローチャート
【図９】本発明の様々な実施例による非活性化待機状態から始まる接続制御モジュールのフローチャート
【図１０】本発明の様々な実施例によるアクティブ状態から始まる接続制御モジュールのフローチャート
【図１１】本発明の様々な実施例に従って予約帯域割り当てを加入者局に提供する信号図
【図１２】本発明の一実施例による図３のCPEの発信呼設定の信号図
【図１３】本発明の一実施例による図３のCPEの発信呼解放の信号図
【図１４】本発明の一実施例による図３のCPEの着信呼設定の信号図
【図１５】本発明の一実施例による図３のCPEの着信呼解放の信号図
【図１６】本発明の一実施例による図４のCPEの発信呼設定の信号図
【図１７】本発明の一実施例による図４のCPEの発信呼解放の信号図
【図１８】本発明の一実施例による図４のCPEの着信呼設定の信号図
【図１９】本発明の一実施例による図４のCPEの着信呼解放の信号図
【図２０】本発明の様々な実施例を組み込んだCPEシステムのブロック図
【発明を実施するための形態】
【０００６】
以下の説明では、例示目的で、本発明の開示の実施例の完全な理解を提供するために複数の詳細が示されている。しかし、これらの特定の詳細は、本発明の開示の実施例を実施するために必要でないことが当業者に明らかになる。他にも、本発明の開示の実施例をあいまいにしないように、周知の電気構造及び回路はブロック図形式で示されていない。“結合”という用語は、直接接続、間接接続又は間接通信を含むものとする。
【０００７】
図１を参照すると、本発明の様々な実施例による例示的なブロードバンド無線アクセス（BWA：Broadband  Wireless  Access）システム10が示されている。BWAシステム10は、地理的領域をカバーするために、無線セルを使用してもよい。BWAシステム10は、遠隔側位置の複数の加入者局（SS：subscriber  station）14に送信する中央側位置の基地局（BS：base  station）12を含んでもよく、各SS14は、加入社宅内装置（CPE：Customer  Premise  equipment）を有してもよい。一般的に、BWAシステム10は、２種類のCPE16及び18で示されてもよい。しかし、実装に応じて、双方の種類のCPE16及び18がBWA10に存在してもよい。所与のSS14は、CPE16又は18を含んでもよい。更に、各種類の１つのみのCPEが示されているが、BWAシステム10に複数のいずれかの種類のCPEが存在してもよい。BWAシステム10の実施例は、IEEE802.16標準の通信プロトコルに従って相互に通信してもよい。一般的に、この802.16標準は、無線メトロポリタンエリアネットワーク（MAN：Metropolitan  Area  Network）で固定及び／又は移動SS（SS14等）の無線ブロードバンドアクセスを規定してもよい。無線MANもWiMAXネットワークと呼ばれることがある。
【０００８】
第１の種類のCPE16は、それに結合された１つ以上のインターネットプロトコル（IP）電話22（例えば、CPE16のEthernet（登録商標）接続により結合される）を有してもよく、或る実施例では、それに結合された１つ以上の計算装置24（パーソナルコンピュータ等）を有してもよい。或る実施例では、各IP電話22は、セッション・イニシエーション・プロトコル（SIP：Session  Initiation  Protocol）ユーザエージェント（図示せず）を含んでもよい。第２の種類のCPE18は、それに結合された１つ以上のアナログ電話26（例えば、CPE18のRJ11インタフェースにより結合される）を有してもよく、或る実施例では、それに結合された１つ以上の計算装置24（パーソナルコンピュータ等）を有してもよい。IP電話22及びアナログ電話26は、VoIP（Voice  over  Internet  Protocol）呼を生じる。SIPは、１つ以上のIP電話22でセッションを生成、変更及び終了するアプリケーションレイヤの制御（シグナリング）プロトコルである（IETF（Internet  Engineering  Task  Force）のSIPワーキンググループからのRFC（Request  For  Comments）3261仕様参照）。しかし、SIP以外のプロトコルがVoIP呼セッションに使用されてもよい。
【０００９】
BS12は、SS14から無線伝送媒体30を介して無線通信信号を受信し、SS14に無線通信信号を送信する受信／送信アンテナ28を有してもよい。CPE16及び18は、それぞれアンテナ31及び32を含んでもよい。アンテナ31及び32は、BS12から無線通信信号を受信してもよく、BS12に無線通信信号を送信してもよい。BS12は、セル内でSS14へのトラヒック及びSS14からのトラヒックを収集してもよい。BS12は、有線又は無線バックボーンネットワーク36（インターネット等）へのインタフェースを有する装置34（BS上りリンクスケジューラを含む）を含んでもよく、これにより、所与のSS14とバックボーンネットワーク36との間のリンクを提供してもよい。次に、バックボーンネットワーク36は、IP電話22及び計算装置24で示すように、それに結合された複数の装置を有してもよい。
【００１０】
本発明の様々な実施例によるCPE16及び18は、VoIPのサポートを対象とする。特に、CPE16及び18は、IP電話22又はアナログ電話26から生じたVoIPトラヒックを、音声サービス用に調整された差別化サービス品質（differentiated  QoS）を備えた接続で伝送するように構成される。本発明の様々な実施例は、IEEE802.16標準の関連する部分の説明の後に、以下に説明するようにCPE16及び18に実装され得る２段階の呼制御手順を使用することにより、WiMAXでVoIPを展開する。
【００１１】
IEEE802.16標準は、パケット（SSにより送信される上りリンクパケット又はBSにより送信される下りリンクパケット）の一方向伝送を提供する媒体アクセス制御（MAC：Media  Access  Control）伝送サービスとして“サービスフロー”を規定する。サービスフローは、一式のQoSパラメータ（待ち時間、ジッタ及びスループット保証等）により特徴付けられる。BSは、サービスフローに規定されたQoSパラメータセットに従って所与のQoSを提供する。一般的に、IEEE802.16標準に記載されたサービスフローは、３つの状態を有してもよい（各サービスフローは３つの状態のいずれに遷移してもよい）。(a)プロビジョニング済（Provisioned）：サービスフローのこの状態は、例えばネットワーク管理システムによるプロビジョニングを介して知られる。(b)許可（Admitted）：サービスフローのこの状態は、SSについてBSにより予約されたリソースを有する。(c)アクティブ（Active）：サービスフローのこの状態は、SSについてBSにより委ねられたリソースを有する。IEEE802.16は、プロビジョニング済セット、許可セット及び／又はアクティブセットへのQoSパラメータセットの適切な適用を指定するパラメータ：QoSパラメータセットタイプ（“セットタイプ（Set  Type）”）を各サービスフローの符号化内に含む。802.16標準は、２段階の活性化モデル（Activation  Model）を提案しており、帯域のようなりソースは、最初に“許可（admit）”され、エンドツーエンドのネゴシエーションが終了したときに、リソースが“活性化（activate）”される。
【００１２】
IEEE802.16標準は、それぞれVoIP呼が設定又は解放（tear-down）されたときに動的にサービスフローを生成又は削除するために使用され得る動的サービス追加（DSA：Dynamic  Service  Addition）メッセージと動的サービス削除（DSD：Dynamic  Service  Deletion）メッセージとを規定する。しかし、１つ以上のVoIP呼に帯域を予約するためにDSA/DSDを使用することは、以下の問題を有する。すなわち、(a)加入者が許可されていないサービスを加入者が使用することを回避するために、各DSA要求は、許可のために許可サーバに転送される必要がある。これは、各VoIP呼設定にかなりのオーバーヘッド及び遅延を追加することがある。(b)２つのサービスフロー識別子（SFID：Service  Flow  Identifier）が各VoIP呼に割り当てられて解放される必要がある。これは、BSを通じたSFID管理の余分なオーバーヘッド及び複雑性を追加することがある。これはまた、２つのSSが同じSFIDを使用できることを意味する。これは、アカウントの記録がSFIDに基づくため、アカウント管理に混乱を生じることがある。(c)BSはどのくらいのDSA/DSDメッセージがVoIP呼について加入者から送信されるかを予測できないため、BSの全体帯域幅は、異なるサービスに最適に分配されないことがある。これは、VoIP呼の拒否又は帯域の浪費を生じることがある。(d)また、呼毎にDSA/DSDメッセージを処理するためのオーバーヘッドをBSスケジューラに追加することがある。以下に説明するように、本発明の様々な実施例によるCPE16及び18は、以下に説明する他の手法（２段階の呼制御手順）を取る。
【００１３】
IEEE802.16（WiMAX）はまた、QoS要件を区別するために、帯域要求／許可処理を使用した上りリンクスケジューリングサービスを規定する。以下は、様々なサービスについてのIEEE802.16のサービスクラスである。UGS（Unsolicited  Grant  Service）、rtPS（Real-Time  Polling  Service）、nrtPS（Non-Real-Time  Polling  Service）及びBE（Best  Effort  Service）がある。各サービスクラスは、所望のQoSのサービスフローを要求するためにSS又はBSにより使用されるサービスフローの特性又は属性（QoSパラメータを含む）のグループを含む。UGSは、T1/E1エミュレーション及び静寂抑制（silence  suppression）のないVoIPのように、固定ビットレート（CBR：constant  bit  rate）又はCBRのようなサービスフローをサポートするように設計される。換言すると、UGSは、固定の単位のデータを定期的に生成するサービスを伝達するように調整される。従って、BSは、SSからの明示的な帯域要求なしに、予約帯域割り当て（帯域許可）を先取り的に定期的にスケジューリングする。rtPS（Real-Time  Polling  Service）は、MPEGビデオのように、定期的に可変サイズのデータパケットを生成するリアルタイムサービスフローをサポートするように設計される。SSは、サービスフローのリアルタイム要件を満たすために十分な頻度でポーリングされる。UGS又はrtPSは、本発明の様々な実施例に従って、CPEで使用されてもよく、この場合、或る実施例ではUGSと呼ばれる。一般的に、nrtPS（Non-Real-Time  Polling  Service）及びBE（Best  Effort  Service）はVoIP呼に適していない。
【００１４】
図２を参照すると、本発明の様々な実施例に従って図１のBWAシステムのSS12及び１つのSS14を表す概略ブロック図が示されている。概念的に、BS12及びSS14は、仮想の線44により上りリンク部分40と下りリンク部分42とに分割される。BS12及びSS14の機能ユニットは、媒体アクセス制御（MAC）レイヤと物理（PHY）レイヤとを含み、OSI（Opens  Systems  Interconnect）モデルのレイヤに準拠してもよく、この場合、レイヤは、上りリンク部分と物理リンク部分とに分割されてもよい。従って、SS14は、上りリンクMAC/PHYレイヤ部分48と下りリンクMAC50/PHYレイヤ部分52とに結合されたパケット分類器46を有するものとして示されてもよい。同様に、BS12は、下りリンクMAC/PHYレイヤ部分56と上りリンクPHYレイヤ部分58とに結合されたパケット分類器54を有するものとして示されてもよい。SS14の上りリンクMAC/PHYレイヤ48とBS12の上りリンクPHYレイヤ部分58との間に概念的な伝送パイプ62が示されており、このパイプは、上りリンクUGSサービスフローと上りリンクBEサービスフローとを有する。同様に、BS12の下りリンクMAC/PHYレイヤ部分56とSS14の下りリンクPHYレイヤ部分52との間に概念的な伝送パイプ64が示されており、このパイプは、下りリンクUGSサービスフローと下りリンクBEサービスフローとを有する。SS14は、図１のCPE16又は18でもよい。SS14のパケット分類器46は、上りリンクVoIPパケットを上りリンクUGSサービスフローに分類し、BS12にルーティングしてもよく、BS12のパケット分類器54は、下りリンクVoIPパケットをダウンストリームUGSサービスフローに分類し、SS14にルーティングしてもよい。分類器は、パケットを分類するために、IP/ポートアドレス、QoS属性（例えばTos（Type  of  Service）、DSCP（Differentiated  Service  Code  Point））のようなルールを使用する。サービスフローに複数の分類ルールが存在してもよいため、複数のIP接続は同じサービスフローにルーティングされてもよい。
【００１５】
SS14は、２段階の呼制御手順を利用する。２段階の呼制御手順は、帯域予約についての段階Iと、帯域活性化についての段階IIとを含む。段階Iの前に、サービスフローのプロビジョニングが存在してもよい。プロビジョニング中に、サービスフローはインスタンス化され、以下に説明するように、次に段階Iの間に予約され得るプロビジョニング済の帯域を含むように、そのプロビジョニング済のQoSParamSetが設定されてもよい。１つの可能性として、プロビジョニング済の帯域量は、ネットワーク管理システム（図示せず）により設定されてもよい。プロビジョニング済の帯域は、接続設定前又は接続設定中にBS12とSS14との間でネゴシエーションされてもよい。プロビジョニング済の帯域は、何らかの数の電話について設定されてもよく、この場合、この電話の数は１に限定されない。例えば、VoIP毎に100Kbpsを仮定して２つのVoIP呼を同時に受け取りたいと思う所与のSS14について、200Kbpsがプロビジョニング済の帯域に設定されてもよい。この例では、SS14が２つより多くのIP電話又はアナログ電話22又は26をCPE16又は18にそれぞれ接続しても、以下に説明する段階IIの帯域活性化中の如何なる所与の時間においても、せいぜい２つのみのアクティブな呼が存在し得る。統計的に、SS14において全てのVoIP呼が同時にアクティブであるとは限らないため、VoIPユーザに関して、SS14は、性能のかなりの低減なしに、BS12とプロビジョニング済の帯域を設定することについて十分に加入していない（under  subscribe）可能性がある。
【００１６】
段階Iの帯域予約について、BS12は、VoIPサービスフローについてSS14に“予約帯域割り当て（reserved  bandwidth  allocation）”を提供してもよく、この場合、このようなSS14は前に確立されたプロビジョニング済のサービスフローを有する。BS12の制約のため、或る場合での予約帯域割り当ては、プロビジョニング済の帯域より小さくてもよい。いずれの場合でも、プロビジョニング済の帯域の前の確立のため、BS12は、BSの制約に従わないにしても、所与のSS14に提供される所望の予約帯域割り当ての量を事前に認識している。段階IIの帯域活性化について、上りリンク／下りリンク（UL/DL）UGSサービスフローは、少なくとも１つのVoIP呼について活性化される。段階Iの予約帯域割り当てが１つより多くのVoIP呼についてのものであると仮定すると、１つより多くのアクティブなVoIP呼（すなわち、複数のVoIP呼）が同じUGSサービスフローを共有してもよい。或る実施例では、UGSサービスフローに含まれる各VoIPは、別々に活性化及び非活性化されてもよい。
【００１７】
２段階の呼制御手順では、複数のDSAメッセージに応じてサービスフローについて複数の予約帯域割り当てを許可する必要なく、複数のVoIP呼について単一の予約帯域割り当てがサービスフローに許可され得る。同様に、１つ以上のVoIP呼について予約帯域割り当ての非活性化を要求する複数のDSDメッセージも存在しない。これは、BSスケジューラの接続設定オーバーヘッドを低減し得る。更に、事前に音声サービスの帯域を割り当てることができるBS12によりVoIP品質に影響を与えずに、改善した帯域効率も実現され、どのくらいの音声呼が所与のDSA/DSDメッセージで開始／除去されるかを認識していないという問題を回避し得る。従って、帯域浪費及び悪い音声サービスが低減され得る。更に、CPE16及び18は、それぞれ如何なるIP電話及び如何なるアナログ電話とも動作し得る。２段階の呼制御手順は、アプリケーション空間に実装され得るため、CPE16及び18のMACレイヤ又はPHYレイヤに変更を必要としない。更に、２段階の呼制御手順がCPE16及び18に実装されるため、BS12にトランスペアレントになり得る。従って、２段階の呼制御手順を含めることは、BS12との相互運用性の問題を生じることなく、CPE16又は18に付加価値サービスを生成し得る。２段階の呼制御手順を実装するために、802.16標準の変更は必要ない。更に、CPE16又は18に２段階の呼制御手順を含めることは、WiMAXでのVonage使用モデルのサポートを提供し得る。
【００１８】
図３及び４を参照すると、SS14はが詳細に示されているが、この場合、VoIP呼接続のみが示されている（パケット分類器はない）。図３は、図１のCPE16を詳細に示しており、図４は、図１のCPE18を詳細に示している。図３を参照すると、本発明の一実施例に従って、SS14はCPE16の形式を取っており、２つのIP電話22と１つのコンピュータ24とに結合されて示されている。CPE16の様々なOSIレイヤが図４より詳細に図３に示されている（しかし、図３のように上りリンク部分と下りリンク部分とに分割されていない）。このようなレイヤはIP電話22用に構成されている。或る実施例では、電話22及びコンピュータ24は、Ethernet（登録商標）  PHYレイヤ70に結合されてもよく、次に、Ethernet（登録商標）  PHYレイヤ70は、Ethernet（登録商標）  MACレイヤ74、インターネットプロトコル（IP）レイヤ76及び伝送制御プロトコル（TCP）レイヤ78を通じて、セッション・イニシエーション・プロトコル（SIP：Session  Initiation  Protocol）プロキシ72の形式の“呼セッションモジュール（call  session  module）”に結合される。また、或る実施例では、IPレイヤ76は、MAC  CS（Convergence  Sublayer）80、MAC  CPS（Common  Part  Sublayer）82、WiMAX  PHYレイヤ84及び無線媒体30を通じて、BS12に結合されてもよい。接続制御モジュール（WiMAX接続制御（WCC：WiMAX  Connect  Control）モジュール86等）はCPE16に含まれ、呼セッションモジュール（SIPプロキシ72）とインタフェース接続するWCCアプリケーションプログラミングインタフェース（API）と、MAC  CS80及びMAC  CPS82とインタフェース接続するMAC  APIとを含む。図３のCPE16のアーキテクチャは、IP電話22のサポートを提供する。WCCモジュール86は、WiMAXサービスフローとVoIPストリーミングとのマッピングの役目をする。SIPプロキシ72は、サーバの役目とクライアントの役目との双方を行ってもよい。SIPサーバとして動作する場合、SIPプロキシ72は、１つのIP電話22からSIPメッセージを受信する。SIPクライアントとして動作する場合、SIPプロキシ72は、IP電話22の代わりにSIPメッセージをネットワークに転送する。音声ストリーミングパケットは、Ethernet（登録商標）  MACレイヤ74から、IPレイヤ76を通じてWCCモジュール86により設定されたWiMAXサービスフローにルーティングされてもよい。
【００１９】
図４を参照すると、本発明の一実施例に従って、SS14はCPE18の形式を取っており、１つのアナログ電話26（１つより多くてもよい）と１つのコンピュータ24とに結合されて示されている。図４の多くの構成要素は図３と同じであるため、同じ参照符号を有しており、再び説明されない。しかし、CPE18はアナログ電話を扱う構成要素を含んでおり、コーデック（コーダ−デコーダ）／SLIC（Subscriber  Line  Interface  Circuit）の組み合わせ87を含む。コーデックは、アナログ電話26からのアナログ信号をデジタル信号にコーディングし、デジタル信号をアナログ電話26に向かうアナログ信号にデコーディングすることを提供してもよい。SLICは、例えば、バッテリ供給（battery  feed）、過負荷保護、管理及び2-4線ハイブリッド（2-4  wire  hybrid）を含むループインタフェース機能を提供してもよい。コーデック／SLICの組み合わせ87は、ドライバ89を通じてSIPユーザエージェント88の形式の“呼セッションモジュール”に結合されてもよい。これはまた、IP76に結合される。SIPユーザエージェント88は、WCC  APIを介してWCCモジュール86に結合され、また、TCP78に結合される。図４のCPE18のアーキテクチャはアナログ電話26をサポートする。前述のように、WCCモジュール86は、WiMAXサービスフローとVoIPストリーミングとのマッピングの役目をする。SIPユーザエージェント88は、アナログ電話のイベント（オンフック／オフフック検出及び呼び出し音の活性化等）についてコーデック及びSLICの組み合わせ87とインタフェース接続してもよい。音声ストリーミングパケットは、コーデックから、IPレイヤ76を通じてWCCモジュール86により設定されたWiMAXサービスフローにルーティングされてもよい。
【００２０】
図３及び４について、WCCモジュール86の２つのAPIインタフェースが以下のように規定される。図３のSIPプロキシ72及び図４のSIPユーザエージェント88は、概して“呼セッションモジュール”と呼ばれる。この理由は、WCC  APIと交換されるメッセージ（信号）が図３及び４で同じであるからである。SIPが呼セッションモジュールを実装するために使用されるが、他の呼セッションプロトコルが使用されてもよい。図３及び４のWCCモジュール86のWCC  APIは、SIPアプリケーションが以下のメッセージを使用してWiMAXサービスを活性化又は非活性化することを可能にしてもよい。すなわち、(a)wccConnReq：VoIPストリーミングをWiMAXサービスフローに接続するための呼セッションモジュール（図３のSIPプロキシ72又は図４のSIPユーザエージェント88）からの接続要求メッセージ、(b)wccConnRsp：wccConnReqへの接続応答メッセージ、(c)wccDiscReq：MiMAXサービスフローへのVoIPストリーミングを切断するための呼セッションモジュール（図３のSIPプロキシ72又は図４のSIPユーザエージェント88）からの切断要求メッセージ、(d)wccDiscRsp：wccDiscReqへの応答メッセージである。WCCモジュール86のMAC  APIは、サービスフローを制御するためにIEEE802.16  MACメッセージを使用してもよい。或る実施例では、これらのIEEE802.16メッセージは、(a)dsaReq（dynamic  service  addition  Request）：サービスフローを生成するためのDSA-REQ要求、(b)dsaRsp（dynamic  service  addition  Response）：DSA-REQへのDSA-RSP応答、(c)dscReq（dynamic  service  change  Request）：サービスフロー属性を変更するためのDSC-REQ要求、(d)dscRsp（dynamic  service  change  Response）：DSC-REQへのDSC-RSP応答、(e)dsdReq（dynamic  service  deletion  Request）：サービスフローを削除するためのDSD-REQ要求、及び(f)dsdRsp（dynamic  service  deletion  Response）：DSD-REQへのDSD-RSP応答を含んでもよい。
【００２１】
図５を参照すると、前述のAPIメッセージ又は信号を使用して、本発明の様々な実施例に従って図３及び４のWCCモジュール86について制御状態遷移図が提供され、以下に提示される図６〜１０の図面の概要を提供する。図５のこの図は、以下の状態を有する。すなわち、(a)初期状態90：電源投入又はリセット後の初期状態、(b)許可状態92：UL/DLサービスフローのようなリソースが予約されている（割り当てられている）が、まだ活性化されていない（すなわち、アクティブなVoIP呼がない）、(c)活性化待機状態94：サービスフロー活性化についてのBSの応答の待機中、(d)アクティブ状態96：少なくとも１つのアクティブなVoIP呼が存在する、(e)非活性化待機状態98：サービスフロー非活性化についてのBS応答の待機中である。許可状態は、前述の２段階の呼制御手順の段階Iに対応する。初期状態90の間に、BSは、求められていないdsaReqメッセージをWCCモジュールに送信し、何らかの数のVoIP呼に予約帯域割り当てを提供することを要求してもよい。dsaRspメッセージ（図示せず）でBSに応答するときに、WCCモジュールは、初期状態90から許可状態92に遷移してもよい。BSがdsdReqメッセージを送信してサービスフローを削除するときに、WCCモジュールは、許可状態92から初期状態90に戻ってもよい。呼セッションモジュールからwccConnReqメッセージを受信すると、WCCモジュールは、dscReqメッセージをBSに送信し、許可状態から活性化待機状態94に遷移してもよい。BSからdsqRspメッセージを受信すると、WCCモジュールは、活性化待機状態94からアクティブ状態96に遷移してもよい。アクティブ状態96は、アクティブなVoIP呼が存在するという点で、前述の２段階の呼制御手順の段階IIに対応する。アクティブ状態96から活性化待機状態94に延びるwccConnReqメッセージで示すように、他のVoIP呼が追加されると、そのVoIP呼について、WCCモジュールは、活性化待機状態94に戻る。VoIP呼が呼セッションモジュールからwccDiscReqメッセージを受信するWCCモジュールにより終了されると、WCCモジュールは、アクティブ状態96から非活性化待機状態98に遷移してもよい。非活性化待機状態98で、WCCは、dscReqメッセージをBSに送信してもよい。BSからdscRspメッセージを受信すると、WCCは許可状態92に遷移してもよい。
【００２２】
図６〜１０は、本発明の様々な実施例に従って図５に記載のWCC状態図を実装する様々な制御状態論理図を示している。図５に示す状態の参照符号が図６〜１０で使用されている。更に、これらの図面で使用されるいくつかのパラメータは以下のように定義される。(a)“利用可能帯域量”Bw(XL)は、初期状態中に予約帯域割り当ての帯域量に初期化された利用可能な上りリンク又は下りリンク帯域を示す。(b)利用可能下りリンク帯域量Bw(DL)は、下りリンクの利用可能な帯域を示す。(c)利用可能上りリンク帯域量Bw(UL)は、上りリンクの利用可能な帯域を示す。(d)“呼セッション帯域部分”（要求帯域）の量reqBwは、VoIP呼に必要な要求帯域を示す。この場合、呼セッション帯域部分は、VoIP呼に必要な予約帯域割り当ての部分である。(e)T7は、DSA/DSC/DSD応答タイムアウトの待ちを示す。
【００２３】
図６を参照すると、図３及び４のWiMAX接続制御（WCC：WiMAX  Connection  Control）モジュール86の手順が、本発明の様々な実施例に従って示されている。WCCモジュール86は、初期状態90で始まり、複数の動作の後に、初期状態90に留まるか、許可状態92に遷移する。WCCモジュールが初期状態90にあるときに、動作100において、WCCモジュールが、初期状態90の間にVoIPストリームがWiMAXサービスフローに接続されることを要求するwccConnReqメッセージを、呼セッションモジュール（図３のSIPプロキシ又は図４のSIPユーザエージェント）から受信すると、動作102において、WCCモジュール86は、“失敗（接続が存在しない）”を示すwccConnRspメッセージで、呼セッションモジュールに応答し、繰り返しの初期状態90で示すように、初期状態90を続けてもよい。初期状態90の間に、動作104において、WCCモジュール86は、VoIP呼のサービスフローの帯域予約を要求するdsaReqメッセージをBSから受信してもよい。このBS起動のdsaReqメッセージは、許可セットに設定されたそのセットタイプパラメータを有し、或る実施例では、サービス名クラスのUGSを使用してもよい。この場合、UGSに関連するQoSパラメータセットが存在する。或る実施例では、BS起動のdsaReqは、予約帯域割り当ての帯域量を含んでもよく、これは、上りリンク（UP）及び下りリンク（DL）接続についてプロビジョニング済の帯域以下でもよい。動作106において、WCCモジュールは、SS起動のdsaReqメッセージのセットタイプが“許可”であるか否かを決定してもよい。そうである場合、動作108において、WCCは、OKに設定された確認コード（CC：Confirmation  Code）パラメータセットで、dsaRsp応答メッセージをBSに送信してもよい。次に動作110において、利用可能帯域量Bw(XL)が予約帯域割り当ての帯域量に初期化されてもよい。BSがプロビジョニング済の帯域の全ての量を提供することに制約されない場合、これはプロビジョニング済の帯域でもよい。動作112において、WCCモジュールは、UP/DL接続がそれぞれ許可されたか否かを決定してもよい。そうである場合、WCCモジュールは、その許可状態92に遷移してもよく、そうでない場合、WCCは初期状態に留まってもよい。動作106において、セットタイプが“許可”でない場合、動作114において、WCCモジュールは、CCが“その他”（誤ったQoSパラメータセットタイプ）を示すように設定されたdsaReqメッセージで応答し、許可状態92に進んでもよい。
【００２４】
図７を参照すると、本発明の様々な実施例による図３及び４のWCCモジュール86は、許可状態92で始まる。動作120において、VoIP呼のwccConnReqメッセージ要求が許可状態92中にWCCモジュールで受信されると、動作122において、上りリンク利用可能帯域量Bw(UL)は、上りリンクreqBw以上であるか否かを決定するために、VoIP呼の上りリンク呼セッション帯域量（要求帯域）reqBwと比較されてもよく、また、利用可能下りリンク帯域量Bw(DL)は、下りリンクreqBw以上であるか否かを決定するために、下りリンク呼セッション帯域（要求帯域）reqBwと比較されてもよい。そうである場合、動作124において、WCCモジュールは、SSに対して、dscReqメッセージをBSに送信させ、上りリンク（UL）接続を活性化してもよい。次に動作126において、WCCモジュールは、IEEE802.16で規定されているT7タイマを設定し、BSからdscRspメッセージを受信する期間を規定してもよい。同様に、動作128において、WCCモジュールは、SSに対して、dscReqメッセージをBSに送信させ、下りリンク（DL）接続を活性化してもよい。次に動作130において、WCCモジュールは、T7タイマを設定し、BSからdscRspメッセージを受信する期間を規定してもよい。その後、WCCモジュールは、活性化待機状態94に遷移してもよい。動作122において、利用可能帯域量がreqBwを超過しない場合、WCCモジュールは、VoIP電話呼について“失敗（十分なリソースがない）”を示すwccConnRspメッセージを送信するように進んでもよい。許可状態92の間に、動作140において、WCCは、BSからアクティブなVoIP呼の削除を要求するdsdReqメッセージをBSから受信してもよい。動作142において、WCCはdsdRspメッセージのCCパラメータを設定してもよく、動作144において、dsdRspメッセージはBSに送信されてもよい。次に、WCCは、初期状態90に戻ってもよい。
【００２５】
図８を参照すると、図３及び４のWCCモジュール86は活性化待機状態94で始まる。この活性化待機状態94の間に、動作150において、WCCモジュールは、BSからdsdReqメッセージを受信してもよい。動作152において、WCCは、dsdRspメッセージで拒否にパラメータCCを設定してもよく、動作154において、dsdRspメッセージをBSに送信してもよい。その後、WCCモジュールは、活性化待機状態94に留まる。この活性化待機状態94の間に、動作160において、WCCモジュールは、図７で前に送信したdscRspメッセージに応じて、BSからdscRspメッセージを受信してもよい。動作162において、WCCモジュールは、受信したdsdRspメッセージのCCパラメータを検査し、“成功”に設定されているか否かを確認してもよい。そうである場合、動作164において、T7タイマが設定されてもよく、動作166において、VoIP呼についてセッション呼帯域部分（要求帯域）の量reqBwだけBw(XL)が低減されてもよい。動作168において、WCCモジュールは、下りリンクと上りリンクとが活性化されたか否かを決定してもよい。そうである場合、動作170において、WCCモジュールは、VoIP呼の活性化の成功を示すwccConnRspを呼セッションモジュールに送信してもよく、アクティブ状態96になる。動作168で“no”である場合、WCCモジュールは、活性化待機状態94に留まってもよい。動作162で“no”である場合、動作170において、WCCモジュールは、“失敗（動作失敗）”を示すwccConnRspを呼セッションモジュールに送信し、動作172に進んでもよい。動作172において、WCCモジュールは、何らかのアクティブな呼が存在するか否かを決定してもよい。“yes”である場合、WCCモジュールはアクティブ状態96になる。“no”である場合、WCCモジュールは許可状態になる。動作180において、VoIP呼の所望の帯域の活性化を示すdsdRspメッセージを待機している間に図７で設定されたT7タイマがタイムアウトすると、動作182において、WCCモジュールは、リトライ回数がリトライ制限に到達していないか否かを決定してもよい。そうである場合、動作184において、WCCモジュールは、そのdscReqメッセージを繰り返し、VoIP接続を活性化し、動作186において、再びT7タイマを設定し、活性化待機状態94に留まってもよい。動作182において“no”である場合、動作184において、WCCモジュールは、クリーンアップ手順を実行してもよい。動作186において、“T7タイムアウトのリトライが制限値を超過した”というエラーログが入力されてもよい。動作188において、次に、WCCモジュールは、“失敗（動作失敗）”を示すwccConnRspメッセージを呼セッションモジュールに送信してもよい。次に、動作190において、WCCは、アクティブな呼が存在するか否かを確認するように進んでもよい。何らかのアクティブな呼が存在する場合、WCCモジュールは許可状態92に進んでもよい。アクティブな呼が存在しない場合、WCCモジュールはアクティブ状態96に進んでもよい。
【００２６】
図９に関して、本発明の様々な実施例に従って、図３及び４のWCCモジュール86は、呼セッションモジュールからwccDiscReqメッセージを受信したため、非活性化待機状態98で始まる。非活性化待機状態98の間に、動作200において、WCCモジュールは、VoIP呼が依然としてアクティブであるときに、サービスフローの非活性化を要求するdsdReqメッセージをBSから受信してもよい。動作202において、WCCモジュールは、dsdRspメッセージで“拒否”（802.16標準では、設定は“リソース／一時的拒否（reject  temporary/resource）”とみなされる）にCCパラメータを設定することにより応答してもよい。動作204において、WCCは、dsdRspメッセージをBSに送信し、非活性化待機状態98に留まってもよい。非活性化待機状態98の間に、動作206において、WCCモジュールは、非活性化についての前のdscReq要求メッセージに応答するdscRspメッセージをBSから受信してもよい。動作208において、WCCモジュールは、dscRspメッセージのパラメータCCを検査し、BSにより“成功”に設定されているか否かを確認してもよい。“yes”である場合、動作210において、T7タイマはリセットされ、動作212において、利用可能帯域量Bw(XL)は、非活性化されたVoIP呼のreqBwだけ増加してもよい。次に動作214において、WCCモジュールは、上りリンクと下りリンクとの双方の接続が非活性化されたか否かを検査及び確認してもよい。“yes”である場合、動作216において、WCCモジュールは、“成功”を示すwccDiscRspメッセージを呼セッションモジュールに送信し、動作218において、アクティブな呼が残っているか否かを検査して確認してもよい。“yes”である場合、WCCは、アクティブ状態96に遷移し、noである場合、WCCは、許可状態92に遷移してもよい。“no”である場合、動作214において、WCCモジュールは非活性化待機状態98に留まってもよい。動作208で“no”である場合、動作220において、CCパラメータにエラーログが入力されてもよく、WCCモジュールは動作214にループしてもよい。WCCモジュールは、dsa/dsc/dsd要求メッセージを送信する前にT7タイマを活性化してもよく、これは、dsa/dsc/dsd応答が時間通りに処理されない場合にタイムアウトしてもよい。従って、非活性化待機状態98の間に、動作222において、WCCモジュールは、BSからのdscRspメッセージを待機している間にT7タイマをタイムアウトさせてもよい。次に動作224において、WCCモジュールは、リトライ回数が設定された制限値を超えていないか否かを決定してもよい。“yes”である場合、動作226において、接続を非活性化するdscReqメッセージがリトライされてもよく、動作228において、T7タイマが設定されてもよく、WCCモジュールは非活性化待機状態98に留まってもよい。動作224で“no”である場合、動作230において、非活性化の試行中にT7のリトライが設定された制限値を超えたことを示すエラーログが作られてもよい。動作232において、wwwDiscRsp信号が呼セッションモジュールに送信されてもよい。次に動作234において、WCCモジュールは、何らかのアクティブな呼が残っているか否かを決定する。“yes”である場合、WCCモジュールはアクティブ状態96に遷移してもよく、“no”である場合、WCCモジュールは許可状態92に遷移してもよい。
【００２７】
図１０に関して、本発明の様々な実施例に従って、図３及び４のWCCモジュール86は、アクティブなVoIP呼に使用されているアクティブな帯域をBSから受信したため、アクティブ状態96で始まる。WCCモジュールは、それぞれ帯域の増加又は減少により、利用可能帯域量BW(XL)を増加又は減少させようとしてもよい。例えば、BSは、全体の最大のプロビジョニング済の帯域を提供していなくてもよく、予約帯域を増加させようとしてもよい。代替として、WCCモジュールは、最大のプロビジョニング済の帯域でSSに予約されてもよいが、例えば、加入契約により、最大のプロビジョニング済の帯域を増加可能にしてもよく、最大のプロビジョニング済の帯域を減少可能にしてもよい。他の可能性も、予約（プロビジョニング済）帯域割り当てを増加させる必要性及び機能をもたらしてもよい。これを開始するために、動作240において、WCCモジュールは、利用可能帯域量Bw(XL)を増加させるか否かを尋ねるdscReqメッセージをSSから受信してもよい。動作242において、WCCモジュールは、帯域を増加させるか減少させるか（或いは同じままに保持するか）を自分に問い合わせ、増加である場合、予約帯域割り当てを増加させようとする。増加する場合、動作244において、利用可能帯域量Bw(XL)は、帯域インクリメント（bwIncrement）だけ増加する。次に、動作246において、WCCは、帯域のインクリメント又はデクリメントを受け付けるために“OK”に設定されたCCパラメータを有するdscRspメッセージを送信することにより、BSに応答する。動作242において、帯域のデクリメントである場合、動作248において、WCCモジュールは、利用可能帯域量Bw(XL)を減少させようとするか否かを決定してもよい。そうである場合、動作250において、利用可能帯域量Bw(XL)は、帯域デクリメント（bwDecrement）だけ減少してもよく、WCCモジュールは、デクリメントを受け付けるために“OK”に設定されたパラメータCCでdscRspメッセージをBSに送信してもよい。この場合、WCCはアクティブ状態96に留まる。動作248においてWCCモジュールが帯域デクリメントを受け付けようとしない場合（実際にBw(XL)を同じに保持しようとする場合）、動作254において、WCCモジュールは、dscRspメッセージのパラメータCCを拒否に設定してもよく、動作256において、dscRsp応答をBSに送信してもよい。この場合、WCCはアクティブ状態96に留まる。動作258においてWCCモジュールがアクティブ状態96にある間に、VoIP呼に接続するwccConnReqメッセージを呼セッションモジュールから受信すると、動作260において、WCCモジュールは、利用可能帯域量Bw(UL)及びBw(DL)がVoIP呼に必要な呼セッション帯域量（reqBw）に必要なものより大きいか否かを検査して確認する。そうである場合、動作262において、WCCモジュールは、UL接続の活性化を要求するdscReqメッセージを生成し、それをBSに送信してもよい。次に動作264において、WCCモジュールは、UL接続についてのBSからのdscReqメッセージへの応答についてT7タイマを設定してもよい。同様に、動作266において、WCCモジュールは、DL接続の活性化を要求するdscReqメッセージを生成し、それをBSに送信してもよい。次に動作268において、WCCモジュールは、DL接続についてのBSからのdscReqメッセージへの応答についてT7タイマを設定し、活性化待機状態94に遷移してもよい。動作260に対してnoである場合、動作269において、WCCモジュールは、“失敗（十分なリソースがない）”を示すwccConnRspメッセージを送信することにより、呼セッションモジュールに応答する。この場合、WCCモジュールはアクティブ状態96に留まる。動作270においてWCCモジュールがアクティブ状態96の間に、切断したVoIP呼について呼セッションモジュールからwccDiscReqメッセージを受信すると、動作272において、WCCモジュールは、切断したVoIP呼についてUL接続帯域を切断するdscReqメッセージをBSに送信してもよく、動作274において、UL接続についてのdscReqメッセージへの応答の受信についてT7タイマを設定してもよい。同様に、動作276において、WCCモジュールは、切断したVoIP呼についてDL接続帯域を切断するdscReqメッセージをBSに送信してもよく、動作278において、DL接続についてのdscReqメッセージへの応答の受信についてT7タイマを設定してもよい。次に、非活性化待機状態98に遷移してもよい。WCCモジュールがアクティブ状態96にあるときに、動作280において、WCCモジュールは、WCCがサービスフローから切断しようとしているか否かを尋ねるdsdReqメッセージをBSから受信してもよい。動作282において、WCCモジュールは、“拒否”に設定されたパラメータCCでdsdRspメッセージを生成してもよく、動作284において、WCCモジュールは、dsdRspメッセージをBSに送信してもよい。この場合、WCCモジュールはアクティブ状態96に留まる。
【００２８】
図１１は、本発明の様々な実施例に従って、２段階の呼制御手順の段階Iによる帯域予約シナリオを示しており、それぞれ図３及び４のCPE16及び18の双方に関連する。IEEE802.16では、各サービスフローは一方向であるため、上りリンクサービスフローと下りリンクサービスフローとが別々に設定される必要がある。この例では、２つのVoIP呼をサポートできる例示的な200Kbpsの帯域が予約されてもよい。特に、これは、図３及び４のUL/DL  UGSサービスフローの予約帯域割り当ての提供を示しており、BSの帯域を予約するために、BSの帯域を割り当てる許可要求がBSから生じる。第１に、動作290において、BSは、qosSetType（前述の“タイプセット（Type  Set）”）を許可（Admitted）に設定し、最大持続可能レート（maxSusRate）を200kbpsに設定して、UL接続についてDSA-REQ（dsa-reqと同じ）メッセージを送信する。第２に、WCC86は、動作292において、タイプセット及びmaxSusRateをRSA-REQと同じにして、この予約帯域割り当てを受け付けるDSA-RSPメッセージで応答する。第３に、動作294において、BSは、qosSetType（前述の“タイプセット（Type  Set）”）を許可に設定し、最大持続可能レート（maxSusRate）を200kbpsに設定して、DL接続についてDSA-REQ（dsa-reqと同じ）メッセージを送信する。第４に、WCC86は、動作296において、タイプセット及びmaxSusRateをRSA-REQと同じにして、この予約帯域割り当てを受け付けるDSA-RSPメッセージで応答する。
【００２９】
図１２〜１５は、本発明の一実施例に従って、図１及び３のIP電話22についてのWiMAX上でのVoIP（VoIP  over  WiMAX）呼のシナリオを対象としている。WCC86は、VoIP呼のUL/DLサービスフローを活性化するDSC-REQメッセージを送信してもよい。これが最初のVoIP呼である場合、maxSusRateが100Kbpsに設定される。これが２番目の呼である場合、maxSusRateがもう100Kbpsだけ増加する。このことは、呼が全体のオーバーヘッドで約100Kbpsを必要とするG.711コーデックを使用することを仮定する。図１及び３に示す各IP電話22は、SIPユーザエージェント300（クライアントアプリケーション）を含み、これらのSIPユーザエージェント300の１つが、被発呼側SIPユーザエージェント302への発呼側として図１２に示されている。
【００３０】
図１２を参照すると、図１及び３のIP電話22について発信呼設定のシナリオが示されている。第１の動作において、WCC86の許可状態92で、SIP  INVITEメッセージが発呼側エージェント（caller  agent）300からSIPプロキシ72に送信されてもよい。第２の動作において、SIPプロキシ72は、INVITEを被発呼側ユーザエージェント302に転送してもよい。第３の動作において、SIP  100  trying信号がSIPプロキシ72から発呼側エージェント300に送信されてもよい。第４の動作において、SIP  180  ringing信号が被発呼側エージェント（callee  agent）302からSIPプロキシ72に送信されてもよい。第５の動作において、SIPプロキシ72は、SIP  180  ringing信号を発呼側エージェント300に渡してもよい。第６の動作において、被発呼側エージェント302は、SIP  200  OKを送信し、VoIP呼の確立を開始してもよい。第７の動作において、SIP  200  OKに応じて、SIPプロキシは、VoIP呼の帯域を要求するwccConnReqメッセージをWCC86に送信してもよい。wccConnReqメッセージに応じて、第８及び第９の動作において、WCC86は、qosSetType=アクティブ及びmaxSusRate=100kを含むパラメータセットで、UL/DLについてDSC-REQメッセージをBS12に送信してもよい。その後、WCCは活性化待機状態94に遷移する。第８の動作において、DSC-REQは、上りリンクサービスフローについて以下の機能を実現してもよい。すなわち、maxSusRateパラメータに示す帯域を割り当て、SS14において図２のパケット分類器46を構成してもよく、これにより、VoIPパケットが適切なUGSサービスフローにルーティングされてもよい。パケット分類器の構成に使用される分類ルールは、IPアドレス／ポート又はQoS（サービスタイプ／DSCP（differentiated  services  codepoint））に基づいてもよい。第９の動作において、DSC-REQは、maxSusRateパラメータに示す帯域を割り当て、BS12における図２のパケット分類器を構成してもよく、これにより、VoIPパケットが適切なUGSサービスフローにルーティングされてもよい。第１０及び第１１の動作において、BSは、qosSetTypeがアクティブに設定されてmaxSusRate=100kで、それぞれUL及びDLについてDSC-RSPメッセージで応答してもよい。この場合、WCCはアクティブ状態96に遷移する。第１２の動作において、WCC86は、wccConnRspメッセージをSIPプロキシ72に送信してもよい。第１３の動作において、SIPプロキシ72は、SIP  200  OK信号を発呼側エージェント300に送信してもよい。第１４の動作において、発呼側エージェント300は、SIP肯定応答（ACK）をSIPプロキシに送信してもよく、第１５の動作において、SIPプロキシ72は、ACKを被発呼側エージェント302に送信してもよい。その後、音声接続が確立される。
【００３１】
図１３は、図１及び３のIP電話22について発信呼解放のシナリオを示している。第１の動作において、被発呼側エージェント302は、SIP  BYEメッセージをSIPプロキシ72に送信してもよい。第２の動作において、SIPプロキシ72は、VoIP呼についてUL/DLサービスフローを非活性化するwccDiscReqメッセージをWCC86に送信することにより応答してもよい。第３及び第４の動作において、WCC86は、UL及びDLについてDSC-REQメッセージを送信することにより、wccDiscReqメッセージに応答してもよい。これが最初のVoIP呼である場合、maxSusRateは0に設定されてもよい。これが最初のVoIP呼でない場合、maxSusRateは100Kbpsだけデクリメントされてもよい。DSC-REQを送信した後に、WCC86は活性化待機状態94に遷移する。第５及び第６の動作において、BS12は、maxSusRate=0で、UL及びDLについてDSC-RSPを送信することにより、DSC-REQに応答してもよい。WCC86は、許可状態92に遷移することにより応答し、第７の動作において、wccDiscRspをSIPプロキシ72に送信してもよい。第８の動作において、SIPプロキシは、SIP  BYEメッセージを発呼側エージェント300に送信することにより応答してもよい。第９の動作において、発呼側エージェント300は、ACKをSIPプロキシ72に送信してもよい。第１０の動作において、SIPプロキシ72は、ACKを被発呼側エージェント302に送信してもよい。このことにより、音声接続が解放される。
【００３２】
図１４は、図１及び３のIP電話22について着信呼設定のシナリオを記載している。第１の動作において、WCC86の許可状態92で、SIP  INVITEメッセージが発呼側エージェント302からSIPプロキシ72に送信されてもよい。第２の動作において、SIPプロキシ72は、INVITEを被発呼側ユーザエージェント300に転送してもよい。第３の動作において、SIP  100  trying信号がSIPプロキシ72から発呼側エージェント302に送信されてもよい。第４の動作において、SIP  180  ringing信号が被発呼側エージェント300からSIPプロキシ72に送信されてもよい。第５の動作において、SIPプロキシ72は、SIP  180  ringing信号を発呼側エージェント302に渡してもよい。第６の動作において、被発呼側エージェント300は、SIP  200  OKをSIPプロキシに送信してもよい。第７の動作において、SIP  200  OKに応じて、SIPプロキシは、VoIP呼の帯域を要求するwccConnReqメッセージをWCC86に送信してもよい。wccConnReqメッセージに応じて、第８及び第９の動作において、WCC86は、qosSetType=アクティブ及びmaxSusRate=100kを含むパラメータセットで、UL/DLについてDSC-REQメッセージをBS12に送信してもよい。その後、WCCは活性化待機状態94に遷移する。第１０及び第１１の動作において、BSは、qosSetTypeがアクティブに設定されてmaxSusRate=100kで、それぞれUL及びDLについてDSC-RSPメッセージで応答してもよい。この場合、WCCはアクティブ状態96に遷移する。第１２の動作において、WCC86は、wccConnRspメッセージをSIPプロキシ72に送信してもよい。第１３の動作において、SIPプロキシ72は、SIP  200  OK信号を発呼側エージェント302に送信してもよい。第１４の動作において、発呼側エージェント302は、SIP肯定応答（ACK）をSIPプロキシ72に送信してもよく、第１５の動作において、SIPプロキシ72は、ACKを被発呼側エージェント300に送信してもよい。その後、音声接続が確立される。
【００３３】
図１５は、図１及び３のIP電話22について着信呼解放のシナリオを記載している。第１の動作において、被発呼側エージェント300は、SIP  BYEメッセージをSIPプロキシ72に送信する。第２の動作において、SIPプロキシ72は、SIP  BYEメッセージを発呼側エージェント302に送信することにより応答する。第３の動作において、発呼側エージェント302は、ACKをSIPプロキシ72に送信する。第４の動作において、SIPプロキシ72は、VoIP呼についてUL/DLサービスフローを非活性化するwccDiscReqメッセージをWCC86に送信することにより応答してもよい。第５及び第６の動作において、WCC86は、UL及びDLについてDSC-REQメッセージを送信することにより、wccDiscReqメッセージに応答してもよい。これが最初のVoIP呼である場合、maxSusRateは0に設定されてもよく、qosSetTypeは許可に設定される。これが最初のVoIP呼でない場合、maxSusRateは100Kbpsだけデクリメントされてもよく、qosSetTypeは許可に設定される。DSC-REQを送信した後に、WCC86は活性化待機状態94に遷移する。第７及び第８の動作において、BS12は、maxSusRate=0で、UL及びDLについてDSC-RSPを送信することにより、DSC-REQに応答してもよい。第９の動作において、WCC86は、wccDiscRspをSIPプロキシ72に送信してもよい。WCC86は許可状態92に遷移してもよい。第１０の動作において、SIPプロキシ72は、ACKを被発呼側エージェント300に送信してもよい。
【００３４】
図１６〜１９は、本発明の一実施例に従って、図１及び４のアナログ電話22についてのWiMAX上でのVoIP（VoIP  over  WiMAX）呼のシナリオを対象としている。WiMAX接続制御は、VoIP呼のUL/DLサービスフローを活性化するDSC-REQメッセージを送信する。これが最初のVoIP呼である場合、maxSusRateが100Kbpsに設定される。これが２番目の呼である場合、maxSusRateが100Kbpsに設定される。このことは、呼が全体のオーバーヘッドで約100Kbpsを必要とするG.711コーデックを使用することを仮定する。
【００３５】
図１６は、図１及び４のアナログ電話22について発信呼設定のシナリオを示している。第１の動作において、WCC86の許可状態92で、SIPユーザエージェント88は、INVITEを被発呼側ユーザエージェント304に送信してもよい。第２の動作において、SIP  180  ringing信号が被発呼側エージェント304からSIPユーザエージェント88に送信されてもよい。第３の動作において、被発呼側エージェント304は、SIP  200  OKをSIPユーザエージェント88に送信し、VoIP呼の確立を開始してもよい。第４の動作において、SIP  200  OKに応じて、SIPユーザエージェント88は、VoIP呼の帯域を要求するwccConnReqメッセージをWCC86に送信してもよい。wccConnReqメッセージに応じて、第５及び第６の動作において、WCC86は、qosSetType=アクティブ及びmaxSusRate=100kを含むパラメータセットで、UL/DLについてDSC-REQメッセージをBS12に送信してもよい。その後、WCCは活性化待機状態94に遷移する。パケット分類器の同じ構成が図１２で説明したように考えられる。第７及び第８の動作において、BSは、qosSetTypeがアクティブに設定されてmaxSusRate=100kで、それぞれUL及びDLについてDSC-RSPメッセージで応答してもよい。この場合、WCCはアクティブ状態96に遷移する。第９の動作において、WCC86は、wccConnRspメッセージをSIPユーザエージェント88に送信してもよい。第１０の動作において、SIPユーザエージェント88は、ACKを被発呼側エージェント304に送信してもよい。その後、音声接続が確立される。
【００３６】
図１７は、図１及び４のアナログ電話26について発信呼解放のシナリオを示している。第１の動作において、SIPユーザエージェント304（被発呼側エージェント）302は、SIP  BYEメッセージをSIPユーザエージェント88（発呼側エージェント88）に送信してもよい。第２の動作において、発呼側エージェント88は、VoIP呼についてUL/DLサービスフローを非活性化するwccDiscReqメッセージをWCC86に送信することにより応答してもよい。第３及び第４の動作において、WCC86は、UL及びDLについてDSC-REQメッセージを送信することにより、wccDiscReqメッセージに応答してもよい。これが最初のVoIP呼である場合、maxSusRateは0に設定されてもよく、qosSetTypeは許可に設定される。これが最初のVoIP呼でない場合、maxSusRateは100Kbpsだけデクリメントされてもよく、qosSetTypeは許可に設定される。DSC-REQを送信した後に、WCC86は活性化待機状態94に遷移する。第５及び第６の動作において、BS12は、maxSusRate=0で、UL及びDLについてDSC-RSPを送信することにより、DSC-REQに応答してもよい。WCC86は、許可状態92に遷移することにより応答し、第７の動作において、wccDiscRspを発呼側エージェント88に送信してもよい。第８の動作において、発呼側エージェント88は、ACKを被発呼側エージェント304に送信してもよい。このことにより、音声接続が解放される。
【００３７】
図１８は、図１及び４のアナログ電話26について着信呼設定のシナリオを記載している。第１の動作において、WCC86の許可状態92で、SIP  INVITEメッセージが発呼側エージェント304からSIPユーザエージェント88に送信されてもよい。第２の動作において、SIP  INVITEに応じて、SIPユーザエージェント88は、VoIP呼の帯域を要求するwccConnReqメッセージをWCC86に送信してもよい。wccConnReqメッセージに応じて、第３及び第４の動作において、WCC86は、qosSetType=アクティブ及びmaxSusRate=100kを含むパラメータセットで、UL/DLについてDSC-REQメッセージをBS12に送信してもよい。その後、WCCは活性化待機状態94に遷移する。第５及び第６の動作において、BSは、qosSetTypeがアクティブに設定されてmaxSusRate=100kで、それぞれUL及びDLについてDSC-RSPメッセージで応答してもよい。この場合、WCCはアクティブ状態96に遷移する。第７の動作において、WCC86は、wccConnRspメッセージをSIPユーザエージェント88に送信してもよい。第８及び第９の動作において、SIPユーザエージェント88は、SIP  180  ringing信号及びSIP  200  OK信号を発呼側エージェント304に送信してもよい。第１０の動作において、発呼側エージェント304は、SIP肯定応答（ACK）をSIPユーザエージェント88に送信してもよい。その後、音声接続が確立される。
【００３８】
図１９を参照すると、図１及び４のアナログ電話26について着信呼解放のシナリオが記載されている。第１の動作において、被発呼側エージェント88は、SIP  BYEメッセージを発呼側エージェント304に送信する。第２の動作において、発呼側エージェント304は、SIP  200  OKメッセージを被発呼側エージェント88に送信することにより応答してもよい。第３の動作において、被発呼側エージェント88は、VoIP呼についてUL/DLサービスフローを非活性化するwccDiscReqメッセージをWCC86に送信することにより応答してもよい。第４及び第５の動作において、WCC86は、UL及びDLについてDSC-REQメッセージを送信することにより、wccDiscReqメッセージに応答してもよい。これが最初のVoIP呼である場合、maxSusRateは0に設定されてもよい。これが最初のVoIP呼でない場合、maxSusRateは100Kbpsだけデクリメントされてもよい。DSC-REQを送信した後に、WCC86は活性化待機状態94に遷移する。第６及び第７の動作において、BS12は、maxSusRate=0で、UL及びDLについてDSC-RSPを送信することにより、DSC-REQに応答してもよい。この場合、WCC86は許可状態92に遷移する。第８の動作において、WCC86は、wccDiscRspを発呼側エージェント88に送信してもよい。次に、音声接続が解放される。
【００３９】
図２０を参照すると、CPE310が示されている。CPE310は、図３及び４のCPE16又は18でもよい。CPEシステムは、プロセッサ（集積回路チップ）312と、チップ312を搭載するICチップキャリア314とを含む。ICチップキャリア314は、ソケット318を介して基板又はプリント回路基板（PCB：printed  circuit  board）316に搭載されてもよい。しかし、他のシステムでは、ICキャリア314はPCB316に直接結合されてもよい。PCB316は、搭載されたメインメモリ320と、外部装置又は外部バス用の複数の入出力（I/O）モジュールとを有してもよい。これらの全ては、PCB316のバスシステム322により相互に結合される。システム310は、I/Oモジュール326を介してバスシステム322に結合された大容量記憶装置324を更に含んでもよい。更に、２つの例示的な電話22又は26が、I/Oモジュール328及び330を介してバスシステム322に結合されてもよい。他の外部若しくは周辺装置又は外部バス用の更なるI/Oモジュールが含まれてもよい。
【００４０】
或る実施例では、図３のCPE16の形式を取るCPEシステム310に関して、図３の呼セッションモジュール（SIPプロキシ72）及びWCCモジュール86は、プロセッサ312による実行のために、大容量記憶装置326からメモリ318に動かされるソフトウェアモジュールでもよい。或る実施例では、図４のCPE18の形式を取るCPEシステム310に関して、図４の呼セッションモジュール（SIPユーザエージェント88）及びWCCモジュール86は、プロセッサ312による実行のために、大容量記憶装置326からメモリ318に動かされるソフトウェアモジュールでもよい。呼セッションモジュール及びWCCモジュールがソフトウェアモジュールとして示されているが、他の実施例では、これらは配線されてもよい。
【００４１】
特定の実施例について図示及び説明したが、同じ目的を実現するように計算された何らかの構成が図示の特定の実施例に置換されてもよいことが、当業者にわかる。この出願は、本発明の如何なる適合又は変更をカバーすることを意図する。従って、本発明は、特許請求の範囲及びその均等によってのみ限定されることを明らかに意図する。
【図１】
2010519830.tif 000003
【図２】
2010519830.tif 000004
【図３】
2010519830.tif 000005
【図４】
2010519830.tif 000006
【図５】
2010519830.tif 000007
【図６】
2010519830.tif 000008
【図７】
2010519830.tif 000009
【図８】
2010519830.tif 000010
【図９】
2010519830.tif 000011
【図１０】
2010519830.tif 000012
【図１１】
2010519830.tif 000013
【図１２】
2010519830.tif 000014
【図１３】
2010519830.tif 000015
【図１４】
2010519830.tif 000016
【図１５】
2010519830.tif 000017
【図１６】
2010519830.tif 000018
【図１７】
2010519830.tif 000019
【図１８】
2010519830.tif 000020
【図１９】
2010519830.tif 000021
【図２０】
2010519830.tif 000022
【国際調査報告】
2010519830.tif 000023
2010519830.tif 000024