JP5070334B2 - モバイルサブスクライバステーションのためのｖｏｉｐ呼をサポートする装置 - Google Patents

Description

本発明の実施形態は、電子デバイス分野に係り、特に通信デバイスに係る。

ブロードバンドワイヤレスアクセス（ＢＷＡ）システムは、ポイントツーマルチポイント通信システムを通信ネットワークに提供する。ＢＷＡシステムは通常マイクロ波およびミリメートル波技術を利用して、通信信号をワイヤレスベースステーション（ＢＳ）から１以上のサブスクライバステーション（ＳＳ）および／またはモバイルサブスクライバステーション（ＭＳ）に送信する。ＢＷＡシステムは、音声、ビデオ、およびデータサービスを提供するよう設計された集中（converged）ワイヤレスネットワークであってよい。規格の中の８０２.１６ファミリーは、ＩＥＥＥ（米国電気電子学会）が、固定、ポータブル、および／または、モバイルＢＷＡネットワークの提供を目的として開発した（ＩＥＥＥ規格８０２．１６、２００４年発行版、および後続の版）。ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）フォーラムにより、ＩＥＥＥ８０２．１６規格に基づくブロードバンドワイヤレスネットワークの配置が促進される。特に、ＷｉＭＡＸフォーラムにより、ブロードバンドワイヤレス機器の互換性および相互利用性が保証される。便宜上、本開示では「８０２．１６」および「ＷｉＭＡＸ」という用語を入れ替え可能な形で利用して、エアインタフェース規格のＩＥＥＥ８０２．１６一式のことを表す場合がある。

ダウンリンク送信においては、ＷｉＭＡＸネットワークは、ＢＳから、ＳＳまたはＭＳへ、データパケットをブロードキャストしうるが、アップリンク送信においては、スケジューリングサービスを設計して、異なるトラフィックの特性およびサービス品質（ＱｏＳ）要件を有するサービスをサポートすることができる。ＷｉＭＡＸネットワーク等の集中ワイヤレスネットワークの顕著な利点は、異なるサービス間のワイヤレススペクトルという殆どの貴重なリソースを共有できることである。しかし、ＷｉＭＡＸネットワークにおけるワイヤレスネットワークの集中には、多数のＳＳ間でのアップリンク送信の調停、および、異なるサービス間で必要なＱｏＳを有するアップリンク帯域幅の割り当てといった課題も存在する。

本発明の様々な実施形態によるＢＷＡシステムのブロック図である。 本発明の様々な実施形態による図１のＢＷＡシステムのベースステーションを組み込むアクセスサービスネットワーク（ＡＳＮ）のブロック図である。 本発明の様々な実施形態によるＭＳのアクティブな第１のサービスフローおよび許可された第２のサービスフローを提供する信号図である。 本発明の様々な実施形態による図１のベースステーションを組み込むＡＳＮのブロック図であり、ＡＳＮモードのトリガが示されている。 本発明の様々な実施形態による図１のベースステーションを組み込むＡＳＮのブロック図であり、ＭＳモードトリガが示されている。 本発明の様々な実施形態によるＷＩＭＡＸ接続制御（ＷＣＣ）モジュールの状態遷移図である。 本発明の様々な実施形態による、ＡＳＮトリガモードを利用するＭＳに対して確保された帯域幅を第２のサービスフローに提供する信号図である。 本発明の一実施形態による、ＡＳＮトリガモードを利用する呼のセットアップ処理の信号図である。 本発明の一実施形態による、ＡＳＮトリガモードを利用する呼のティアダウン処理の信号図である。 本発明の様々な実施形態による、ＭＳトリガモードを利用するＭＳに対して確保された帯域幅を第２のサービスフローを提供する信号図である。 本発明の一実施形態による、ＭＳトリガモードを利用する呼のセットアップ処理の信号図である。 本発明の一実施形態による、ＭＳトリガモードを利用する呼のティアダウン処理の信号図である。 本発明の様々な実施形態を組み込むモバイルステーションシステムのブロック図である。

以下の記載においては、説明を行う目的から多数の特定の詳細を述べて、本発明について開示する実施形態の完全な理解を可能とすることに努める。しかし、本発明の実施形態がこれら特定の詳細なく実施可能であることは当業者には明らかである。他の場合には、公知の電気的な構造および回路はブロック図の形式で示して、本発明について開示する実施形態を曖昧にしないよう努める。「連結」という用語は、直接的な接続、間接的な接続、または間接的な通信をも含有する。

図１は、本発明の様々な実施形態による、例示的なブロードバンドワイヤレスアクセス（ＢＷＡ）システム１０を示す。ＢＷＡシステム１０はワイヤレスセルを利用して地理的領域をカバーしてよい。ＢＷＡシステム１０は、遠隔サイト位置の複数のモバイルサブスクライバステーション（モバイルＳＳ）またはモバイルステーション（ＭＳ）１４（図１にはＭＳ１４は１つだけ示されている）に対して送信する中央サイト位置のベースステーション（ＢＳ）１２を含んでよい。ＭＳ１４の例には、ラップトップまたはウルトラモバイルデバイス（ＵＭＤ）（例えばハンドヘルドデバイス）が含まれうる。ＢＷＡシステム１０の部材は、ＩＥＥＥ８０２．１６規格の通信プロトコルに応じて互いに通信しあってよい。概して、この８０２．１６規格は、ワイヤレスメトロポリタンエリアネットワーク（ＭＡＮ）（ＷｉＭＡＸネットワークとも称されうる）の固定および／またはモバイルＳＳ（例えばＭＳ１４）へのワイヤレスブロードバンドアクセスを定義してよい。ＢＳ１２と複数のＭＳ１４とは、ＢＳ１２のワイヤレスセルのワイヤレス媒体（エアインタフェース）１６を介して通信する。ＢＳ１２は、セル内のＭＳ１４への、またはＭＳ１４からのトラフィックを収集してよい。ＢＳ１２はインターネット等の有線または無線のバックボーンネットワーク（不図示）へのインタフェースを有する機器を含むことができ、これにより任意のＭＳ１４とバックボーンネットワークとの間のリンクを提供する。

ＭＳ１４は、ＶｏＩＰ（voice over Internet Protocol）呼を生成および受信しうる。一実施形態では、ＢＷＡシステム１０は、ＶｏＩＰ呼セッションについてセッション開始プロトコル（ＳＩＰ）を利用する。ＳＩＰは、１以上のＭＳ１４のセッションを作成、修正、および終了させるアプリケーション層制御（シグナリング）プロトコルである（ＩＥＴＦ（Internet Engineering Task Force）ＳＩＰワーキンググループによるＲＦＣ（Request For Comments）３２６１仕様を参照のこと）。しかし、ＳＩＰ以外のプロトコルをＶｏＩＰ呼セッションで利用することもできる。ＢＷＡシステムは、ＭＳ１４が発信する、またはＭＳ１４で受信されたＶｏＩＰトラフィックを、音声サービス用に用意された特別なサービス品質（ＱｏＳ）を有するコネクションを介して伝送する。ＩＥＥＥ８０２．１６規格の関連部分の記載および様々な定義を提示して、本発明による様々な実施形態の理解を助ける。

ＩＥＥＥ８０２．１６は、「サービスフロー」を、パケット（ＳＳが送信するアップリンクパケットまたはＢＳが送信するダウンリンクパケット）の一方向トランスポートを提供するメディアアクセスコントロール（ＭＡＣ）トランスポートサービスとして定義している。サービスフローは、待ち時間、ジッタ、およびスループット保証等のＱｏＳパラメータ一式により特徴付けられる。ＢＳは、サービスフローについて定義されたＱｏＳパラメータセットにおいて任意のＱｏＳを提供する。概してＩＥＥＥ８０２．１６規格が記載するサービスフローは、（ａ）準備（Provisioned）‐このサービスフローの状態は、例えばネットワーク管理システムによる準備により既知である、（ｂ）許可（Admitted）‐このサービスフローの状態は、ＳＳ用にＢＳがリソースを確保している、（ｃ）アクティブ（Active）‐このサービスフローの状態は、ＳＳ用にＢＳがリソースを割り当てている、という３つの状態を有することができ、各サービスフローは３つの状態のいずれかへの遷移が可能である。ＩＥＥＥ８０２．１６は、各サービスフロー符号内に、ＱｏＳパラメータセット（準備セット、許可セット、および／またはアクティブセット）の正規のアプリケーションを特定するパラメータＱｏＳパラメータセットタイプ（「セットタイプパラメータ」）を含む。８０２．１６規格は、帯域幅等のリソースがまず「許可され」、その後に、ひとたびエンドツーエンドネゴシエーションが完了すると、そのリソースを「起動」する、という、二段階起動モデルを提案している。ＩＥＥＥ８０２．１６はさらに、ＶｏＩＰ呼接続がセットアップされるまたはティアダウンされる際に動的にサービスフローをそれぞれ作成、変更および削除するＤＳＡ（Dynamic Service Deletion）メッセージ、ＤＳＣ（Dynamic service Change）メッセージ、およびＤＳＤ（Dynamic Service Deletion）メッセージを定義している。

ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）はさらに、区別化ＱｏＳ要件への帯域幅要求／承認処理を用いてアップリンクスケジューリングサービスを定義している。以下は、様々なサービス用のＩＥＥＥ８０２．１６のサービスクラスである：（ａ）ＵＧＳ（要請されていない（Unsolicited）承認サービス）：Ｔ１／Ｅ１エミュレーションおよびサイレンス抑制のないＶｏＩＰ等のサポートコンスタントビットレート（ＣＢＲ）またはＣＢＲに類似したサービスフローのサポート、（ｂ）リアルタイムポーリングサービス（ｒｔＰＳ）：サイレンス抑制のないＶｏＩＰサービス等の、周期的に可変サイズのデータパケットを生成するリアルタイムサービスフロー（ＳＦ）のサポート、（ｃ）拡張リアルタイムポーリングサービス（ｅｒｔＰＳ）：サイレンス抑制のないＶｏＩＰ等の、周期的に可変サイズのデータパケットを生成するリアルタイムサービスフローのサポート、（ｄ）非リアルタイムポーリングサービス（ｎｒｔＰＳ）：ファイル転送プロトコル（ＦＴＰ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）等の、定期的に可変サイズのデータ承認バーストタイプを必要とする非リアルタイムＳＦのサポート、および（ｅ）ベストエフォートサービス（ＢＥ）：通常のウェブサーフィングおよび電子メールサービスのサポート。各サービスクラスは、一纏まりのＭＳ１４またはＢＳ１２が利用するサービスフロー特性または属性（ＱｏＳパラメータを含む）を含み、所望のＱｏＳのサービスフローを要求する。

アクセスサービスネットワーク（ＡＳＮ）は、ＷｉＭＡＸサブスクライバ（例えばＭＳ１４）への無線アクセス（radio access）を行うのに必要な一式のネットワーク機能として定義される。ＡＳＮは以下の機能を提供する：（ａ）ＷｉＭＡＸ ＭＳ（ＭＳ１４等）とのＷｉＭＡＸ層−２（Ｌ２）コネクティビティ、（ｂ）ＡＡＡ（認証、許可、および会計上の）メッセージの、ＷｉＭＡＸサブスクライバのホームネットワークサービスプロバイダ（Ｈ−ＮＳＰ）への、サブスクライバセッションの認証、許可、およびセッション会計を目的とした転送、（ｃ）ＷｉＭＡＸサブスクライバの好適なＮＳＰのネットワークでの発見および選択、（ｄ）ＷｉＭＡＸ ＭＳとの層３（Ｌ３）の構築に関するリレー機能（つまりＩＰアドレス割り当て）、および無線リソース管理。上述の機能に加えて、ポータブルおよびモバイルな環境ではＡＳＮは以下の機能をサポートしうる：（ａ）ＡＳＮアンカーモビリティ、（ｂ）コネクティビティサービスネットワーク（ＣＳＮ）アンカーモビリティ、（ｃ）ページング、および（ｄ）ＡＳＮ−ＣＳＮトンネリング（ASN-CSN tunneling）。ＡＳＮは、１以上のＢＳ１２、および１以上のＡＳＮゲートウェイ等のネットワーク部材を含みうる。１つのＡＳＮを、１を超える数のＣＳＮが共有してもよい。

ＣＳＮ（Connectivity Service Network）は、インターネットプロトコル（ＩＰ）コネクティビティサービスをＷｉＭＡＸサブスクライバに提供する一式のネットワーク機能として定義される。ＣＳＮは以下の機能を提供しうる：（ａ）ユーザセッションへのＭＳ ＩＰアドレスおよびエンドポイントパラメータ割り当て、（ｂ）インターネットアクセス、（ｃ）ＡＡＡプロキシまたはサーバ、（ｄ）ユーザ加入プロフィールに基づくポリシーおよび許可制御（Policy and Admission Control）、（ｅ）ＡＳＮ−ＣＳＮトンネリングサポート、（ｆ）ＷｉＭＡＸサブスクライバへの課金およびオペレータ間の調停（settling）、ローミングに際してのインターＣＳＮトンネリング（inter-CSN tunneling for roaming）、および（ｈ）インターＡＳＮモビリティおよびロケーションベースのサービス等のＷｉＭＡＸサービス、ピアツーピアサービスへのコネクティビティ、法的な傍受サービスをサポートする目的の、ＩＰマルチメディアサービスおよびファシリティへの準備、認証、および／または、コネクティビティ。ＣＳＮは、ルータ、ＡＡＡプロキシ／サーバ、ユーザデータベース、および相互作用ゲートウェイＭＳ等のネットワーク部材を含みうる。

ＡＡＡ（認証、許可、および会計上の）サービスは、ユーザ認証、ユーザ許可、およびユーザ会計機能を行う。幾らかの実施形態では、遠隔認証ダイアルインユーザサービス（ＲＡＤＩＵＳ）プロトコルを通信プロトコルとして利用して、ＡＡＡ情報を伝送することができる。ＲＡＤＩＵＳは、自身のリンクおよび共有ＡＡＡまたはＡＡＡプロキシサービスの認証を希望するデバイス間の認証、許可、会計および構成情報を伝送するインターネット標準トラックプロトコル（Internet standard track protocol）である。ＩＥＥＥ８０２．１６ｅは、供給者と認証者との間の鍵交換において拡張可能認証プロトコル（ＥＡＰ）を利用しており、多数の鍵を利用しうる。開始点は、認証サーバから来る一対のマスターキー（ＰＭＫ）であってよい。

図１に戻ると、本発明の様々な実施形態によるＢＷＡシステム１０のＢＳ１２およびＭＳ１４のうち１つを表すブロック概略図が示されている。ＭＳ１４は１つしか示されていないが、ＢＳ１２は複数のＭＳ１４（複数のモバイルＳＳ１４）を収容することができる。ＢＳ１２およびＭＳ１４は、構想としてはアップリンク部分２０とダウンリンク部分２２とに、仮想線２４で分割されている。ＢＳ１２およびＭＳ１４の機能ユニットは、メディアアクセスコントロール（ＭＡＣ）層と物理（ＰＨＹ）層とを含むオープンシステムインターコネクト（ＯＳＩ）モデルの層に準拠していてよく、これら層がアップリンク部分２０およびダウンリンク部分２２に分割されている。故に、ＭＳ１４は、アップリンクＭＡＣ／ＰＨＹ層部分２８、ダウンリンクＭＡＣ層部分３０、およびダウンリンクＰＨＹ層部分３２に連結されているパケット分類器２６として描くことができる。同様に、ＢＳ１２は、ダウンリンクＭＡＣ／ＰＨＹ層部分３６に連結されるパケット分類器３４を有するとして描くことができる。ＢＳ１２はさらに、アップリンクＰＨＹ層部分３８およびアップリンクＭＡＣ層部分４０を含んでよい。後述するように、パケット分類器２６および３４は、分類規則に基づいて、パケットを適切な仮想接続へルーティングする。

図１は、ＶｏＩＰおよびデータ（例えばインターネットデータ）が、ＢＷＡシステム１０の集中ＷｉＭＡＸネットワークでトランスポートされうる様子を示す。サービスフローは、エアインタフェース１６を介した仮想接続である。より詳しくは、構想上の送信パイプ４２が、ＭＳ１４のアップリンクＭＡＣ／ＰＨＹ層２８と、ＢＳ１２のアップリンクＰＨＹ層部分３８との間に示されており、このパイプはＶｏＩＰシグナリング用の第１のアップリンクサービスフロー４４と、ＶｏＩＰ呼（呼のＶｏＩＰパケット）用の第２のアップリンクサービスフロー４６を有するとして示されているが、この詳細については後述する。同様に、構想上の送信パイプ４８は、ＢＳ１２のダウンリンクＭＡＣ／ＰＨＹ層３６と、ＭＳ１４のダウンリンクＰＨＹ層部分２２との間に示されており、このパイプはＶｏＩＰシグナリング用の第１のダウンリンクサービスフロー５０と、ＶｏＩＰ呼（呼のＶｏＩＰパケットを伝送するＶｏＩＰ接続）用の第２のダウンリンクサービスフロー５２を有するとして示されている。ＭＳ１４のパケット分類器２６は、アップリンクＶｏＩＰパケット５４を、ＢＳ１２に向けたアップリンクの第２のサービスフロー４６へと分類およびルーティングしてよく、ＢＳ１２のパケット分類器３４は、ＭＳ１４に向けた第２のダウンリンクサービスフロー５２へとダウンリンクＶｏＩＰパケット５６を分類およびルーティングしてよい。同様に、アップリンクデータ５８はパケット分類器２６により分類されて、第１のアップリンクサービスフロー４４へルーティングされてよく、ダウンリンクデータ６０は第１のダウンリンクサービスフロー５０へルーティングされてよい。パケット分類器２６および３４は、宛先ＩＰ／ポートアドレス、ＱｏＳ属性（Ｔｏｓ（サービスのタイプ））、ＤＳＣＰ（区別化されたサービスコードポイント）等の規則を利用して、パケットを分類する。１つのサービスフローには多数の分類規則があってよい。後述するように、第１のサービスフロー４４および５０は、本発明の様々な実施形態では、ＶｏＩＰシグナリングを含んでもよい。

ＢＷＡシステム１０は、本発明の様々な実施形態によると、ＶｏＩＰサービスをサポートする制御プランのプロトコルおよび手順を含む。より詳しくは以下の通りである：準備および会計を含むＶｏＩＰサービス配置シナリオ、ＶｏＩＰ呼が開始される際に、区別化されたＱｏＳをサービスフローに提供する方法、および、ＶｏＩＰ呼が終了する際のサービスフローの解除。ＶｏＩＰサービスに関しては、１つのセルについて最大数のＶｏＩＰ呼を良好な音声品質で提供することが望ましい。故に、ＶｏＩＰ呼の際の帯域幅割り当て／割り当て解除スキームは、帯域幅効率性および音声品質目的における重要な特徴でありうる。最も簡単な方法は、この目的にＤＳＡ／ＤＳＤメッセージを利用することであろう。しかし、呼毎にＤＳＡ／ＤＳＤを利用することには、以下の大きな問題がある：ＢＳが任意の時点でＶｏＩＰ呼を開始するのに幾つのＭＳがＤＳＡメッセージを送信する必要があるのかを知る手立てがない、というのも、ＭＳはＢＳからＢＳへローミングしているからである。故に、ＢＳは音声およびデータサービスについて帯域幅割り当てを最適に計画することができない場合もある。この結果、帯域幅が不十分なために多くの呼が拒絶されることからＶｏＩＰサービスの保証ができなくなる虞がある。各ＤＳＡ要求はホームＡＡＡサーバに認証を目的として転送される必要があるので、呼のセットアップ中に重要な遅延が生じる可能性がある。遅延は、ＭＳが外国のネットワーク（foreign networks）にローミングする際に、より長くなる可能性がある。これにより、呼毎にＤＳＡ／ＤＳＤメッセージを処理する方法では、ＢＳスケジューリングが複雑なものになる虞がある。

本発明の様々な実施形態によるＢＷＡシステム１０は、ＢＳ１２が始める２つのサービスフロー手順を用いてＷｉＭＡＸを介してＶｏＩＰを配置する。アップリンクフローに関しては、２つのサービスフローは、第１のアップリンクサービスフロー４４および第２のアップリンクサービスフロー４６を含み、ダウンリンクフローに関しては、２つのサービスフローは、第１のダウンリンクサービスフロー５０および第２のダウンリンクサービスフロー５２を含む。本発明の様々な実施形態によると、ＢＷＡシステム１０の第２のアップリンクサービスフロー４６および第２のダウンリンクサービスフロー５２を、ＵＧＳ、ｒｔＰＳまたはｅｒｔＰＳから選択する。幾らかの実施形態では、第１のアップリンクサービスフロー４４および第１のダウンリンクサービスフロー５０を、ｎｒｔＰＳまたはＢＥから選択してよい。第１のサービスフロー４４および５０のＶｏＩＰシグナリングには、呼制御メッセージ（例えば図８、９、１１、および１２に関して後述するＳＩＰ信号）を含んでよい。図２に関して詳述するように、ＢＳ１２は、ＤＳＡ−要求（ＤＳＡ−ＲＥＱ）メッセージを送信して、各第１のサービスフローがアクティブ状態（Active State）であるようなＶｏＩＰシグナリング用の第１のサービスフロー４４および５０を作成する。その後、ＢＳがＶｏＩＰ呼接続について第２のサービスフロー４６および５２をサポートすることができる場合、ＢＳ１２は第２のサービスフローを作成するべくＤＳＡ−ＲＥＱを送信する。後述するように、第２のサービスフロー４６および５２は、セットアップされると、各々許可状態（Admitted State）になり、これは、ＶｏＩＰサービスの帯域幅が確保されているが、まだＶｏＩＰ呼に対して承認されてはいないことを意味する。

本発明の様々な実施形態によるＢＷＡシステム１０は、第１段階が帯域幅確保であり第２段階が帯域幅起動であるという、二段階呼制御手順を利用している。第１段階の前に、サービスフローをインスタンス化してよく、その準備されたＱｏＳＰａｒａｍＳｅｔを、後の第１段階において確保される準備帯域幅を含むように設定してよく、これについては後述する。一つの可能性として、準備帯域幅の量は、ネットワーク管理システム（不図示）が設定してよい。別の可能性としては、準備帯域幅は、接続セットアップの前に、またはその間に、ＢＳ１２とＭＳ１４との間でネゴシエーションされてもよい。インスタンス化された第２のサービスフローの提供は、準備状態（Provisioned State）を有することで特徴付けられ、このインスタンス化段階は、ＶｏＩＰサービスに加入するＭＳ１４の第２のサービスフローの「事前準備（pre-provisioning）」とも称される場合がある。この名称によって、後に行われる帯域幅の確保は、「準備」の一部として称される場合もある。

帯域幅確保を行う第１段階では、ＭＳ１４がＢＳ１２のセルに入ると、ＢＳ１２はＶｏＩＰサービスの第２のサービスフロー４６および５２用に帯域幅を確保する。これらサービスフローは、図６を参照しながら後述するように、許可状態に変化する（ＱｏＳパラメータ状態が「許可された（Admitted）」になる）。帯域幅起動を行う第２段階で、ＶｏＩＰ呼が開始されると、ＱｏＳパラメータ状態がアクティブ（Active）に設定され、帯域幅（確保された帯域幅割り当て）が、最大維持トラフィックレートパラメータが特定するように、ＶｏＩＰ呼に対して承認される。帯域幅の起動停止（deactivation）の際には、ＶｏＩＰ呼を終了すると、ＱｏＳパラメータ状態が、許可状態（Admitted State）に変化する。加えて、ＶｏＩＰサービスのＵＤＲ（利用データ記録）を生成するが、これには、（ａ）確保されている第２サービスフローの期間および（ｂ）呼期間中にトランスポートされたバイト数が含まれる。

図２を参照すると、本発明の様々な実施形態によるＢＳ１２における図１のＢＷＡシステム１０のＢＳ１２はＡＳＮ７０の一部として示されており、ＭＡＣ層のソフトウェア機能の幾つかが示されている。ＡＳＮ７０はさらに、ＢＳ１２に連結されたＡＳＮゲートウェイ（ＡＳＮ ＧＷ）７２を含む。ＢＳ１２は、サービスフロー管理（ＳＦＭ）モジュール７４を含むとして示されている。幾らかの実施形態では、ＳＦＭモジュール７４は、許可（admission）制御モジュール７６、データパス機能モジュール７８、および許可制御モジュール７６およびデータパス機能７８に連結されたサービスフロー情報（ＳＦ ｉｎｆｏ）データベース８０を含んでもよい。しかし、全てがＢＳ１２のＭＡＣ層に存在するこれらモジュールの機能は、異なる分類がなされて異なる名称で称されてもよい。一例としては、ＳＦＭモジュール７４は図１のＢＳ１２のＭＡＣ／ＰＨＹ３６の一部であってもよい。幾らかの実施形態では、ＡＳＮゲートウェイ７２は、認証器８２を含んでよい。ＡＳＮゲートウェイ７２は、ＡＡＡサーバ８４に連結されてもよいし、ＡＡＡサーバに連結されうるＡＡＡプロキシサーバに連結されてもよい。ＡＡＡサーバ８４はホームＣＳＮであってもよいことは前述の通りである。

幾らかの実施形態では、前述のサービスフローＱｏＳパラメータに対する全ての変更は、ＳＦＭモジュール７４の許可を受けることにしてもよい。これには、新たなサービスフローを作成する全てのＤＳＡ−ＲＥＱメッセージ、および、既存のサービスフローのＱｏＳパラメータセットを変更する全てのＤＳＣ−ＲＥＱメッセージが含まれる。これら変更には、許可制御モジュール７６による許可制御決定（例えばAdmittedQosParamSetの設定）、および、データパス機能モジュール７８によるサービスフローの起動（例えば、ActiveQosParamSetの設定）が含まれてよい。リソースに関する低減要求も、許可制御モジュール７６による許可を受けることにしてもよい。

データパス機能モジュール７８は、許可制御モジュール７６に対して要求を行ってよい。データパス機能モジュール７８は、さらに、ＤＳＡ，ＤＳＣ，およびＤＳＤメッセージをＷｉＭａｘ接続制御モジュール（後述）に送受信してよい。データパス機能モジュール７８はさらに、「ＢＳスケジューラ」と称されるものを含んでよく、これは主に、前述した第１および第２のサービスフローを含むサービスフローに対する帯域幅承認をスケジュールするのに利用されてよい。概して、複数の要因（factor）に基づいて、ＢＳスケジューラは、特定の帯域幅の送信データを選択してよい。スケジュールサービスおよび関連するＱｏＳパラメータを特定することにより、ＢＳスケジューラはアップリンクトラフィックのスループットおよび待ち時間の必要性を予期して、ポールを提供する、および／または、適時に承認することができる。図３に関して記載するように、幾らかの実施形態では、各ＭＳ１４は、ＢＳ１２が構築した（ＶｏＩＰパケットの接続である）ＶｏＩＰシグナリング用の自身の第１のアップリンクサービスフロー４４、およびＶｏＩＰシグナリング用の自身の第２のアップリンクサービスフロー４６を有する。

図１および２を適宜参照しながら図３を参照すると、本発明の幾らかの実施形態によるＶｏＩＰサービスフロー準備および確保手順９０が示されている。ＶｏＩＰ呼における第２のサービスフローの確保手順は、ＭＳ１４がネットワークに入ることで（例えば図１におけるＢＷＡシステム１０のＢＳ１２のセルに入ることで）開始されてよい。処理９２でＭＳ１４は、ダウンリンク（ＤＬ）取得、同期、範囲変更（ranging）を行い、サブスクライバ基本機能（ＳＢＣ）をＢＳ１２との間で交換してよい。処理９４で、ＡＳＮ ＧＷ７２の認証器８２は、秘密鍵管理バージョン２（ＰＭＫｖ２）ＥＡＰ−転送メッセージに含まれているＥＡＰ−ＩＤ要求をＭＳ１４へ送信してよい。処理９６では、ＭＳ１４は、ＰＭＫｖ２ＥＡＰ−転送メッセージに含まれているＥＡＰ−ＩＤ応答を認証器８２に返してよい。処理９８では、ＭＳのＥＡＰのＩＤは、認証器８２がホームＡＡＡサーバ８４に送信するＲＡＤＩＵＳアクセス要求（Ｒｅｑ）メッセージに含まれていてよい。処理１００では、ＥＡＰ認証プロセスは、ＭＳ１４とＡＡＡサーバ８４との間で行われてよい。処理１０２で、ＥＡＰ認証プロセスが完了してよい。処理１０４で、ＡＡＡサーバ８４は、以下の表１に示すパラメータを含むＲＡＤＩＵＳアクセス応答（Ｒｓｐ）メッセージを送信してよい。

処理１０４で、認証器８２は、ＰＭＫｖ２ＥＡＰ−転送メッセージに含まれているＥＡＰ−ＳｕｃｃｅｓｓをＭＳ１４へ送信する。処理１０６で、認証器８２は、ＭＳＫ（マスターセッションキー）からＰＭＫ（対のマスターキー）を生成して、ＩＥＥＥ８０２．１６ｅ推奨版に特定されているアルゴリズムに基づいてＰＭＫからＡＫを（認証鍵）を生成してよい。認証器８２は、ＡＫをＢＳに送信してよい。処理１０８で、認証器は、以下の表２のパラメータを含むＲＲ−Ｒｅｑメッセージを送信してよい。

処理１１０で、ＢＳ１２およびＭＳ１４は、ＰＭＫｖ２の３通りのハンドシェーク（ＳＡ−ＴＥＫ−チャレンジ／要求／応答交換）を行い、事前準備サ−ビスフローのセキュリティ連携を構築する。処理１１２で、ＢＳ１２およびＭＳ１４は、ＴＥＫ（トラフィック暗号鍵）鍵交換を、ＰＭＫｖ２鍵−要求／返信メッセージを利用して行ってよい。処理１１４で、ＭＳおよびＢＳは、登録（ＲＥＧ）メッセージを利用してＭＳ登録を行ってよい。

処理１１６で、ＢＳ１２のＳＦＭモジュール７４（例えば、許可制御モジュール７６）は、許可制御を実行して、ネットワーク（ＢＳ１２のセル）に入っているＭＳ１４のＶｏＩＰサービスフローをサポートできるか否かを判断してよい。許可制御モジュール７６が、ＶｏＩＰサービスフローをサポートできると判断した場合、許可信号を生成する。処理１１８で、ＳＦＭモジュール７４（例えば、許可制御モジュール７６）による認証がなされると、ＢＳ１２のＳＦＭモジュール７４（例えば、データパス機能モジュール７８）は、ＤＳＡ−ＲＥＱメッセージを送信して、図１に示され前述した第１のアップリンク（ＵＬ）サービスフロー４４および第１のダウンリンク（ＤＬ）サービスフロー５０を作成する。図１の第１のサービスフロー４４および５０は、ＶｏＩＰシグナリングに利用されるが、ＳＩＰエージェント（図４および５参照のこと）へ、またはＳＩＰエージェントから、それぞれ提供されてよい。第１のサービスフローもまた、他のデータに利用されうる（図１のデータ５８参照のこと）。第１のサービスフローは、許可状態を経て遷移する必要性なく、アクティブ状態に設定される（例えば、ActiveQoSParamSetをヌルではない値に設定する）。

処理１２０で、ＢＳ１２がＶｏＩＰ呼接続について図１の第２のＵＬおよびＤＬサービスフロー４６および５２をサポートできる場合（例えば、データパス機能モジュール７８が許可信号を受信する）、ＢＳ１２（例えば、データパス機能モジュール７８）は、ＤＳＡ−ＲＥＱメッセージを送信して、ＶｏＩＰ呼（呼のＶｏＩＰパケット）用の第２のサービスフロー４６および５２を作成する。第２のサービスフロー４６および５２は、許可状態に設定されるが（例えば、AdmittedQoSParamSetをヌルではない値に設定する）、これは、帯域幅が確保されているがまだ承認されていないことを意味する。処理１２２で、ＢＳ１２は、ＲＲ−ＲＳＰメッセージを認証器８２に送信してよい。

一実施形態では、ＶｏＩＰシグナリングの第１のサービスフローは、許可制御モジュール７６がＶｏＩＰ呼接続について第２のサービスフローを許可するか否かという条件にその構築が基づくことなく、許可制御モジュール７６の認証に基づいて構築されてよい。別の実施形態では、ＶｏＩＰシグナリングの第１のサービスフローの構築およびＶｏＩＰ呼接続の第２のサービスフローの構築は、ＢＳ１２が第２のサービスフローをサポートすることができるという許可制御モジュール７６の決定を条件として行われてよい。

図４および５は、呼毎に図１の第２のアップリンクサービスフロー４６および第２のダウンリンクサービスフロー５２の起動または起動停止をＶｏＩＰアプリケーションに行わせる２つのトリガモデルに関している。２つのトリガモードは、ＡＳＮ７０とＭＳ１４のトリガポイントにそれぞれ対応するＡＳＮトリガモードとＭＳトリガモードとを含む。以下の記載は、主に、第２アップリンクサービスフロー４６の起動または起動停止に関するものであり、第２のダウンリンクサービスフロー５２の起動または起動停止は、概ね第２のアップリンクサービスフロー４６とともに行われる。

図４を参照すると、本発明の幾らかの実施形態によると、図２のＡＳＮ７０は、ＡＳＮトリガモードの実装に関している。これら実施形態では、ＢＳ１２のＳＦＭモジュール７４は、新たなコンポーネントである、ＷｉＭＡＸ接続制御（ＷＣＣ）モジュール１３０（「接続制御モジュール」とも称される）を有してよい。幾らかの実施形態では、ＢＳ１２における残りのＭＡＣ層との通信は、主に、データパス機能モジュール７８へ、またはデータパス機能モジュール７８からのものである（例えば、ＤＳＡおよびＤＳＣ要求および応答メッセージの交換）。ＭＳ１４はさらに、ＳＩＰエージェント１３２を示すよう描かれている。これら実施形態では、ＡＳＮ７０は、ＢＳ１２のＳＦＭモジュール７４に、または、ＡＳＮゲートウェイ７２に位置するＳＩＰプロキシモジュール１３４を含みうる。ＳＦＭモジュール７４は、ＢＳ１２のＭＡＣ層の一部である。識別子Ｒ１は、図１のワイヤレス媒体（エアインタフェース）１６のことであり、識別子Ｒ６は、ＳＦＭモジュール７４とＡＳＮゲートウェイ７２との間の通信リンクのことである。つまり、ＡＳＮトリガモードについては、ＷＣＣモジュール１３０はＡＳＮ７０内に配置される。

概して、ＷＣＣモジュール１３０は、ＷｉＭＡＸサービスフローとともにＶｏＩＰストリーミングのマッピングを担う。ＷＣＣモジュール１３０は、ＭＳ１４の代わりにＶｏＩＰサービスフローの起動または起動停止を担う。同様に、ＳＩＰプロキシモジュールは、ＭＳ１４のＳＩＰエージェント１３２の代わりに動作する。ＳＩＰプロキシモジュール１３４は、ＳＩＰサーバおよびＳＩＰクライアントの役割の両方を果たす。ＳＩＰサーバとして機能するとき、ＳＩＰプロキシモジュール１３４は、ＭＳ１４のＳＩＰエージェント１３２からＳＩＰシグナリングメッセージを受信してよい。ＳＩＰプロキシモジュール１３４は、ＳＩＰシグナリングメッセージに呼応して、図１のＶｏＩＰサービスフロー４４および４６を起動または起動停止するように、ＷＣＣモジュール１３０に要求してよい。ＳＩＰクライアントとして機能するとき、ＳＩＰプロキシモジュール１３４は、ＳＩＰシグナリングメッセージを、ネットワークのＳＩＰサーバ（不図示）に転送してよい。ＳＩＰプロキシモジュール１３４は、後述するようにＷＣＣ−アプリケーションインタフェース（ＡＰＩ）を介してＷＣＣモジュール１３０とインタフェースしてよい。ＡＳＮトリガモードのＶｏＩＰ呼のフローの例を図８および９に示すが、これはさらに、ＷＣＣプロトコルおよびそのＳＩＰプロキシ１３４との相互作用を記載する。

図５を参照すると、本発明の幾らかの実施形態における図２のＭＳ１４は、ＭＳトリガモードの実装に関している。図５のコンポーネントの多くが図４のものと同じであるので、同じ参照番号を残し、説明を省略する。これら実施形態では、前述のＷＣＣモジュール１３０は、ＭＳ１４内に配置されてよく、ＳＩＰエージェント１３２と直接通信してよく、これにより、ＳＩＰプロキシモジュールは必要がなくなる。ＷＣＣモジュール１３０は、図４におけるＡＳＮトリガの実施形態のものと同じ機能を果たしてよい。図１１および１２はＭＳトリガモードのＶｏＩＰ呼のフローの例を示しており、これはＷＣＣプロトコルを、より詳細に説明している。

２つのトリガモードの比較を以下の表３に示す。

図４および５に関しては、ＷＣＣモジュール１３０のＷＣＣ ＡＰＩインタフェースは以下のように定義される。ＷＣＣ ＡＰＩインタフェースに関しては、図４のＳＩＰプロキシモジュール１３４および図５のＳＩＰエージェント１３２は、総称的に、「呼セッションモジュール」と称される、というのも、ＷＣＣ ＡＰＩと交換されたメッセージ（信号）は、図４および５のものと同じであるからである。ＳＩＰは呼セッションモジュールを実装するのに利用されるが、他の呼セッションプロトコルを利用することもできる。図４および５の両方におけるＷＣＣ ＡＰＩは、ＳＩＰアプリケーションがＶｏＩＰサービスフローを起動または起動停止することを、以下のメッセージを利用して可能ならしめる。メッセージは以下の通りである：（ａ）wccConnReq−ＶｏＩＰストリーミングをＶｏＩＰサービスフローに接続するための呼セッションモジュール（図４のＳＩＰプロキシモジュール１３４または図５のＳＩＰエージェント１３２）からの接続要求メッセージ、（ｂ）wccConnRsp−wccConnReqへの接続応答メッセージ、（ｃ）wccDiscReq−ＶｏＩＰストリーミングのＶｏＩＰサービスフローへの接続を停止するための呼セッションモジュール（図４のＳＩＰプロキシモジュール１３４または図５のＳＩＰエージェント１３２）からの接続停止要求メッセージ、および（ｄ）wccDiscRsp−wccDiscReqへの応答メッセージ。

ＷＣＣモジュール１３０はさらに、サービスフローを制御する目的からＩＥＥＥ８０２．１６ＭＡＣメッセージを利用するＭＡＣ ＡＰＩを有してよい。幾らかの実施形態では、ＷＣＣモジュール１３０は以下のＩＥＥＥ８０２．１６メッセージを利用してよい：（ａ）ＤＳＡ−ＲＥＱ（dynamic service addition Request）−サービスフロー作成する要求、（ｂ）ＤＳＡ―ＲＳＰ（dynamic service addition Response）−ＤＳＡ−ＲＥＱへの応答、（ｃ）ＤＳＣ―ＲＥＱ（dynamic service change Request）−サービスフロー属性を変更する要求、（ｄ）ＤＳＣ−ＲＳＰ（dynamic service change Response）−ＤＳＣ−ＲＥＱへの応答、（ｅ）ＤＳＤ−ＲＥＱ（dynamic service deletion Request）−サービスフローの削除要求、および（ｆ）ＤＳＤ−ＲＳＰ（dynamic service deletion Response）−ＤＳＤ−ＲＥＱへの応答。

図６を参照すると、本発明の様々な実施形態による図４および５のＷＣＣモジュール１３０の状態遷移図が、上述のＡＰＩメッセージまたは信号を用いて示されている。さらに、状態遷移図は、後に提示する図７−１２の概略図を提供している。図６のこの図は以下の状態を有する、（ａ）初期化状態１４０−電源投入またはリセット後の初期状態、（ｂ）許可状態１４２−ＵＬ／ＤＬサービスフロー等のリソースが確保された（割り当てられた）たが、起動されていない状態（つまり、アクティブなＶｏＩＰ呼がない状態）、（ｃ）起動待ち状態１４４−サービスフロー起動についてのＢＳ応答を待っている状態、（ｄ）アクティブ状態１４６−少なくとも１つのアクティブなＶｏＩＰ呼がある状態、および（ｅ）起動停止待ち状態１４８−サービスフロー起動停止についてのＢＳ応答を待っている状態。

許可状態は、上述の二段階呼制御手順の第１段階に対応する。初期化状態１４０にある間は、ＢＳはＷＣＣモジュールに、要請されていない（non-solicited）ＤＳＡ−ＲＥＱメッセージを送信して、幾らかの数のＶｏＩＰ呼について確保された帯域幅割り当てを提供するよう要求してよい。ＤＳＡ−ＲＳＰメッセージ（不図示）でＢＳに応答して、ＢＳがサービスフロー削除を要請するＤＳＤ−ＲＥＱメッセージを送信すると、ＷＣＣモジュールは、許可１４２から初期化状態１４０へ戻る。ＷＣＣモジュールは、ＢＳがＤＳＤ−ＲＥＱを送信してサービスフローを削除すると、メッセージ許可状態１４２から初期化状態１４０へ遷移して戻る。呼セッションモジュールからwccConnReqメッセージを受信すると、ＷＣＣモジュールはＤＳＣ−ＲＥＱメッセージをＢＳに送信してよく、許可状態から起動待ち状態１４４へ遷移してよい。ＤＳＤ−ＲＳＰメッセージをＢＳから受信すると、ＷＣＣモジュールは、起動待ち状態１４４からアクティブ状態１４６へ遷移してよい。アクティブ状態１４６は、今はアクティブなＶｏＩＰ呼があるという点で、上述の二段階呼制御手順の第２段階に対応している。呼セッションモジュールからwccDiscReqメッセージを受信したＷＣＣモジュールによりＶｏＩＰ呼が終了されると、ＷＣＣモジュールは、アクティブ状態１４６から起動停止待ち状態１４８へ遷移してよく、ここで、ＷＣＣはＤＳＣ−ＲＥＱメッセージをＢＳに送信してよい。ＤＳＣ−ＲＳＰメッセージをＢＳから受信すると、ＷＣＣは、許可状態１４２へ遷移してよい。

図７から１２は、本発明の様々な実施形態による図６に記載したＷＣＣ状態図を実装するＶｏＩＰ呼フローの様々な例を示す。これら例は、区別化されたサービスフローをＶｏＩＰサービスに提供するためのＳＩＰ、ＷＣＣ、およびＢＳ／ＭＳ ＭＡＣの統合を示している。これらの例は、最大ビットレートが１２．２Ｋｂｐｓであるアダプティブマルチレート（ＡＭＲ）ｃｏｄｅｃ（不図示）を利用する。これらの例においては、第２のサービスフローの各々が、２５Ｋｂｐｓの最大維持レートを必要としており、これには全てのヘッダオーバヘッドが含まれる。図６の状態に付された参照番号を図７から１２でも利用する。図７から９に関しては、呼フローの例が図４に記載されたＡＳＮトリガモードについて示されている。ＡＳＮトリガモードのこの呼フローの例では、図４のＷＣＣモジュール１３０はＢＳ１２に配置されている。同じ呼フローを、ＡＳＮゲートウェイ７２に常駐しているＷＣＣモジュール１３０について利用することもできる。図１０から１２に関しては、図５に記載するＭＳトリガモードについて呼フロー例が示されている。ＭＳトリガモードのこの呼フローの例においては、図４のＷＣＣモジュール１３０はＭＳ１４に位置している。

図７を参照すると、ＢＳに位置しているＷＣＣモジュール１３０の初期化が示されており、これは基本的に図３の処理１２０に対応しており、ここではアップリンク（ＵＬ）およびダウンリンク（ＤＬ）ＶｏＩＰトラフィックの２つのサービスフローが生成され、ＱｏＳパラメータセットタイプが「許可」に設定される。ＤＳＡ−ＲＥＱメッセージに示されているパラメータは、包括的ではなく、可変であってよい。より詳しくは、図７は、上述の二段階呼制御手順の第１段階による帯域幅確保シナリオを示す。ＩＥＥＥ８０２．１６において、各サービスフローは一方向であるので、アップリンクおよびダウンリンクサービスフローが別個にセットアップされる必要がある。この例においては、一例である２５Ｋｂｐｓ帯域幅がＶｏＩＰ呼用に確保されうる。特に、これは、図１の第２のＵＬおよびＵＤサービスフロー４６および５２に対して確保された帯域幅割り当ての提供を示しており、ここで、許可要求はＢＳ１２のＷＣＣモジュール１３０から発生して、ＢＳの帯域幅を割り当てて、ＭＳ１４の帯域幅を確保する。

ＷＣＣモジュール１３０は、初期化状態から始まる。第一に、処理１５０で、ＢＳはＵＬ接続用のＤＳＡ−ＲＥＱメッセージを、「許可（Admitted）」に設定されたQosSetTypeと２５ｋｂｐｓに設定された最大維持可能レート（maxSusRate）とともに、送信する。第二に、処理１５２で、ＷＣＣモジュール１３０は、ＣＣ＝Ｓｕｃｃとして、処理１５２でこの確保された帯域幅割り当てを受けるＤＳＡ−ＲＳＰメッセージで応答する。第三に、処理１５５において、ＢＳは、「許可」に設定されたQosSetTypeと２５ｋｂｐｓに設定された最大維持可能レート（maxSusRate）とともに、ＤＬ接続用にＤＳＡ−ＲＥＱメッセージを送信する。第四に、処理１５６で、ＷＣＣモジュール１３０は、ＣＣ＝Ｓｕｃｃとしてこの確保された帯域幅割り当てを受けるＤＳＡ−ＲＳＰメッセージで応答する。

図４よび８を参照すると、図４のＳＩＰプロキシモジュール１３４とともに呼セットアップが示されている。図４を参照すると、図８のヘッダは以下の通りである。発呼側（Caller）の「ＳＩＰエージェント」が図４のＳＩＰエージェント１３２であり、「ＭＳのＭＡＣ」がＭＳ１４のＭＡＣであり（例えば、図１のＭＡＣ／ＰＨＹ層２８）、「ＢＳのＷＣＣ」が図４のＢＳ１２のＷＣＣモジュール１３０であり、「ＡＳＮのＳＩＰプロキシ」が図４のＡＳＮ７０のＳＩＰプロキシモジュール１３４である。加えて、被呼側（Callee）のＳＩＰエージェント１５８が示されている。より詳しくは、この発生している呼セットアップは、図７で遷移した、許可状態１４２にあるＷＣＣモジュール１３０で開始される。

最初の６つの処理１６０‐１７０は、ＶｏＩＰ呼をセットアップするＳＩＰプロトコルを記載する。最初の処理１６０で、ＳＩＰ ＩＮＶＩＴＥメッセージを、発呼側のＳＩＰエージェント１３２からＳＩＰプロキシモジュール１３４へ送信してよい。第２の処理１６２で、ＳＩＰプロキシモジュール１３４は、被呼側のＳＩＰエージェント１５８へＩＮＶＩＴＥを転送してよい。第３の処理１６４で、ＳＩＰ１００試行信号が、ＳＩＰプロキシモジュール１３４から、発呼側のＳＩＰエージェント１３２に送信されてよい。第４の処理１６６で、ＳＩＰ１８０呼信号を、被呼側のＳＩＰエージェント１５８からＳＩＰプロキシモジュール１３４に送信してよい。第５の処理１６８で、ＳＩＰプロキシモジュール１３４は、ＳＩＰ１８０呼信号を、発呼側のＳＩＰエージェント１３２に渡してよい。第６の処理１７０で、被呼側のＳＩＰエージェント１５８は、ＳＩＰ２００ＯＫ信号を送信して、ＶｏＩＰ呼の構築を開始してよい。

第７の処理１７２で、ＳＩＰ２００ＯＫ（被呼側のＳＩＰエージェント１５８が呼に答える）に呼応して、ＳＩＰプロキシモジュール１３４は、ＶｏＩＰ呼について帯域幅を要求するwccConnReqメッセージをＷＣＣモジュール１３０に送信してよい。加えて、wccConnReqメッセージは、ＶｏＩＰストリーミングをサービスフローにマッピングするべく以下のパラメータを含む：（ａ）バイト単位の全ビットレート、（ｂ）ｍｓ単位の音声パケット期間、（ｃ）バイト単位の音声パケットサイズ、（ｄ）ソースＩＰアドレスおよびポート番号、および（ｅ）宛先ＩＰアドレスおよびポート番号。

wccConnReqメッセージに呼応して、第８および第９の処理１７４および１７６で、ＷＣＣモジュール１３０は、ＵＬ／ＤＬ用にＭＳ１４のＭＡＣにＤＳＣ−ＲＥＱメッセージを、qosSetType=activeに設定されたパラメータとともに送信してよく、この後で、ＷＣＣモジュール１３０は、自身の起動待ち状態１４４に遷移してよい。より詳しくは、ＷＣＣモジュール１３０はＤＳＣ−ＲＥＱメッセージを送信するときに、ＶｏＩＰ呼用にＵＬ／ＤＬサービスフローを起動するべく以下のパラメータを送信する：（ａ）サービスフロー識別（ＳＦＩＤ）（ＵＬまたはＤＬ）、（ｂ）ＱｏＳパラメータセットタイプ＝「アクティブ」（これは、ＳＦがアクティブであり、ＢＳ１２がＭＳ１４に帯域幅を承認することを示す）、および（ｃ）以下の規則によりＳＳおよびＢＳのパケット分類器を構成して、ＶｏＩＰパケットが適切な第２のサービスフローにルーティングできるようにする（パラメータの例には、ＩＰ宛先アドレス／ポートおよびサービス／区別化されたサービスコードポイント（ＤＳＣＰ）のＩＰタイプが含まれる）。ＤＳＣ−ＲＥＱメッセージの送信後、ＷＣＣモジュール１３０は自身の起動待ち状態１４８へ遷移してよい。

第１０の処理１７８で、ＭＳ１４のＭＡＣ層は、ＣＣ（Conformation Code）を成功（Ｓｕｃｃ）にセットして、ＵＬのＤＳＣ−ＲＳＰメッセージに応答してよい。第１１の処理１８０で、ＷＣＣモジュール１３０は、ＣＣをＳｕｃｃにセットして、ＵＬのＤＳＣ−ＡＣＫを送信することで応答してよい。同様に、第１２の処理１８２で、ＭＳ１４のＭＡＣ層は、ＣＣ（Conformation Code）を成功（Ｓｕｃｃ）にセットして、ＤＬのＤＳＣ−ＲＳＰメッセージで応答してよい。第１３の処理１８４で、ＷＣＣモジュール１３０は、ＣＣをＳｕｃｃにセットして、ＤＬのＤＳＣ−ＡＣＫを送信することで応答してよい。その後、ＷＣＣモジュール１３０は、アクティブ状態１４６に遷移してよい。

第１４の処理１８６で、ＷＣＣモジュール１３０は、ＳＩＰプロキシモジュール１３４に対してwccConnRspメッセージを送信して、ＳＩＰプロキシモジュール１３４にサービスフローで音声通信の準備が整ったことを通知してよい。その後、ＳＩＰプロトコルは、処理１８８−１９２の呼を完了する。より具体的には、第１５の処理１８８で、ＳＩＰプロキシモジュール１３４は、ＳＩＰ２００ＯＫ信号を、発呼側のＳＩＰエージェント１３２に送信してよい。第１６の処理１９０で、発呼側のＳＩＰエージェント１３２はＳＩＰ受領確認（ＡＣＫ）をＳＩＰプロキシモジュール１３４に送ってよく、第１７の処理１９２で、ＳＩＰプロキシモジュール１３４は、被呼側のＳＩＰエージェント１５８にＡＣＫを送信してよく、この後の１９４で音声接続が構築される。

処理１７２は、帯域幅を起動して、ＭＳ１４がＶｏＩＰ呼中にデータ利用のため課金されることを示す。前述の利用データ記録（ＵＤＲ）は、確保されているＶｏＩＰ帯域幅および実際のデータ利用の期間に対して課金されるＶｏＩＰサブスクライバ（ＭＳ１４）の課金記録を取得してもよい。概して、データパス機能モジュール７８は、ＵＤＲの会計を管理し、ＳＦ情報データベース８０にＵＤＲを記憶させてよい。幾らかの実施形態では、ＶｏＩＰサービスのＵＤＲは、（ａ）確保されている第２のサービスフロー（ＵＧＳ，ｒｔＰＳ、またはｅｒｔＰＳサービスフロー）の期間、および（ｂ）ＶｏＩＰ呼期間中にトランスポートされたバイト数を含む。

図４から９を参照すると、これもＡＳＮトリガモードについて、図４のＳＩＰプロキシモジュール１３４とともに図９に示す呼解除フローが示されている。第１の処理２００で、発呼側のＳＩＰエージェント１３２は、ＳＩＰ ＢＹＥメッセージをＳＩＰプロキシモジュール１３４に送信して、ＶｏＩＰ呼を解除してよい。第２の処理２０２で、ＳＩＰプロキシモジュール１３４は、ＶｏＩＰ ＵＬ／ＤＬサービスフローに対する接続を停止するべく、以下のパラメータ（ａ）ソースＩＰアドレスおよびポート番号、（ｂ）宛先ＩＰアドレスおよびポート番号とともに、wccDiscReqメッセージをＷＣＣモジュール１３０に送信することで、応答してよい。第３および第４の処理２０４および２０６で、ＷＣＣモジュール１３０は、ＶｏＩＰ呼のＵＬ／ＤＬサービスフローの起動停止をするべく以下のパラメータとともにＤＳＣを送信することで、wccDiscReqメッセージに応答してよく、このパラメータとは以下の通りである：（ａ）ＳＦＩＤ（ＵＬまたはＤＬ）、（ｂ）ＱｏＳパラメータセットタイプ＝許可（「許可」状態に変更することで、アクティブ呼がないことを示す）および（ｃ）「分類器ＤＳＣアクション」パラメータをＤＳＣ削除分類器に設定する（先に呼に利用された分類器規則を削除する）パラメータ。ＤＳＣ−ＲＥＱメッセージの送信後に、ＷＣＣモジュール１３０は自身の起動停止待ち１４８に遷移してよい。

第５の処理２０８で、ＭＳ１４のＭＡＣは、ＣＣ（受領確認コード）（confirmation code）を成功（Ｓｕｃｃ）に設定してＵＬのＤＳＣ−ＲＳＰメッセージを送信することで、ＵＬのＤＳＣ−ＲＥＱメッセージに応答してよい。第６の処理２１０で、ＷＣＣモジュール１３０は、ＣＣ＝ＳｕｃｃとしてＵＬのＤＳＣ−ＡＣＫメッセージを送信することで応答してよい。同様に、第７の処理２１２で、ＭＳ１４のＭＡＣは、ＤＬのＤＳＣ−ＲＳＰメッセージを送信することでＤＬのＤＳＣ−ＲＥＱメッセージに応答してよい。第８の処理２１４で、ＷＣＣモジュール１３０は、ＣＣ＝ＳｕｃｃとしてＤＬのＤＳＣ−ＡＣＫメッセージを送信することで応答してよい。その後、ＷＣＣモジュール１３０は、自身の許可状態１４２に遷移することで応答してよい。第９の処理２１６で、ＷＣＣモジュール１３０は、wccDiscRspをＳＩＰプロキシモジュール１３４に送信して、ＳＩＰプロキシモジュール１３４に対して、サービスフローが起動停止されたことを通知してよい。

処理２１８‐２２２で、ＳＩＰプロトコルは呼を解除する。第１０の処理２１８で、ＳＩＰプロキシモジュール１３４は、被呼側のＳＩＰエージェント１５８にＳＩＰ ＢＹＥメッセージを送信することで応答してよく、第１１の処理２２０で、ＡＣＫをＳＩＰプロキシモジュール１３４に送信してよい。第１２の処理２２２で、ＳＩＰプロキシモジュール１３４は、発呼側のＳＩＰエージェント１３２にＡＣＫを送信してよく、これにより２２４で音声接続がティアダウンされる。

図１０を参照すると、図５に示すＭＳトリガモードの呼フローの例が示されている。この例においては、ＷＣＣモジュール１３０はＭＳ１４に位置している。図１０は、ＷＣＣモジュール１３０の初期化を示しており、これは基本的に図３の処理１２０に対応しており、ここではアップリンク（ＵＬ）およびダウンリンク（ＤＬ）ＶｏＩＰトラフィックの２つのサービスフローが生成され、ＱｏＳパラメータセットタイプが「許可」に設定される。ＤＳＡ−ＲＥＱメッセージに示されているパラメータは、包括的ではなく、可変であってよい。この例においては、一例である２５Ｋｂｐｓ帯域幅がＶｏＩＰ呼用に確保されうる。特に、これは、図１のＵＬ／ＤＬの第２のサービスフロー４６および５２に対して確保された帯域幅割り当ての提供を示しており、ここで、許可要求はＢＳ１２のＭＡＣから発生して、ＢＳの帯域幅を割り当ててＭＳ１４の帯域幅を確保する。第一に、処理２３０で、ＢＳは、qosSetTypeを「許可」に設定して、且つ、最大維持可能レート（maxSusRate）を２５ｋｂｐｓに設定して、ＵＬ接続のＤＳＡ−ＲＥＱメッセージを送信する。第二に、処理２３２で、ＷＣＣモジュール１３０は、ＣＣ＝Ｓｕｃｃとして、この確保された帯域幅割り当てを受け付けるＤＳＡ−ＲＳＰメッセージで応答する。第三に、処理２３４で、ＢＳは、qosSetTypeを「許可」に設定して、且つ、最大維持可能レート（maxSusRate）を２５ｋｂｐｓに設定して、ＤＬ接続のＤＳＡ−ＲＥＱメッセージを送信する。第四に、処理２３６で、ＷＣＣモジュール１３０は、ＣＣ＝Ｓｕｃｃとして、この確保された帯域幅割り当てを受け付けるＤＳＡ−ＲＳＰメッセージで応答する。

図５および１１を参照すると、図４のＳＩＰプロキシモジュール１３４による呼セットアップフローが示されている。この発生している呼セットアップのシナリオは、図１０で示したように許可状態１４２になったＷＣＣモジュール１３０で開始される。最初の三つの処理２４０−２４４は、ＶｏＩＰ呼をセットアップするＳＩＰプロトコルを記載する。第１の処理２４０では、発呼側のＳＩＰエージェント１３２から被呼側のＳＩＰエージェント１５８へＳＩＰ ＩＮＶＩＴＥメッセージを送信してよい。第２の処理２４２で、ＳＩＰ１８０呼信号を、被呼側のＳＩＰエージェント１５８から、発呼側のＳＩＰエージェント１３２へ送信してよい。第３の処理２４４では、被呼側のＳＩＰエージェント１５８は、ＳＩＰ２００ＯＫ信号を、発呼側のＳＩＰエージェント１３２に送信して、ＶｏＩＰ呼の構築を開始してよい。第４の処理２４６で、ＳＩＰ２００ＯＫ（被呼側のＳＩＰエージェント１５８が呼に答える）に呼応して、発呼側のＳＩＰエージェント１３２は、ＶｏＩＰ呼について帯域幅を要求するwccConnReqメッセージをＭＳ１４のＷＣＣモジュール１３０に送信してよい。加えて、wccConnReqメッセージは、ＶｏＩＰストリーミングをサービスフローにマッピングするべく以下のパラメータを含む：（ａ）バイト単位の全ビットレート、（ｂ）ｍｓ単位の音声パケット期間、（ｃ）バイト単位の音声パケットサイズ、（ｄ）ソースＩＰアドレスおよびポート番号、および（ｅ）宛先ＩＰアドレスおよびポート番号。

wccConnReqメッセージに呼応して、第５および第６の処理２４８および２５０で、ＷＣＣモジュール１３０は、ＵＬ／ＤＬ用にＢＳ１２にＤＳＣ−ＲＥＱメッセージを、qosSetType=activeに設定されたパラメータとともに送信してよく、この後で、ＷＣＣモジュール１３０は、自身の起動待ち状態（WaitForActivation state）１４４に遷移してよい。より詳しくは、ＷＣＣモジュール１３０はＤＳＣ−ＲＥＱメッセージを送信するときに、ＶｏＩＰ呼用にＵＬ／ＤＬサービスフローを起動するべく以下のパラメータを送信する：（ａ）サービスフローＩＤ（ＳＦＩＤ）（ＵＬまたはＤＬ）、（ｂ）ＱｏＳパラメータセットタイプ＝「アクティブ」（これは、ＳＦがアクティブであり、ＢＳ１２がＭＳ１４に確保された帯域幅を承認することを示す）、および（ｄ）以下の規則によりＳＳおよびＢＳのパケット分類器を構成して、ＶｏＩＰパケットが適切な第２のサービスフローにルーティングできるようにする（パラメータの例には、ＩＰ宛先アドレス／ポートおよびサービス／区別化されたサービスコードポイント（ＤＳＣＰ）のＩＰタイプが含まれる）。ＤＳＣ−ＲＥＱメッセージの送信後、ＷＣＣモジュール１３０は自身の起動待ち状態１４８へ遷移してよい。

第７の処理２５２で、ＢＳ１２は、ＣＣ（Conformation Code）を成功（Ｓｕｃｃ）にセットして、ＵＬのＤＳＣ−ＲＳＰメッセージに応答してよい。第８の処理２５４で、ＭＳ１４のＷＣＣモジュール１３０は、ＣＣをＳｕｃｃにセットして、ＵＬのＤＳＣ−ＡＣＫを送信することで応答してよい。同様に、第９の処理２５６で、ＢＳ１２は、ＣＣ＝Ｓｕｃｃとして、ＤＬのＤＳＣ−ＲＳＰメッセージで応答してよい。第１０の処理２５８で、ＷＣＣモジュール１３０は、ＣＣをＳｕｃｃにセットして、ＤＬのＤＳＣ−ＡＣＫを送信することで応答してよい。第１１の処理２６０で、ＷＣＣモジュール１３０は、発呼側のＳＩＰエージェント１３２に対して、サービスフローにおいて音声通信の準備が整った旨を伝えるwccConnRspメッセージを送信してよい。その後、ＷＣＣモジュール１３０は、アクティブ状態１４６に遷移してよい。その後、ＳＩＰプロトコルは呼を完了する。より具体的には、第１２の処理２６２で、発呼側のＳＩＰエージェント１３２は、被呼側のＳＩＰエージェント１５８にＳＩＰ ＡＣＫ信号を送信してよく、その後の２６４で音声接続が構築される。

図５から１２を参照すると、図５に示すＭＳトリガモードとともに図１２に示す呼解除フローが示されている。第１の処理２７０で、被呼側のＳＩＰエージェント１５８は、ＳＩＰ ＢＹＥメッセージを、発呼側のＳＩＰエージェント１３２に送信して、ＶｏＩＰ呼を解除してよい。第２の処理２７２で、発呼側のＳＩＰエージェント１３２は、ＶｏＩＰ ＵＬ／ＤＬサービスフローに対する接続を停止するべく、パラメータ（ａ）ソースＩＰアドレスおよびポート番号、（ｂ）宛先ＩＰアドレスおよびポート番号とともにwccDiscReqメッセージをＭＳ１４のＷＣＣモジュール１３０に送信することで応答してよい。 第３および第４の処理２７４および２７６で、ＷＣＣモジュール１３０は、ＶｏＩＰ呼のＵＬ／ＤＬサービスフローの起動停止をするべく以下のパラメータとともにＤＳＣ−ＲＥＱメッセージを送信することで、wccDiscReqメッセージに応答してよく、このパラメータとは以下の通りである：（ａ）ＳＦＩＤ（ＵＬまたはＤＬ）、（ｂ）ＱｏＳパラメータセットタイプ＝許可（「許可」状態に変更することで、アクティブ呼がないことを示す）および（ｃ）「分類器ＤＳＣアクション」パラメータをＤＳＣ削除分類器に設定する（先に呼に利用された分類器規則を削除する）パラメータ。ＤＳＣ−ＲＥＱメッセージの送信後、ＷＣＣモジュール１３０は、起動停止待ち状態（WaitForDeactivation State）１４８に遷移してよい。

第５の処理２７８で、ＢＳ１２は、ＣＣ＝Ｓｕｃｃとして、ＵＬのＤＳＣ−ＲＳＰメッセージを送信することで、ＵＬのＤＳＣ−ＲＥＱメッセージに応答してよい。第６の処理２８０で、ＷＣＣモジュール１３０は、ＣＣ＝ＳｕｃｃとしてＵＬのＤＳＣ−ＡＣＫメッセージを送信することで応答してよい。同様に、第７の処理２８２で、ＢＳ１２は、ＣＣ＝Ｓｕｃｃとして、ＤＬのＤＳＣ−ＲＳＰメッセージを送信することで、ＤＬのＤＳＣ−ＲＥＱメッセージに応答してよい。第８の処理２８４で、ＷＣＣモジュール１３０は、ＣＣ＝ＳｕｃｃとしてＤＬのＤＳＣ−ＡＣＫメッセージを送信することで応答してよい。第９の処理２８６で、ＷＣＣモジュール１３０は、発呼側のＳＩＰエージェント１３２にwccDiscRspを送信して、ＳＩＰエージェント１３２に、サービスフローが起動停止された旨を通知してよい。その後、ＷＣＣモジュール１３０は、自身の許可状態１４２に遷移することで応答してよい。処理２８８で、ＳＩＰプロトコルは、発呼側のＳＩＰエージェント１３２が、ＳＩＰ２００ＯＫ信号を、被呼側のＳＩＰエージェント１５８に送信することで呼を解除してよく、これにより２９０で音声接続がティアダウンされる。

図１３を参照すると、ＷＣＣモジュール１３０を含む図５のＭＳ１４であってよいシステム３１０が示されている。ＭＳの例は、大容量記憶デバイスを有するラップトップまたはＵＭＤである。システムは、プロセッサ（集積回路チップ）３１２およびチップ３１２搭載用のＩＣチップキャリア３１４を含んでよい。ＩＣチップキャリア３１４は、ソケット３１８を介して基板またはプリント回路基板（ＰＣＢ）３１６に搭載されてよい。しかし、他のシステムではＩＣキャリア３１４がＰＣＢ３１６に直接連結されてもよい。ＰＣＢ３１６は、メインメモリ３２０と、外部デバイスまたは外部バス用に複数の入出力（Ｉ／Ｏ）モジュールとを有してよく、これら全てが互いに、ＰＣＢ３１６上のバスシステム３２２より連結される。システム３１０は、さらに、Ｉ／Ｏモジュール３２６を介してバスシステム３２２に連結される大容量記憶デバイス３２４を含んでよい。幾らかの実施形態では、さらなるＩ／Ｏモジュール３２８および３３０が、それぞれ他の外部または周辺Ｉ／Ｏデバイス３３２および３３４について含まれてよい。ＳＩＰエージェント１３２およびＷＣＣモジュール１３０は、大容量記憶デバイス３２６からメモリ３１８に、プロセッサ３１２の実行を目的として移動させられるソフトウェアモジュールであってよい。呼セッションおよびＷＣＣモジュールはソフトウェアモジュールとして示されているが、他の実施形態では、これらはハードワイヤであってよい。加えて、二段階呼制御手順はＭＳ１４に実装されているが、ＢＳ１２に対してトランスペアレントであってもよい。故に、二段階呼制御手順を含めることで、ＢＳ１２との相互運用性の問題を引き起こすことなくシステム３１０に対して付加価値を有するサービスを作成することができる。

特定の実施形態を例示および記載してきたが、当業者であれば同じ目的を達成するよう図られた任意の配置で記載されている特定の実施形態を置き換えることができることを理解しよう。本願は、本発明の適用例または変形例をカバーすることを意図している。故に、本発明は請求項およびその均等物によってのみの限定が明白に意図されている。

Claims (30)

1. 許可制御モジュールと、前記許可制御モジュールと通信するデータパス機能モジュールと、前記データパス機能モジュールと通信する接続制御モジュールとを有するサービスフロー管理モジュールを備える装置であって、
   前記データパス機能モジュールは、アクティブ状態の第１のアップリンクサービスフローの第１の動的サービス追加要求メッセージ（ＤＳＡ要求メッセージ）を生成して、ＶｏＩＰ（ボイス・オーバー・ＩＰ）シグナリングを提供し、
   前記許可制御モジュールは、前記許可制御モジュールがＶｏＩＰ呼に対して第２のアップリンクサービスフローをサポートできると判断すると、許可信号を生成し、
   前記第１および前記第２のアップリンクサービスフローは、実質的にＩＥＥＥ（米国電気電子学会）８０２．１６規格に準拠しており、
   前記データパス機能モジュールは、前記許可信号に呼応して、さらに、許可状態の前記第２のアップリンクサービスフローの第２のＤＳＡ要求メッセージを生成し、
   前記第２のＤＳＡ要求メッセージは、前記ＶｏＩＰ呼に確保された帯域幅を含み、
   前記接続制御モジュールは、ＤＳＡ要求メッセージおよび／または動的サービス変更要求メッセージ（ＤＳＣ要求メッセージ）の少なくとも一部に基づいて初期状態、第２のアップリンクサービスフローの帯域幅が確保されたが、アクティブなＶｏＩＰ呼がない状態である許可状態、第２のアップリングサービスフロー起動についての応答を待っている状態である起動待ち状態、少なくとも１つのＶｏＩＰ呼がある活動状態、第２のアップリングサービスフロー起動停止についての応答を待っている状態である起動停止待ち状態を含む複数の状態の間で遷移する装置。
2. 前記第２のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
   請求項１に記載の装置。
3. 前記第１のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
   請求項２に記載の装置。
4. 前記第１および前記第２のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない前記許可状態、および、前記サービスフローが起動されている前記アクティブ状態にすることができ、
   前記第１の動的サービス追加要求メッセージは、前記許可状態に前に設定されることなく前記アクティブ状態に設定された第１のセットタイプのパラメータを含み、
   前記第２のＤＳＡ要求メッセージは、前記許可状態に設定された第２のセットタイプのパラメータを有する
   請求項１から請求項３のいずれか１つに記載の装置。
5. 前記データパス機能モジュールは、さらに、前記第２のアップリンクサービスフローの利用データ記録を作成し、
   前記利用データ記録は、前記第２のアップリンクサービスフローの期間および前記ＶｏＩＰ呼中にトランスポートされたバイト数を含む
   請求項１から請求項４のいずれか１つに記載の装置。
6. 前記許可制御モジュールは、さらに、前記装置のセルにモバイルステーションが入ることに呼応して、前記第２のアップリンクサービスフローをサポートすることができるか否かの前記判断を開始する
   請求項１から請求項５のいずれか１つに記載の装置。
7. 前記接続制御モジュールは、前記第２のＤＳＡ要求メッセージの受信に呼応して、ＤＳＡ応答メッセージを前記データパス機能モジュールに送り、前記第２のアップリンクサービスフローの必要性を確認する
   請求項１から請求項６のいずれか１つに記載の装置。
8. 前記接続制御モジュールは、前記ＶｏＩＰ呼の接続要求メッセージの受信に呼応して、さらに、前記データパス機能モジュールに動的サービス変更要求メッセージ（ＤＳＣ要求メッセージ）を送信して、前記ＶｏＩＰ呼の前記第２のアップリンクサービスフローを起動する
   請求項７に記載の装置。
9. 前記接続制御モジュールは、前記ＤＳＣ要求メッセージの送信後に、さらに、前記データパス機能モジュールから、前記確保された帯域幅の起動を示すＤＳＣ応答メッセージを受信する
   請求項８に記載の装置。
10. 前記サービスフロー管理モジュールは、さらに、呼セッションモジュールを含み、
    前記呼セッションモジュールは前記接続制御モジュールと通信し、前記ＶｏＩＰ呼の前記接続要求メッセージを生成する
    請求項９に記載の装置。
11. 前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記ＶｏＩＰ呼の接続停止要求メッセージを生成して、
    前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、前記データパス機能モジュールに、別のＤＳＣ要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、前記データパス機能モジュールから、先に起動された前記確保された帯域幅の起動停止を示す別のＤＳＣ応答を受信する
    請求項１０に記載の装置。
12. 前記接続制御モジュールは、さらに、前記ＤＳＡ応答メッセージを送信すると、初期化状態から許可状態に遷移して、
    前記接続制御モジュールは、さらに、前記ＤＳＣ要求メッセージを送信すると、前記許可状態から起動待ち状態へ遷移して、
    前記接続制御モジュールは、さらに、前記ＤＳＣ応答メッセージを受信すると、前記起動待ち状態からアクティブ状態に遷移して、
    前記接続制御モジュールは、さらに、別のＤＳＣ要求メッセージを送信すると、前記アクティブ状態から起動停止待ち状態に遷移して、
    前記接続制御モジュールは、さらに、前記別のＤＳＣ応答メッセージを受信すると、前記起動停止待ち状態から前記許可状態に遷移する
    請求項１１に記載の装置。
13. ＶｏＩＰシグナリング用にアクティブ状態の第１のアップリンクサービスフローを受信して、さらに、ＶｏＩＰ呼用に接続要求メッセージを生成する呼セッションモジュールと、
    前記呼セッションモジュールに連結され、許可状態の第２のアップリンクサービスフロー用の動的サービス追加要求メッセージ（ＤＳＡ要求メッセージ）を受信する接続制御モジュールと
    を備え、
    前記ＤＳＡ要求メッセージは、確保された帯域幅を含み、
    前記接続制御モジュールは、前記接続要求メッセージに呼応して、さらに、動的サービス変更要求メッセージ（ＤＳＣ要求メッセージ）を送信して、前記第２のアップリンクサービスフローを起動して、
    前記第１および前記第２のアップリンクサービスフローは、実質的にＩＥＥＥ（米国電気電子学会）８０２．１６規格に準拠し、
    前記接続制御モジュールは、ＤＳＡ要求メッセージおよび／またはＤＳＣ要求メッセージの少なくとも一部に基づいて初期状態、第２のアップリンクサービスフローの帯域幅が確保されたが、アクティブなＶｏＩＰ呼がない状態である許可状態、第２のアップリングサービスフロー起動についての応答を待っている状態である起動待ち状態、少なくとも１つのＶｏＩＰ呼がある活動状態、第２のアップリングサービスフロー起動停止についての応答を待っている状態である起動停止待ち状態を含む複数の状態の間で遷移する装置。
14. 前記第２のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
    請求項１３に記載の装置。
15. 前記第１のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
    請求項１４に記載の装置。
16. 前記第１および前記第２のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない前記許可状態、および、前記サービスフローが起動されている前記アクティブ状態にすることができ、
    前記第１のアップリンクサービスフローは前記アクティブ状態にあり、前記第２のアップリンクサービスフローは前記許可状態にある
    請求項１３から請求項１５のいずれか１つに記載の装置。
17. 前記接続制御モジュールは、前記ＤＳＡ要求メッセージに呼応して、さらに、前記第２のアップリンクサービスフローの必要性を確認するＤＳＡ応答メッセージを送信して、
    前記接続制御モジュールは、前記ＤＳＣ要求メッセージの送信後に、さらに、前記第２のアップリンクサービスフローの起動を示すＤＳＣ応答メッセージを受信する
    請求項１３から請求項１６のいずれか１つに記載の装置。
18. 前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記ＶｏＩＰ呼の接続停止要求メッセージを生成して、
    前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、別のＤＳＣ要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、先に起動された前記確保された帯域幅の起動停止を示す別のＤＳＣ応答を受信する
    請求項１７に記載の装置。
19. 前記接続制御モジュールは、さらに、前記ＤＳＡ応答メッセージの送信において、初期化状態から許可状態に遷移して、
    前記接続制御モジュールは、さらに、前記ＤＳＣ要求メッセージの送信において、前記許可状態から起動待ち状態へ遷移して、
    前記接続制御モジュールは、さらに、前記ＤＳＣ応答メッセージの受信において、前記起動待ち状態からアクティブ状態に遷移して、
    前記接続制御モジュールは、さらに、前記別のＤＳＣ要求メッセージの送信において、前記アクティブ状態から起動停止待ち状態に遷移して、
    前記接続制御モジュールは、さらに、前記別のＤＳＣ応答メッセージの受信において、前記起動停止待ち状態から前記許可状態に遷移する
    請求項１８に記載の装置。
20. 前記接続制御モジュールは、さらに、ベースステーションから前記ＤＳＡ要求メッセージを受信して、前記ベースステーションに前記ＤＳＣ要求メッセージを送信する
    請求項１３から請求項１９のいずれか１つに記載の装置。
21. ＶｏＩＰシグナリング用にアクティブ状態の第１のアップリンクサービスフローを提供させる段階と、
    ＶｏＩＰ呼用に第２のアップリンクサービスフローをサポートできることを判断させる段階であって、前記第１のアップリンクサービスフローおよび前記第２のアップリンクサービスフローが実質的にＩＥＥＥ（米国電気電子学会）８０２．１６規格に準拠している段階と、
    前記第２のアップリンクサービスフローをサポートできると判断すると、前記第２のアップリンクサービスフローに確保された帯域幅を確保させる段階と、
    前記ＶｏＩＰ呼の接続要求メッセージに呼応して、前記第２のアップリンクサービスフローを起動させる段階と、
    動的サービス追加要求メッセージ（ＤＳＡ要求メッセージ）および／または動的サービス変更要求メッセージ（ＤＳＣ要求メッセージ）の少なくとも一部に基づいて初期状態、第２のアップリンクサービスフローの帯域幅が確保されたが、アクティブなＶｏＩＰ呼がない状態である許可状態、第２のアップリングサービスフロー起動についての応答を待っている状態である起動待ち状態、少なくとも１つのＶｏＩＰ呼がある活動状態、第２のアップリングサービスフロー起動停止についての応答を待っている状態である起動停止待ち状態を含む複数の状態の間で、接続制御モジュールを遷移させる段階とを含む処理をコンピュータに実行させる
    プログラム。
22. 前記第２のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
    請求項２１に記載のプログラム。
23. 前記第１のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
    請求項２２に記載のプログラム。
24. 前記処理は、さらに、前記第２のアップリンクサービスフローの利用データ記録を作成し、
    前記利用データ記録は、前記第２のアップリンクサービスフローの期間および前記ＶｏＩＰ呼中にトランスポートされたバイト数を含む
    請求項２１から請求項２３のいずれか１つに記載のプログラム。
25. モバイルステーションシステムであって、
    互いに連結されたメモリ、大容量記憶デバイス、およびプロセッサと、
    互いに連結された呼セッションモジュールおよび接続制御モジュールと
    を備え、
    前記呼セッションモジュールおよび前記接続制御モジュールの各々は、前記大容量記憶デバイスに記憶されて、前記プロセッサにより前記メモリへ移動させられ、
    前記プロセッサは前記呼セッションモジュールおよび前記接続制御モジュールを実行し、
    前記呼セッションモジュールは、ＶｏＩＰシグナリング用に、アクティブ状態の第１のアップリンクサービスフローを受信して、さらに、ＶｏＩＰ呼に接続要求メッセージを生成して、
    前記接続制御モジュールは、許可状態の第２のアップリンクサービスフローの動的サービス追加要求メッセージ（ＤＳＡ要求メッセージ）を受信して、前記ＤＳＡ要求メッセージは、確保された帯域幅を含み、
    前記接続制御モジュールは、前記接続要求メッセージに呼応して、さらに、動的サービス変更要求メッセージ（ＤＳＣ要求メッセージ）を送信して、前記第２のアップリンクサービスフローを起動して、前記第１および前記第２のアップリンクサービスフローは、実質的にＩＥＥＥ（米国電気電子学会）８０２．１６規格に準拠し、
    前記接続制御モジュールは、ＤＳＡ要求メッセージおよび／またはＤＳＣ要求メッセージの少なくとも一部に基づいて初期状態、第２のアップリンクサービスフローの帯域幅が確保されたが、アクティブなＶｏＩＰ呼がない状態である許可状態、第２のアップリングサービスフロー起動についての応答を待っている状態である起動待ち状態、少なくとも１つのＶｏＩＰ呼がある活動状態、第２のアップリングサービスフロー起動停止についての応答を待っている状態である起動停止待ち状態を含む複数の状態の間で遷移する
    モバイルステーションシステム。
26. 前記第２のアップリンクサービスフローは、自発的な承認サービスフロー、リアルタイムポーリングサービスフロー、および拡張リアルタイムポーリングサービスフローのうちから選択される
    請求項２５に記載のモバイルステーションシステム。
27. 前記第１のアップリンクサービスフローは、非リアルタイムポーリングサービスフローおよびベストエフォートサービスフローのうちから選択される
    請求項２６に記載のモバイルステーションシステム。
28. 前記第１および前記第２のアップリンクサービスフローは、それぞれ、前記サービスフローが確保されているが起動されていない許可状態、および、前記サービスフローが起動されているアクティブ状態にすることができ、
    前記第１のアップリンクサービスフローは前記アクティブ状態にあり、前記第２のアップリンクサービスフローは前記許可状態にある
    請求項２７に記載のモバイルステーションシステム。
29. 前記接続制御モジュールは、前記ＤＳＡ要求メッセージに呼応して、さらに、前記第２のアップリンクサービスフローの必要性を確認するＤＳＡ応答メッセージを送信して、
    前記接続制御モジュールは、前記ＤＳＣ要求メッセージの送信後に、さらに、前記第２のアップリンクサービスフローの起動を示すＤＳＣ応答メッセージを受信して、
    前記呼セッションモジュールは、前記接続要求メッセージの生成後に、さらに、前記ＶｏＩＰ呼の接続停止要求メッセージを生成して、
    前記接続制御モジュールは、前記接続停止要求メッセージに呼応して、さらに、別のＤＳＣ要求メッセージを送信することで、先に起動された前記確保された帯域幅を起動停止して、先に起動された前記確保された帯域幅の起動停止を示す別のＤＳＣ応答を受信する
    請求項２５から請求項２８のいずれか１つに記載のモバイルステーションシステム。
30. 前記接続制御モジュールは、さらに、前記ＤＳＡ応答メッセージを送信すると、初期化状態から許可状態に遷移して、
    前記接続制御モジュールは、さらに、前記ＤＳＣ要求メッセージを送信すると、前記許可状態から起動待ち状態へ遷移して、
    前記接続制御モジュールは、さらに、前記ＤＳＣ応答メッセージを受信すると、前記起動待ち状態からアクティブ状態に遷移して、
    前記接続制御モジュールは、さらに、前記別のＤＳＣ要求メッセージを受信すると、前記アクティブ状態から起動停止待ち状態に遷移して、
    前記接続制御モジュールは、さらに、前記別のＤＳＣ応答メッセージを受信すると、前記起動停止待ち状態から前記許可状態に遷移する
    請求項２９に記載のモバイルステーションシステム。

Images